Sunday, 24 May 2009

Testing of Requirements... Is always a good thing™

I was having a read of The Impact of Requirements issues on Testing which is on the SoftEd Resources page. It says that 40% of software errors come from requirements errors. It would tend to agree with this as on the whole as it there is possibility for ambiguity and ambiguity leads to the business thinking it should do X, the developer codes Y and the tester tests it assuming it will do Z. Which leads to the standard inclusion of:

I'm sure everyone has seen this picture before, it is the standard diagram indicating misunderstandings in requirements.

What I see the problem is that testers only get involved when it is time to the output from development. This is always the case and I doubt it will really change until the client can understand spending time and money on testers to be engaged from day zero of the project and test every output along the way before going onto the next stage in the project life cycle. For example the project requirements are normally only signed off by the client. This isn't always the best as the the client doesn't always understand the technology fully and they described it to the BAs so they are can fill in the gaps and ambiguity without thinking about it. Having testers involved at this stage would bring in a viewpoint from people who have been involved in requirements gathering and also bring the testing viewpoint to things and looking for holes and defects.

Why I don't think this will fly without a lot of re-education?:
  • Testing will slow it down
  • This will require people so therefore require more money to be spent

But I personally think these are false realities:
  • It may lengthen the time for requirements gathering, but the overall project will be less. As picking up these errors before development will mean that some pieces will not have to be redesigned. redeveloped and retested. This is the whole the sooner in the cycle you detect a defect the cheaper it is to fix. Though usually it is only looked at with Unit Test vs. System Test vs. User Acceptance Test vs. Production.
  • The second point of needed more people and therefore money is linked into what I just said above. You will just be spreading the testing effort out over the project and will hopefully make the time spent testing the requirements back by spending less time retesting.

What is needed? Re-education in that life cycles should have test team involvement the whole way through the project not just post development. This will need to be taught in project management courses and made part of the methodologies used. Some of the Agiles are better at this as the test team is at the kick off meetings etc. and everyone is co-located so ambiguity can be sorted out quickly without needing to schedule meetings etc. Though seeing Agile doesn't scale to larger projects it would be good if some how some of these aspects could be worked into methodologies for the larger projects to use.