Test design techniques

Improve Your Science

1. TEST DESIGN TECHNIQUES By : Y.A Obbi Ikhsan Backlink ke website r esmi : http://sif.uin-suska.ac.id/ http://fst.uin-suska.ac.id/ http://www.uin-suska.ac.id/

2. UNIVERSITAS ISLAM NEGERI SULTAN SYARIF KASIM RIAU FAKULTAS SAINS DAN TEKONOLOGI Nama : Y.A Obbi Ikhsan Nim : 11453106082 Jurusan : Sistem Informasi

3. IDENTI IDENTIFYING TEST CONDITIONS AND DESIGNING TEST CASES FYING TEST CONDITIONS AND DESIGNING TEST CASES   Differentiate between a test design specification, a test case specification and a test procedure specification. ( Kl) Compare the terms test condition, test case and test procedure. (K2) Write test cases: ( K3) a showing a clear traceability to the requirements; b containing an expected result. Translate test cases into a well-structured test procedure specification at a level of detail relevant to the knowledge of the testers. ( K3) Write a test execution schedule for a given set of test cases, considering prioritization, and technical and logical dependencies. (K3)

4. IEEE 829 STANDARD : TEST PROCEDURE SPECIFICATION TEMPLATE CATEGORIES OF TEST DESIGN TECHNIQUES Recall reasons that both specification-based (black-box) and structure-based (white-box) approaches to test case design are useful, and list the common techniques for each. (K 1 ) Explain the characteristics and differences between specification-based testing, structure-based testing and experience-based testing. (K2)

5. INTRODUCTION Each testing technique falls into one of a number of different categories. Broadly speaking there are two main categories, static and dynamic. Static techniques were discussed in Chapter 3. Dynamic techniques are subdivided into three more categories: specification-based (black-box, also known as behavioral techniques), structure-based (white-box or structural techniques) and experience-based. Specification-based techniques include both functional and non-functional techniques (i.e. quality characteristics). The techniques covered in the syllabus are summarized in Figure 4.1

6. SPECIFICATION-BASED OR BLACK-BOX TECHNIQUES Write test cases from given software models using the following test design techniques. (K3 ) a. equivalence partitioning; b. boundary value analysis; c. decision tables; d. state transition testing. Understand the main purpose of each of the four techniques, what level and type of testing could use the technique, and how coverage may be measured. ( K2) Understand the concept of use case testing and its benefits. (K2)

7. EQUIVALENCE PARTITIONING AND BOUNDARY VALUE ANALYSIS Equivalence partitioning (EP) is a good all-round specification-based black-box technique. It can be applied at any level of testing and is often a good technique to use first. It is a common sense approach to testing, so much so that most testers practise it informally even though they may not realize it. However, while it is better to use the technique informally than not at all, it is much better to use the technique in a formal way to attain the full benefits that it can deliver. This technique will be found in most testing books, including [Myers, 1979] and [Copeland, 2003].

8. BOUNDARY VALUE ANALYSIS ? Boundary value analysis (BVA) is based on testing at the boundaries between partitions. If you have ever done 'range checking', you were probably using the boundary value analysis technique, even if you weren't aware of it. Note that we have both valid boundaries (in the valid partitions) and invalid boundaries (in the invalid partitions). As an example, consider a printer that has an input option of the number of To apply boundary value analysis, we will take the minimum and maximum (boundary) values from the valid partition (1 and 99 in this case) together with copies to be made, from 1 to 99.  

9. DECISION TABLE TESTING Why use decision tables ?. A decision table is a good way to deal with combinations of things (e.g. inputs). This technique is sometimes also referred to as a 'cause-effect' table. The reason for this is that there is an associated logic diagramming technique called 'cause-effect graphing' which was sometimes used to help derive the decision table (Myers describes this as a combinatorial logic network [Myers, 1979]). However, most people find it more useful just to use the table described in [Copeland, 2003].

10. STATE TRANSITION TESTING State transition testing is used where some aspect of the system can be described in what is called a 'finite state machine'. This simply means that the system can be in a (finite) number of different states, and the transitions from one state to another are determined by the rules of the 'machine'. This is the model on which the system and the tests are based. Any system where you get a different output for the same input, depending on what has happened before, is a finite state system. A finite state system is often shown as a state diagram (see Figure 4.2).

11. 2. TEST MANAGEMENT   TEST ORGANIZATION   Recognize the importance of independent testing. (Kl) List the benefits and drawbacks of independent testing within an organ ization . (K2) Recognize the different team members to be considered for the creation of a test team. (Kl) Recall the tasks of typical test leaders and testers. (Kl)

12. DEFINING THE SKILLS TEST STAFF NEED Doing testing properly requires more than defining the right positions and number of people for those positions. Good test teams have the right mix of skills based on the tasks and activities they need to carry out, and people outside the test team who are in charge of test tasks need the right skills, too. People involved in testing need basic professional and social qualifications such as literacy, the ability to prepare and deliver written and verbal reports, the ability to communicate effectively, and so on. Going beyond that, when we think of the skills that testers need, three main areas come to mind: Application or business domain: A tester must understand the intended behavior, the problem the system will solve, the process it will automate and so forth, in order to spot improper behavior while testing and recognize the 'must work' functions and features. Technology: A tester must be aware of issues, limitations and capabilities of the chosen implementation technology, in order to effectively and effi ciently locate problems and recognize the 'likely to fail' functions and features. Testing: A tester must know the testing topics discussed in this book - and often more advanced testing topics - in order to effectively and efficiently carry out the test tasks assigned.

13. TEST PLANS ,ESTIMATES AND STRATEGIES   Recognize the different levels and objectives of test planning. (Kl) Summarize the purpose and content of the test plan, test design specifi cation and test procedure documents according to [IEEE 829]. (K2) Recall typical factors that influence the effort related to testing. (Kl) Differentiate between two conceptually different estimation approaches: the metrics-based approach and the expert-based approach. (K2) Differentiate between the subject of test planning for a project, for indi vidual test levels (e.g. system test) or specific test targets (e.g. usability test), and for test execution. (K2) List test preparation and execution tasks that need planning. (Kl) Recognize and justify adequate exit criteria for specific test levels and groups of test cases (e.g. for integration testing, acceptance testing or usability testing). (K2)

14. TEST PROGRESS MONITORING AND CONTROL Recall common metrics used for monitoring test preparation and execution . (Kl) Understand and interpret test metrics for test reporting and test control (e.g ., defects found and fixed and tests passed and failed). (K2) Summarize the purpose and content of the test summary report document according to [IEEE 829]. (K2)  

15. 3. TOOL SUPPORT FOR TESTING The tools described in this chapter are not the only tools that a tester can make use of. You may not normally think of a word processor or a spreadsheet as a testing tool, but they are often used to store test designs, test scripts or test data. Testers may also use SQL to set up and query databases containing test data. Tools used by developers when debugging, to help localize defects and check their fixes, are also testing tools.

16. EFFECTIVE USE OF TOOLS : POTENTIAL BENEFITS AND RISKS Summarize the potential benefits and risks of test automation and tool support for testing. (K2) Recognize that test execution tools can have different scripting techniques , including data-driven and keyword-driven. (Kl)

17. RISKS OF USING TOOLS Although there are significant benefits that can be achieved using tools to support testing activities, there are many organizations that have not achieved the benefits they expected. Simply purchasing a tool is no guarantee of achieving benefits, just as buying membership in a gym does not guarantee that you will be fitter. Each type of tool requires investment of effort and time in order to achieve the potential benefits. There are many risks that are present when tool support for testing is intro- duced and used, whatever the specific type of tool. Risks include: unrealistic expectations for the tool; underestimating the time, cost and effort for the initial introduction of a tool; underestimating the time and effort needed to achieve significant and con tinuing benefits from the tool; underestimating the effort required to maintain the test assets generated by the tool; over-reliance on the tool.

18. STATIC ANALYSIS TOOLS Static analysis tools are very useful to developers, as they can identify potential problems in code before the code is executed and they can also help to check that the code is written to coding standards . When a static analysis tool is first introduced, there can be some problems. For example, if the tool checks the current coding standard against code written several years ago, there may be a number of things found in the old code that fail to meet the new coding standard now in place. If the old code has been working well for years, it is probably not a good idea to change it just to satisfy the new coding standard (unless changes are necessary for some other reason). There is a risk that the changes to meet the new standard may have inadvertent side-effects which may not be picked up by regression testing.

19. TEST MANAGEMENT TOOLS Test management tools can provide a lot of useful information, but the informa - tion as produced by the tool may not be in the form that will be most effective within your own context. Some additional work may be needed to produce interfaces to other tools or a spreadsheet in order to ensure that the informa - tion is communicated in the most effective way.

20. REFERENSI : GRAHAM ET.AL (2011)