Continuous Requirements Engineering part 2/2
This is the second part of a two part blog by Bogdan Bereza. Read the first part here >
Test analysis helps the requirements process
Testers have complained for a long time that testing starts too late in projects. It is much more than just a testing problem, though, because it means, that huge potential, which test analysis and design have for radically improving requirements, is not used.
Asking uncomfortable question
By asking uncomfortable questions, which testers should remember to do even after midnight , unless they want to be co-dependent , even high-level, vision-related requirements can sometimes be contested. “Why on earth would anyone ever want to do this?” – an exasperated tester may ask and, being the first person to really use an implemented system, discover that some assumed system goals are impossible and wrong.
Re-defining stakeholders
Test execution – as our exploratory colleagues often righty stress – is a perfect opportunity for designing more test cases. This of course entails asking many “what if” questions. What if an unauthorized person gains access to this data? What if the receiving system is down? What is an infant presses this button not once, but many times? Both test design and test execution – including test result evaluation – provide ample opportunities for discoveries, for re-defining stakeholders, system and system context boundaries.
Exploratory requirements elicitation
What is misleadingly called “exploratory testing”, is really exploratory requirements engineering plus requirements-based testing.
Crazy idea? Not at all. Initially, exploratory testing was invented to cope with situation where requirements were poor, or missing altogether. The main techniques promoted by exploratory testing are creative guesswork concerning what the tested software should do, finding out stakeholders’ real priorities, finding quality attributes most important in a given context, where testing takes place. It is requirements elicitation on the fly, followed by a fast analysis in order to do best testing possible – isn’t it?
Well, it is. Exploratory approach is really great, when there are no requirements, or they are not trustworthy, or not complete.
The clinching evidence is HTSM (Heuristic Test Strategy Model), created by James Bach to help exploratory testers choose the right strategy fast and correctly. Like its more comprehensive predecessors, ISO 9126, FURPS and ISO/IEC 25010:2011, HTSM is first of all a list of quality attributes – or requirements types – to be taken into account. Of course, this is necessary, for an exploratory requirements process.
Discovering forgotten requirements
Designing test cases, additional “what if?” questions are asked. To some of them, there is no answer ready – you have to go and ask someone. This is a very powerful motive for finding more requirements. For psychological, technical and social reasons, such stubborn asking and questioning comes naturally while preparing tests, but can be judged pushy and somehow illicit in the early stages of requirements elicitation. It is therefore obvious that test analysis and test case design should be done simultaneously with requirements work, not later nor much later, which is still common in IT projects.
Requirements analysis, modelling and breakdown
Requirements elicitation, analysis, modelling and specification are not four distinct process stages, performed sequentially, but rather four small steps, performed many times on the way from some mumbled stakeholder’s comment to the final, well-formulated, validated and accepted full-fledged requirement. Even in sequential development, requirements engineering is iterative. You hear some vague statement, you put it down hastily, go back home, give it a thought, draw a simple picture of what you think it means, go back to the stakeholder, or to another stakeholder, to ask again, many times, until you are really sure. This may include prototyping, or any other form of iterative/agile activity. An important element of this process is formulating your thinking along the following lines: do you really understand what the stakeholder means? How can you check that the implemented system fulfils this requirement?
Controlling requirement’s testability is the single most important criterion for breakdown process: if you do not know how to test it, you need to break it down further.
Requirements verification and consolidation
To verify and validate systems, you test them (dynamic testing). You do not want to test too much, because it costs time and money, but you are not willing to risk testing too little, because it increases the risk of failures in operation. To be able to test as little as possible without risking too many and too serious failures, you need to build systems from good requirements, following a reliable development process.
Whatever the right amount of testing, you do not want many bugs – whether caused by wrong requirements or by implementation mistakes – to make their way to testing, because removing them after testing is more expensive, often much more expensive, then avoiding them or finding them in requirements stage (yes, this is Boehm’s curve).When building a bridge, you prefer finding bugs in its blueprint, to crashing the whole reinforced concrete construction during load test a week before admitting traffic to it. The same applies to software.
That means, testing requirements is the most effective way of both not needing to test the system build from them too much, and not having too many bugs in it, either.Professional testers, who have special testing skills, should be involved in requirements verification just as they are involved in dynamic testing. It is today generally accepted that testers help programmers test software, so consequently, it is time to promote the idea that testers should help requirement engineers test requirements.
Designing test cases from requirements (the test cases to be used in the future, during dynamic system test), the design process itself is a very effective way of testing requirements. In other words: designing dynamic tests from requirements is a great way to perform static requirements testing. Increasing the amount of time spent on testing requirements, you decrease the time required for system testing, which is – up to some level – an extremely profitable deal.
Through testing towards new requirements
Whether you work iteratively or sequentially, development projects are just steps in IT product’s lifecycle, which is always iterative and incremental, whether you have chosen this or not. Market research, and operational monitoring and maintenance are main sources of new business ideas and therefore new requirements; testing is the second main source. Testing generates a lot of new ideas and improvement suggestions, which are often wasted, unless you treat testing as requirements elicitation for the next project, and find ways to gather new ideas and use them later.
Requirements engineering is not a project phase, but a never-ending lifecycle activity, and the activities traditionally classified as testing really belong to it.Bogdan BerezaBook your course on one of Bogdan’s courses!