Learn to Use Test Requirements For Better Communication, Planning and Execution:
It is definitely a good thing to be able to work more efficiently. For testing, there are countless different ways how to improve efficiency.
This approach presented in this article explains how Test Requirements can be used as a medium to increase communication in the projects which in turn helps planning and to execute more relevant content. It also allows using testers’ knowledge smartly for a better design.
Why? Because this way of working can improve your project’s efficiency. Better quality in less time. How? Split your Requirements/User stories from the testing point of view.
How I suggest using Test Requirements is something between the traditional V-model way of working and Agile methods. I will first go through a few problems I’ve encountered in projects working in purer forms of traditional and V-model projects. After going through these common problems I will show how to test requirements that can be used to avert these.
Table of Contents:
Projects Working In V-Model
The traditional way of developing software projects is the V-model. The general idea is that these projects first define the requirements for the project, define the System Design based on requirements then implement software and plan testing based on the requirements and the System Design.
The good thing in V-model for testers is that it should produce good documentation where the test design can be based. The quality of requirements for designing tests varies, but generally, there is at least a solid basis for test design.
Still, it is very common that the Requirements and System Design documents do not specify exactly how the software should work and how it should be tested, even when a lot of sweat and time is spent on requirements design. That makes sense.
You can not describe all the features before developing the system, and even describing the need in a way that can not be misunderstood is next to impossible. Because of this, the projects where the development mostly tries to only satisfy requirements, not what the customer actually wants, are likely to produce unwanted results.
It is also very common that the written requirements change during the project. The changes are needed, but how the changes are handles often leave room for improvement. The discussion and decision about the changed requirements might not be available to everyone, and when the requirements are available to everyone, it is after a long and expensive process.
Agile Methods
Agile methods, where development and design are done in multiple iterations has become very popular in recent years. Unfortunately, it has not removed all the Software Development and Testing problems.
The customer should be closely involved in the development process for the project to be able to succeed by giving feedback about customer needs. Quite often the customer is simply not involved in the project enough.
The customer who defines the business needs often has also other work to does not fully steer the project development to the direction he has envisioned. Because of this, the development team does not develop what it optimally should.
Very often the projects using Agile methods do not produce enough documentation where the test design can be based. This can be frustrating as if you do not know how the software should work, how can you test it? ( Well, it is possible but not very efficient )
It is essential that testers all the time do what they should do and do it when they should be doing it. On Agile projects with multiple testers, it is not always so clear what has been tested and when, and thus testers end up not testing the right things. The problem can grow worse when people working in the project change.
What Should Be Done Better?
Now that I mentioned all these nasty problems that are pretty common in software projects, should you throw your current way of working away and start using a new one to get these benefits of efficiency I promised? Fortunately no.
You can implement test requirements to any way of working where you define requirements, user stories or such. The main idea is to split your requirements/user stories to smaller units, test requirements, that are easy to maintain.
The benefit from this is that you always have documentation about what you have agreed, but maintaining these is not too time-consuming. The magic behind Test Requirements is that as they are small and intuitive units and they are easy to communicate. Developers, business people, and testers all talk the same language with these.
The Recipe
The first thing to do is to start splitting your Requirements/User stories or whatever your project design will be based on into Test Requirements. Keep the Test Requirements simple, keep them separate. Concentrate the content on what you are going to test.
Keep the Test Requirements relevant – you should not write everything you are going to test. Keeping the relevancy in mind, you can make assumptions about the requirement so Test Requirements can contain more details about the design that the original requirement had.
The Test Requirement should not tell how you test, that information should go in to test cases. Testers are people who know where the problems in the applications lie. They often have a hunch of defects even before the testing phase.
This hunch is by far the fastest way to find defects. Problems can be found even before they are written in the code – the developer will be able to write better code straight away.
For the developer to take Test Requirements into account, he needs to be aware of them. This means developers should ”review” the test requirements before developing that part of the software. When the Test Requirements are kept simple, this review is very easy and does not consume a lot of time.
This review can have the following outcomes:
#1) The Test Requirement assumption was the same that the developer thought at this point. This confirms the detail. Both know what is intended and what should be tested.
#2) Test Requirement assumption was something the developer hadn’t thought yet but is something he agrees on. He will develop the feature according to the Test Requirement right away saving time.
#3) Test Requirement assumption is wrong – the developer will not develop it in the way it is described. This can lead to changing the Test Requirement or even discarding it. No problem, not much time was spent on it anyway.
#4) Developer does not yet know how the feature described in the Test Requirement will work, so he can not say if it is true or not. In this case, handling that testing requirement will be postponed.
Now I have described the discussion between the Tester and the Developer, but how about the person who wrote the Requirements/User stories. As the Test Requirements can contain more information about the system being developed, the original writer of requirements is probably very interested in that information.
Basically, he should do a similar review to the requirements as the developer does. Depending on the project, this review can happen before or after the developer’s preview. The main point here is that when the Test Requirements are good, this review is so easy to do that you get the people to do it.
I promised you agility, but so far this sounds like an extra step, right? The agility comes from the easiness to handle single Test Requirements at a time. You can communicate about features easily, change the way something is working keeping the reason why it is done the same. Test Requirements add the details to the planning at the right time, and on the way that can be changed.
So what about Automation? Can you Automate Testing along with Test Requirements? Definitely! Test Requirements define what is tested, not how. You can map your Automated test cases to Test Requirements as well.
Test Requirements can be implemented successfully in many ways. This presentation is just a framework for the idea. Feel free to pick ideas and use them in a way that suits your way of work the best.
What Are The Benefits?
#1) As Test Requirements are an easy way to communicate about the need, implementation, and testing, it encourages to talk about what matters – how the software will work. This helps people working on the right thing.
#2) The communication with Test Requirements stays in a format that is easy to find later. It is much easier to check a history of one Test Requirement than one user story.
#3) The Design, Development, and Testing are visible to all involved parties. Test Requirements help keep track of what has been agreed on easy to read level.
#4) Progress of Design, Implementation, and Testing is more measurable. Actual requirements can be considered fully developed and fully tested often only at final production release, if even then. That makes measuring by requirements a bit irrelevant. Test Requirements are smaller units and monitoring the progress of them actually tells about the quality and readiness of the development.
#5) Each time you define a relevant aspect of a requirement or user story before development, you have a fair chance to save time from unwanted design, implementation, testing, fixing and building.
#6) Test Requirements are a perfect way to involve a test team to the project early on. You get their expertise to good use in design. Designing test cases from Test Requirements is faster than from test requirements than from requirements, so in some cases, you can get to the testing phase faster.
#7) Having test cases approved by developers and requirement designers allows testers to explain why the defect is a defect. Sometimes defects are rejected as they are not defined exactly in the requirements, but Test Requirements often add the precision which sometimes helps when reporting defects.
Needed Tools For Test Requirements
Implementing the use of Test Requirements does not require a Test Management tool. It just helps. The tool helps to manage Test Requirements as they are split from requirements, searching the information and keeping the changes in the order in multi-user environments.
Also designing test cases from Test Requirements is easy when there is a tool to support it. If you are looking for a Test Management tool supporting test requirements, ensure that requirements can be ordered into a tree and that there is a way to connect Test Requirements to test cases.
Some tools like HP Quality Center and Meliora Testlab give more power to reporting by making difference between Requirements and Test Requirements.
About the author: This is a guest article by Joonas Palomäki. He is working as a Lead Consultant with over 10 years of experience in Quality assurance projects.