“Bug prevention is testing’s first goal.” – B. Beizer
One of the best practices in our team is the fact that both the devs and the tests review the functional specification before it is accepted. As a test this is the time to make them most of. One of the practices I have learnt from Robert Binders, Testing Object Oriented Systems is analyzing the requirements while you read them. He recommends a pattern called Extended use-cases. If you rewrite the requirements in this way, trying to fill in different scenarios/inputs, you can detect ambiguities in the functional specification better than if you just read through the specification.
The functional specification is the basis for the system tests. Because you can start work on these as soon as the functional specification is out, you have your system test strategy ready even before the developers start churning out features. While you use the system tests the last, you write them the first. As features become available, you can start running some of them.
Subscribe to:
Post Comments (Atom)
I think before all these kinds of testing comes one more, which I call documentation testing. Install the product open the documentation and see if the product does what the documentation says it does. You will find a ton of bugs. Customer pain starts from there.
ReplyDeleteso not able to work as developer, thats why u choose testing and know misguiding other people by writing such blogs.
ReplyDeleteIts better to write some real and good stuff and not the only theoritical part
Hope u understand wat i mean
Just for your Knowledge
Specification based testing is completely different from Functional specification testing,
or watever u r calling it