Why Are Requirements There For Everybody? | TestFort

Why Are Requirements There For Everybody?

You are here

Unfortunately there are still many businesses who rarely realize full impact requirements may have on the overall project until they pay a price for such ignorance. Here is a bad example you may be following now yourself: only PM and SME, meaning the project manager combined with the business side specialist have access, review and the power to sign off to requirements documentation. In a best case scenario the development lead also takes part in this process, which is a fairly wrong approach.

Where may such a path lead you?

Requirements are as valuable to a decent QA process as the code itself if not more. Requirements are considered to be the largest deliverable testers possess. Your requirements specifications documentation serves as the primary basis for all test-cases created early in the way. So you may either gain detailed documents and great test cases or you may gain quite the opposite considering few people were involved in these documents creation.

If you are only tasking an SME to be responsible for such documentation you will get requirements that sound like ‘this particular feature has to be in place to allow users with the potential of choosing a wallpaper of preference’. This will be transformed into something stating ‘the application has to support background wallpaper changes’ by your Business Analyst. What’s so bad about this very approach? Testers are not given details and are not required to test anything but the main functionality.

It’s not the feature that values to QA, but the functionality!

What is the typical workflow you probably are used to? PM and SME combine their efforts and determine a feature that must be implemented, write it down into requirements and then this document flows to the QA department for early test case design and creation. So we have our previous example of how users should be empowered with the potential of changing a wallpaper of their preference. This is nice, but such document does not cover:

  • How this change is being triggered
  • No particular mention of how the change will take place after being triggered is noted
  • No mention of possible ways users will be allowed to choose wallpapers from (provided by in-app resources or downloadable from the web)
  • Custom wallpaper functionality is not even mentioned
  • No mentioning of any constraints like se size or the weight of the wallpaper
  • How must the changes be saved? Manually or automatically?
  • Etc., etc., etc.

So, without proper teamwork and collaboration you gain a testable document that does not present much value as it only covers a small portion of proper requirements. You will gain your tests but they will not cover much, and, as an obvious result, this may lead to numerous crushes in the product and financial losses as you will not be verifying anything of meaning to both the product currently under test and the user while QA takes place.

A solution!

If you are really aiming at a head start with testing, QA professionals will require some solid basis in order to design test cases of decent value. They can’t just accept requirement documentation somebody has already written. They must take part in their creation. Testes must have the authority to demand deeper explanation for better understanding of the product under test. You may host requirements review meetings where the Test Lead will have an equal place as the SME and the PM. This way you will end up with the product of finest quality.