This morning, I went to a Borland Seminar about Requirement Based Testing (RBT). I don’t think that we can justify the spending for the tools that Borland propose to achieve this concept but none the less the information was very valuable to me. Sometimes the simplest concept are the most effective.The first thing they said that got my attention is that a requirement that you can’t test is not a valid requirement. You simply need to reword it to be measurable. So the requirement of an application to be fast is not valid but saying that step x can only take y seconds is valid.
The other thing that they repeated over and over was traceability. You need to be able to see the link between your requirements, the test and the results. That is where their tools helps you greatly. Doing all this in a spreadsheet is the poor man solution to it.
I also liked hearing that you need to have the least amount of test case for your requirements. Simplify! If you have more than 5% of your test case on a specific requirement you should look at it again.
Something else that I will mention that I liked was the fact that your tester, developers should be made aware of all the requirements early on and when you make changes to them you have to communicate them effectively. The goal to get everyone on board early on is to avoid the separation of the teams and the “ennemy mentality” that “sometime” happens.
The last funny tidbit for me was the mention that 60% to 70% of work in IT is actually rework. Work that will not get used or you are simply redoing what you (or someone else) has done. So easy to believe without any need for proofs.