Requirements and the Bigger System

I used to spend ages tying together my test cases to the requirements. One thing that always out-foxed me though was what to do with those tests that didn’t directly tie to a requirement. Or the new test ideas that popped up later in the process that threatened to destroy our carefully planned schedule. It wasn’t until I got to be in charge of my own testing that I realised I’d been getting it all wrong.

I was focussing on the spec and requirements as being the single source for test ideas. I was planning coverage based on tests, which were based on this Word document. I was planning release dates based on a requirements document. I was lying to myself, management and our customers.

There is more to the system than the requirements. The requirements are just a small section of the system. The system is bigger than that. So don’t become consumed with saying you are complete when you have tested just the requirements. There is much much more. And the diagram below barely scratches the surface.

 

Aadiagram

4 Replies to “Requirements and the Bigger System”

  1. I like this because I chuckle when I hear that requirements are mandatory. How could a developer code without them? How could a tester test without them? In a perfect world, I agree, a feature would always have requirements. Unfortunately, my reality is that requirements are quite rare. I have gained the respect of developers and management by testing creatively from many angles without the helpful aid of requirements. Our software is stable, the Engineering team has open communication with a great exchange of information back and forth, and our customer service surveys tell us that our team is consistently doing excellent. All that to say, I agree with your post that there is much more to the scope of test design, scenarios and strategy than requirements.

  2. Hi Laura,Thanks for taking the time to comment.Indeed many companies operate perfectly well with lower than average requirements but I guess the mind set of the people involved plays a large part.For those companies that think they have perfect requirements, there are still areas of the system they have not hit with their testing. Too many contexts and unknowns to be sure of anything.”testing creatively” – I like the sound of that. Rob..

  3. This is a real project M requirement – not made up:—REQ01 – All orders must be processed as usualREQ02 – “new stuff” works like blablalbla—Hence A LOT of testcases goes towards that requirement, the following requirements had very little .. test coverage.. in comparison (to REQ01). Kinda odd. The next project N didn’t include this requirement, but then – wasn’t everything ment to work as usual? Where could we then tie all our regressions tests (ideas, concerns, sideeffects) to?Requirements are an idea to want the solution holds, not necessarily towards what drives the test – or the amount of testcases (think safety critical systems).

  4. Hi Jesper,Genius requirements. Old stuff should keep working. I’ve never seen that listed as a requirement before. Basically a giant requirement of regression. Nice.I like your sentence on requirements being about what the solution holds. Thanks for commenting.Rob..

Comments are closed.