Quality Testing

Quality is delighting customers

Hi guys,

I understand that Test Design specification is one document recommended by ISTQB / ISEB which will detail the test scenarios and features pass / fail criteria. 

I have a few questions below:

1) When do we write it? I assume we should be writing it before writing our test cases and after the requirements are gathered. If no, then what is the answer. 

2)  If answer to question 1 is yes, I was asked in a interview how do you go about writing your test cases. So I said after the requirements are ready, we write our RTM after which the test cases are written which means test design is completely skipped out. So what is the right answer to this question?

3) How many organisations write it?



Views: 370

Reply to This

Replies to This Discussion

Tricky subject, Bataji, since it seems ISTQB don't fully understand the Test Design Spec.  This is a document specifying the design for one or more tests, where a test is a set of test cases and/or procedures centred on a given feature of the test item.  In IEEE 829, TDSs are identified and listed in the Test Plan (clause 4, "Features to be Tested").  To achieve this, you need at least a list of required features of the SUT (software under test).

The next step assumes you have a detailed specification to analyse for test conditions.  During detailed Test Analysis, you identify test conditions for a given feature and list them in the corresponding TDS (clause 2).  From the test conditions, during Test Design, you construct a test model (decision table, state transition diagram, flowchart ...) in TDS clause 2, and use it to identify the test cases that make up your test.

You list these "abstract test cases" in TDS clause 4.  They are "abstract" test cases because they consist of test conditions ("card is valid", "PIN is valid", "amount < balance", "balance decremented by amount", etc) rather than data values.  Also in clause 4 you list the test procedure(s) for running the test.

You now have the design for one test.  Repeat this for each feature, and you have the designs for several tests, though they don't have to be in separate documents; one document or several is over to you.

To implement the design, you create a set of test case specifications, in each of which you specify concrete data values in place of the test conditions for one abstract test case.  The test case specs also don't have to be in separate documents.  The same is true of the test procedure specifications, each of which defines the steps for correct, reliable, consistent execution of a test, including steps such as setting up and verifying the test environment, running the test cases, and tearing down the environment at the end.

ISTQB are confused about where abstract test cases get implemented as concrete test cases; in Chapter 1 of the Foundation Syllabus, it's in the Implementation activity, along with test procedures specifications (which makes sense).  In Chapter 4, it's in the Design activity (which doesn't make as much sense).

Hope this helps,

-- Don

Hi Don,

Excellent explanation. Thank you so much.



well explained!


TTWT Magazine





© 2022   Created by Quality Testing.   Powered by

Badges  |  Report an Issue  |  Terms of Service