Test design techniques
•Download as PPTX, PDF•
0 likes•33 views
Test design techniques involve identifying test conditions from a test basis like requirements or code, then specifying test cases with detailed inputs and expected outputs, and finally implementing test procedures or scripts that group related test cases and define the steps to execute them in a logical order according to a test schedule. The level of formality in documentation depends on the context from informal to very formal for safety-critical systems. Test conditions are things that could be tested, while test cases must be very specific with inputs and expected results.
Report
Share
Recommended for you
Recommended for you
More Related Content
What's hot
What's hot (20)
Similar to Test design techniques
Similar to Test design techniques (20)
Recently uploaded
Recently uploaded (20)
Test design techniques
- 1. Test design techniques By : Arif Rakhmatullah.m Program Studi (S1) Sistem Informasi Fakultas Sains dan Teknologi Universitas Islam Negeri sultan Syarif kasim Riau
- 2. IDENTIFYING TEST CONDITIONS AND DESIGNING TEST CASES • Formality of test documentation Testing may be performed with varying degrees of formality. Very formal testing would have extensive documentation which is well controlled, and would expect the documented detail of the tests to include the exact and specific input and expected outcome of the test. Very informal testing may have no documentation at all, or only notes kept by individual testers, but we'd still expect the testers to have in their minds and notes some idea of what they intended to test and what they expected the outcome to be.
- 3. Cont.. Most people are probably somewhere in between! The right level of formality for you depends on your context: a commercial safety-critical application has very different needs than a one-off application to be used by only a few people for a short time.
- 4. Test analysis: identifying test conditions Test analysis is the process of looking at something that can be used to derive test information. This basis for the tests is called the 'test basis'. It could be a system requirement, a technical specification, the code itself (for structural testing), or a business process. Sometimes tests can be based on an experienced user's knowledge of the system, which may not be documented. The test basis includes whatever the tests are based on.
- 5. Cont… From a testing perspective, we look at the test basis in order to see what could be tested – these are the test conditions. A test condition is simply something that we could test. If we are looking to measure coverage of code decisions (branches), then the test basis would be the code itself, and the list of test conditions would be the decision outcomes (True and False). If we have a requirements specification, the table of contents can be our initial list of test conditions.
- 6. Test design: specifying test cases Test conditions can be rather vague, covering quite a large range of possibilities as we saw with our mobile phone company example (e.g. a teenager in the mid-west), or a test condition may be more specific (e.g. a particular male customer on pay-as- you-go with less than $10 credit). However when we come to make a test case, we are required to be very specific; in fact we now need exact and detailed specific inputs, not general descriptions (e.g. Jim Green, age 17, living in Grand Rapids, Michigan, with credit of $8.64, expected result: add to Q4 marketing campaign). Note that one test case covers a number of conditions (teenager, male, mid-west area, pay-as-you-go, and credit of less than $10).
- 7. Cont.. For a test condition of 'an existing customer', the test case input needs to be 'Jim Green' where Jim Green already exists on the customer database, or part of this test would be to set up a database record for Jim Green. A test case needs to have input values, of course, but just having some values to input to the system is not a test! If you don't know what the system is supposed to do with the inputs, you can't tell whether your test has passed or failed.
- 8. Test implementation: specifying test procedures or scripts The next step is to group the test cases in a sensible way for executing them and to specify the sequential steps that need to be done to run the test. For example, a set of simple tests that cover the breadth of the system may form a regression suite, or all of the tests that explore the working of a given functionality or feature in depth may be grouped to be run together.
- 9. Cont… Some test cases may need to be run in a particular sequence. For example, a test may create a new customer record, amend that newly created record and then delete it. These tests need to be run in the correct order, or they won't test what they are meant to test. The document that describes the steps to be taken in running a set of tests (and specifies the executable order of the tests) is called a test procedure in IEEE 829, and is often also referred to as a test script.
- 10. Cont… It could be called a manual test script for tests that are intended to be run manually rather than using a test execution tool. Test script is also used to describe the instructions to a test execution tool. An automation script is written in a programming language that the tool can interpret. (This is an automated test procedure.) The test procedures, or test scripts, are then formed into a test execution schedule that specifies which procedures are to be run first – a kind of super-script. The test schedule would say when a given script should be run and by whom.
- 11. Cont… The schedule could vary depending on newly perceived risks affecting the priority of a script that addresses that risk, for example. The logical and technical dependencies between the scripts would also be taken into account when scheduling the scripts. For example, a regression script may always be the first to be run when a new release of the software arrives, as a smoke test or sanity check.
- 12. Reference Graham, d., et al. 2006. Foundation of Software Testing: ISTQB certification London, UK: International Thomson Business Press