how do u know that a requirement is testable

Views: 730

Reply to This

Replies to This Discussion

when you 'can' figure out a way to 'test' (verify/validate/check) it ...
thanks sunjeet
A requirement that is Complete, Correct, Non-Ambigious, Measureable and has (Action/result,Conditions,Information/input ) associated is said to be "Testable".

Requirement Decomposition helps in making the requirements testable.
Thanks Adarsh.Really the information got from u is valuable
Can you give me an example of complete, correct, non-ambiguous and measurable?

Requirements are ideas represented in social context by humans. Pure text bookish viewpoint of requirements being "complete, correct etc" is a highly simplistic and reductionist view. Works for certification exams, clearing some interviews, even getting some jobs ... but when rubber meets the ground, when start working on a project and deal with requirements, you will know what I am saying here .....

Let me say ... what has been taught in soft engg books etc is WRONG... check it yourself... don't believe anything without checking yourself ... including this reply of mine...

One simple answer to the original question - ask "how do you test it?"

Hi Susmita,

In addition to my previous reply, Say for example for testable reqmt,

An Airtel user gets 50% discount on all calls made from M2M between 10pm - 6am on weekends.

Check if the reqmt can be tested under proper test environment conditions (system)
Check if the reqmt has defined inputs(measureable, objective) and outputs
Check if the pre & post conditions are properly specified.

If all the above parameters are met, then you can know whether the requirement is testable or not.

By the way, there are 21 proven ways to test software requirements. This is one approach to go about.

Hope this helps you.
21 ways ? what a number ? where did you get this number and how do you know that is a correct number?

Can you list them for the benefit of all and further scrutiny?

What does it mean that pre and post conditions are properly specified? What does properly refer to?

When you know what properly means you probably have already performed the test..

I do not know if there is nothing like complete and non-ambigous requirements. But Shrini's reply is a good example of ambiguous and incomplete presentation of an idea (I think, the same can happen to a requirement also). Let us forget the english and try to understand what he is trying to say.

<quote> Requirements are ideas represented in social context by humans </quote> Does this mean that they (requirements) cannot be correct or complete, and testers need not worry about it if they are not? Are people wasting their time when they do testability analysis, ambiguity reviews etc?  I doubt.  Neither do I believe that requirements are signed off knowing that they incorrect, incomplete and ambiguous!

I appreciate the school of thoughts under the banner of "Context Driven School" but do not see it as an excuse for for lack of clarity, completeness or correctness of requirements. I think this is true irrespective of whether the requirements exist in a "social context" or in a "business context". The rest of the blurb is a continuation of the same idea.

The discussion ends with a strange suggestion of thinking "how to test it" - Not sure if this means that the tester should think of testing the requirements irrespective of whether it is correct and complete!

A requirement that is Complete, Correct, Non-Ambigious, Measureable

and I thought "Requirement" is something which is "Never Complete, nor Correct, Ambiguous, hard to Measure" and still I TEST...

I think we are taking binary view on this - possible or not. Reality is in the colors of Grey!
First identify the test objects (may not be available on a plate as Shrini's mentioned). And then think, what test level is you concern, how big the business impact the item is , and to what extend it is testable. If the risk is high (depends the appl type, user etc), discuss with the project how they can facilitate (many times they are very happy if you bring this out early and help!).

I agree with your view. At the same time, I am of the opinion that a tester, through his reviews (for ambiguity and testability) should contribute to improving the "quality" of requirements. Many of the comments tend to reduce testing into a "craft" and ridicules people who talk about the science and process behind it.


© 2014   Created by Test Republic.

Badges  |  Report an Issue  |  Terms of Service