Extracting Testable Conditions
Following on from Part 1, a large part of Specifications Analysis is extracting Testable Conditions, so now we will look at how to do that.
In order to ensure a quality product, every function that the product carries out must be testable. That is to say, if a product is supposed to do x, y, and z, then in order to determine that it does do x, y, and z, it must be possible to test that it does indeed do x, y, and z.
This is why it is so imperative that the Specifications should be specific rather than vague.
If the Specification says the product will do "x", then it must do "x". Whatever "x" is, it must be clearly defined. When "x" is clearly defined, it is possible for the Developer to develop the product so that it does "x", and it is possible for the Tester to confirm that the product does "x".
Does the product do "x" is therefore a Testable Condition. A Testable Condition is a black and white scenario. Either the product does "x", or it does not do "x".
So when you are analysing the Specifications to produce Testable Conditions, you are looking for everything that can be resolved to a black and white scenario.
To the extent that you are able to do this, the Specification is clear and specific.
Conversely, to the extent that you are not able to do this, the Specification is unclear and not specific.
There are different ways of ways of determining whether you have extracted all the conditions. One is to number everything. Another is to use coloured highlighting pens.
Wherever there are gaps (numerical or uncoloured), you will need to get clarification from the BA.
This is a matter of going through the document for as many times as it takes to get everything in it to be testable.
By the time you have finished, you will have a set of Testable Conditions - you now have to fit these Testable Conditions into your Test Cases.
Showing posts with label Preparation. Show all posts
Showing posts with label Preparation. Show all posts
How To Analyse Specifications - Part 1
Specifications are the foundation of a project. It tells Developers what to develop, and it tells Testers what to test. If the Specifications are of a low quality, then the development work and the testing work will be of a low quality - unless the Specifications are improved.
It should be no surprise then, that the very first job of a Tester is to test the specifications. This is often called Static Testing. Some Testers have a tendency to leap into creating test scripts, but this can (and often does) become a waste of time. So it is testing the specifications against themselves that is the Tester's first priority.
But what do you test them against? What are the criteria that determine whether the Specifications are doing their job correctly?
The answer is in the word specifications, and runs from the first letter to the eighth letter - it is the word "specific". This is the first test of the Specifications - they should be specific.
They should not be vague - a Business Analyst once told me that he had "deliberately left the specifications vague to cover a range of possibilities". I was unimpressed.
Specifications should not use words that don't describe specifically should happen.
Words and phrases such as "handle appropriately", "correct", and "as expected" are very often used in Specifications. I call them "fluffy" words or phrases, because they describe approximately what should happen, but they do not clearly describe what should happen. They are not specific.
The First Test
So this is the first test of the Specifications.
How specific is it? Does it use fluffy words? Does it use fluffy phrases?
These questions need to be raised by the Tester, and clarifications sought wherever the Specification fails the test, e.g "What do you mean when you say that the data output should be handled appropriately? How exactly should it be handled?"
The Second Test
The second test of the Specifications is accuracy.
Now evidently, the Tester is not, at least in the beginning, in a position to say that the Specifications are inaccurate. They are based on discussions between the Business Analyst and one or more people in the business, who we shall refer to as the Product Owner(s). Since the Tester was not a part of those discussions, they are not in a position to say whether or not the Specifications accurately reflect what was said.
But as a Tester, you need to look out for functionality being described differently in different parts of the Specifications - you may even find contradictions within the Specifications!
This can often involve getting out pen and paper and rearranging various points of the Specifications. You can do this in written form, or table form. In the process of this rearrangement, you will see new patterns emerging, which will highlight to you any differences.
This is testing the documentation, or Static Testing.
It should be no surprise then, that the very first job of a Tester is to test the specifications. This is often called Static Testing. Some Testers have a tendency to leap into creating test scripts, but this can (and often does) become a waste of time. So it is testing the specifications against themselves that is the Tester's first priority.
But what do you test them against? What are the criteria that determine whether the Specifications are doing their job correctly?
The answer is in the word specifications, and runs from the first letter to the eighth letter - it is the word "specific". This is the first test of the Specifications - they should be specific.
They should not be vague - a Business Analyst once told me that he had "deliberately left the specifications vague to cover a range of possibilities". I was unimpressed.
Specifications should not use words that don't describe specifically should happen.
Words and phrases such as "handle appropriately", "correct", and "as expected" are very often used in Specifications. I call them "fluffy" words or phrases, because they describe approximately what should happen, but they do not clearly describe what should happen. They are not specific.
The First Test
So this is the first test of the Specifications.
How specific is it? Does it use fluffy words? Does it use fluffy phrases?
These questions need to be raised by the Tester, and clarifications sought wherever the Specification fails the test, e.g "What do you mean when you say that the data output should be handled appropriately? How exactly should it be handled?"
The Second Test
The second test of the Specifications is accuracy.
Now evidently, the Tester is not, at least in the beginning, in a position to say that the Specifications are inaccurate. They are based on discussions between the Business Analyst and one or more people in the business, who we shall refer to as the Product Owner(s). Since the Tester was not a part of those discussions, they are not in a position to say whether or not the Specifications accurately reflect what was said.
But as a Tester, you need to look out for functionality being described differently in different parts of the Specifications - you may even find contradictions within the Specifications!
This can often involve getting out pen and paper and rearranging various points of the Specifications. You can do this in written form, or table form. In the process of this rearrangement, you will see new patterns emerging, which will highlight to you any differences.
This is testing the documentation, or Static Testing.
Subscribe to:
Posts (Atom)