416-275- 9840 (Canada) | 215-297-4646 (USA) | info@getsoftwareservices.com

ISTQB : Test Analysis and Design – Software Testing

ISTQB Test Analysis and Design

In the ISTQB syllabus, the Test Process consists of a five phases Plan, Design, Implement/Execute, Report, Closure. (Our blog titled “Software Test Life Cycle” has more details .)  The second phase of the Software Test Life Cycle is Test Analysis and Design, where specifications are analysed and test cases designed. This phase is an important one. In my experience, most testers are very eager to start writing test cases as soon as specifications are ready. The ISTQB Test process has this formal phase introduced to insist on fore-thought and planning, and hence avoiding re-work and to get it right the first time.

In this test phase, specifications are analysed to understand what the application’s functions are – the screens, the actions, database updates, error messages, flow of data/info etc. The specifications are analysed to check how clear and complete the information is, for any confusion, ambiguities(unclear), for any discrepancies(conflicting actions), and more importantly how to test and verify the function in the system. The reviews and clarifications done early in this stage helps build a greater understanding of the product and hence an improvement to cost, quality and time in later stages.

The ISTQB processes advocates a 3-step process to the test design process – Test Conditions, Test Cases, Test Procedures.

Test Conditions: a test condition verifies a small section of the Functional Specification. eg. Registration,  Login etc

Test Cases: pre-conditions, a set of inputs, expected outcome and the post-conditions to verify the Test Condition

Test Procedure : actual sequence of actions or steps to execute the test

Test Execution Log – the order in which tests are run logically one after another

So, a larger Functional Spec or application is chunked or broken down into smaller manageable parts using Test Conditions. Test Cases focus on verifying the Test Condition for both positive and negative situations. Breaking into Test Conditions and Test cases makes a large application more manageable and enable us to focus on the smaller details without getting lost in detail & documentation. Segregating the test steps from test cases enable better readability, easier review and improved traceability.

In most organizations, this three step process do not exist separately, although we all informally follow this. The terms Test Conditions etc are not used, everything is usually referred to as Test Cases. We usually take an area of the application and start analysing, understanding and designing the test cases and test data. And in Quality Center, we continue this process by creating a folder to represent the Test Condition. Test Cases are written to verify each Test Condition and grouped under the relevant folder.  The only difference is in QC and even otherwise, the test cases and test procedure are grouped as one, each test case has all the steps and info needed to execute it.

The importance of spending time on Analysis and Design of test cases has very good payback in terms of less re-work, better coverage, and less time spent reviewing and correcting test cases. Understanding this and the various techniques and principles in testing, is one of the best ways improve our efficiency as a tester and this is where the ISTQB certification really adds value.

We use Black Box techniques to better design test cases. We will look at Black Box techniques in the coming blogs.

 

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *