How You Should Test Requirements of Different Priority

TestFortExpert by TestFortExpert on 07/2/2014

How You Should Test Requirements of Different Priority

requirementsWhen a tester is fresh to the software testing industry, it’s sometimes difficult for them to prioritize customer requirements smartly and understand what the customer really expects beyond what’s expressly planned. Then it becomes useful to draw some conditional line between the requirements which are of high priority and those of lower priority for the customer and product success.

We suggest to conditionally dividing software product testing requirements into written, expected and desirable. Here is what they are and how testers should handle them.

  1. Written Requirements

These are requirements which are usually contained in product documentation and design plans or are just expressed in spoken or written communication with the customer. These are the skeleton, but far from the whole product.

Run one or several negative checks against each of such requirements. If the product arrives at the testing stage failing to match one of these, it’s worth moving back along the process to fix it. Written requirements should be normally verified by developers with a number of automated checks.

  1. Expected Requirements

Expected requirements often don’t get written down since these are viewed as obvious. For example, if your product has a private content sharing functionality, the customer expects you to understand (and test) that the users’ private content isn’t to be visible to all the users.

To test this kind of requirements a tester should have a knack for both customer problems and software technologies used in the product. The coverage can’t be demonstrated as such, so you should be guided more by heuristic testing methods. When such a requirement fails to be realized, you should note in your bug report why the client would expect it in their product and what can be this bug’s effect on their product’s UX.

  1. Desirable Requirements

Sometimes customers don’t know what exactly their product should look like and they actually rely on your tech competence to bring the product to perfection. These requirements, unexpected but actually desirable, demonstrate your responsibility towards the project and your expertise as a QA expert.

This type is the trickiest to test. Here you should get the customer’s preferences really well. You can increase this ability by using different UX research techniques. After studying how the end user is actually going to use the product, you’ll be able to learn some desirable requirements. Their failure isn’t even a bug – rather it’s just an opportunity to make the product better.

Given the above considerations, it’s better to remember that the end product isn’t just a set of documented requirements. So tighten your belt and be ready to test!

We use cookies to ensure your best experience. By continuing to browse this site, you accept the use of cookies and "third-party" cookies. For more information or to refuse consent to some cookies, please see our Privacy Policy and Cookie Policy