Bridging the gap between customer needs and design is often difficult. This blog post addresses some of these issues and introduces you to the concept of a “test requirement” to help you tackle this problem.
Too often it happens that the project’s outcome is not what the customer would have wanted. There are numerous reasons for this, but two major reasons can be seen over and over again
1) Traditional (V-model) projects relying on pre-written business requirements run into misunderstandings when designing test cases from these requirements.
2) Agile projects tend to have issues with the visibility of quality.
Test requirements help customers and suppliers to talk the same language that is needed of the software and at the same time having a better understanding of the software’s quality.
Common problems with the V-model projects
Before going into what these test requirements actually are, let’s review some commonly encountered issues in testing projects. First, we’ll review the V-model. First off, very often the requirements are too vague to specify exactly how the software works and how it can be tested. This is true even when a serious effort is given to the task of writing the requirements. It is understandable. It is not cost-efficient, if even possible, to write so good requirements that describe unambiguously what the customer needs. Also on bigger projects, these requirements tend to change which increases the expenses of the project.
For a test designer, a changed requirement can be a nightmare if the information is only on somebody’s E-mail or meeting minutes. As the supplier of the software project wants to maximize the profits, it’s interest is usually to fulfill the requirements but not much more. This often leads to a situation where customer’s testers report bugs because the software does not work as the customer wants, but the supplier does not want to fix them for the fixed price as the requirement does not directly specify how the feature should work.
Developing and testing using agile methods
If the V-model projects aren’t always that rosy, the agile testing is not completely without its problems: The customer is expected to allocate time to the project so that the project’s implementation would always be going to the right direction. It is accepted that even if the project does some wild implementation guesses/experiments that are later scratched and rewritten, it is acceptable, as the project’s implementation as a whole can still be very effective. This stays true if the customer steers the project in real-time in the right direction, but often the project learns about the customer needs later than what would be optimal.
If the project is a bigger one and has many testers, having the test team test the right things at the right time is essential, and having visibility on what actually has been tested allows the test manager to accomplish that. The lack of this visibility is sometimes a problem on agile projects. The problem is often worsened if and when people on the project change while the documentation of the implementation is kept at a minimum.
The definition of test requirement
Ok, I’ve stated some often seen problems on testing and development, and supposedly I should have some ideas on how to reduce them with test requirements, but what are those test requirements? In short, they describe what will be tested, but not how it will be tested. What if you are not using requirements as such, you are using, for example, user stories you might ask. It does not change a thing – if you can use something, user story for example, as a basis of design, you can use it as a source of a test requirement too. For the sake of simplicity, I will call all these sources requirements for the rest of this blog post.
A test requirement is short – it should describe one relatively independent area of a requirement it is based on. It is agile – it can change or it can be rejected if needed. A test requirement can have additional information like status for review or importance. All of this can be utilized in decision making and reporting.
The “how” of test requirements
Now we know a little bit what test requirements are, but how do we use them? First off, there are numerous correct ways. You can pick the practices that best fit your development environment. The essential thing to remember when working with test requirements is to start working on them as early as possible. You can start when you have the requirement. Just split the requirement to the pieces you plan to test. You can include things you presume how it will work. Sometimes your assumptions will be wrong but it doesn’t matter. As the scope of a test requirement is small they are super fast to review later. More often the test requirements act as a valuable communication tool and increase the understanding between the customer and the supplier.
I mentioned reviewing. Test requirements should be reviewed by the customer and supplier both. It is an extra step, yes, but it is a fast and efficient one. It can happen at any phase of the project, but the sooner the better. The point is that after the review both parties will have a better understanding of the upcoming solution.
Benefits of using test requirements
There are also other ways to work with requirements and cooperate between involved parties, so what are the benefits of using the test requirements?
- It is simple. Splitting the requirements is an easy task and communication with these even simpler. ”Is this what you want?” Yes/No. ”Can it be done?” Yes/No/Yes, but it will be expensive/Depends (So yes, you will not always get the definitive answer right away about the solution, but having the answer for some helps already a lot).
- It is effective. For every detail you define before development you have a fair chance to save time from unwanted design, implementation, testing, fixing and building.
- Splitting down the requirements to small pieces makes talking about them easy, and using a format that defines how they will be tested is intuitive. Having this kind of detail in the actual requirement is not as good as making these requirements would be too time-consuming and probably would lead to an optimal design. It is better to talk about the requirements with the development team. Waiting until the development team has done the development according to general requirements is not good either as the outcome likely isn’t optimal for the customer.
- Defining test requirements adds a visible and measurable layer that can be used to track the development and quality of the project.
- Using test requirements is a good way of involving the test team early on and using what they are good at – predicting what might go wrong. Experienced tester recognizes the possible weak points of the design. When you have test requirements ready, designing the actual test cases is easier. This is good as that phase in the project tends to be busier, and now you have already done part of the work.
- Another advantage is the added precision when discussing the found defects. When pointing a defect to a more precise test requirement that has been reviewed, it is easier for a tester to point out why the defect has been reported.
Working with test requirements using Meliora Testlab
Meliora Testlab has been designed to utilize the concept of test requirements and gives the user a powerful toolset to design and report test requirements and plan test cases from them. Testlab also contains strong collaboration features that enable project to define either stricter or looser workflows – just what suits the company. Testlab’s automatic notification features make sure people get notified when they should act. This makes managers’ work easier.