Erik van Veenendaal

RE for Testers

Why Testers should have a closer look into Requirements Engineering

Testers use requirements as the basis of test cases, review them for testability, and often participate in general requirement reviews or inspections. Unfortunately, many testers have little knowledge of or skills in Requirements Engineering. What level of quality and detail is realistic to expect in requirements documents? What does testability really mean? How can testers help improve requirements? Testers should be able to answer these questions and, moreover, possess skills in requirements engineering.

Testers often complain about requirements “Can’t test this, not clear, ambiguous” but are themselves unable to answer questions in return such as “What do you think is a good testable requirement?”

However:

• they are one of the main stakeholders -> risk analysis and test designs are based upon requirements.
• they are involved in requirements reviews -> what level of quality is reasonable?
• test designs may even be used as requirements!
• sometimes (in agile) testers identify and specify requirements.
• they have a major interest in requirements and are heavily involved!

Agile

The IT-world has changed and many companies practice some kind of agile development, at least in parts of their projects. Gartner group mentions in its survey “Balancing Agility with Governance -- A Survey of Portfolio Management for Agile IT," that 59% practice agile or at least a combination of agile and traditional development. In agile the tester is even more involved in requirements than ever before and contributes to documenting requirements and its acceptance criteria. A User Story is one of the primary development artifacts for agile project teams. In agile methodologies, requirements are prepared in the form of user stories which describe small functional units that can be designed, developed, tested and demonstrated in a single iteration. These user stories include a description of the functionality to be implemented, any non-functional criteria, and also include acceptance criteria that must be met for the user story to be considered complete. Testers are heavily involved in documenting user stories and its acceptance criteria.

Broadening the tester’s skill set

There are trends in software testing that the (traditional) tester needs to be aware of and respond to. Knowledge and skills will be a challenge in the very near future for many testers. It is just not good enough anymore to understand testing and hold an ISTQB certificate. Testers will not work in a safe independent test team anymore. They will work more closely together with business representatives and developers helping each other when needed and as a team trying to build a quality product. It is expected from testers to have domain knowledge, Requirements Engineering skills, development scripting skills, and strong soft skills, e.g. in communication and negotiation (figure 1).

Test knowledge Test principles Techniques Tools, etc.	IT knowledge Software development Requirements Configuration management
Domain knowledge Business process User characteristics	Soft skills Communication Critical mindset Presentation & reporting

Now understanding that as a tester one needs knowledge and skills in requirements, there are many options. Some testers take a course in Requirements Engineering based on the IREB certification scheme, other course being available as well of course, some practice apprenticing, etc. Whatever it takes to get the job done.

Five success factors

Based on many years of experience in Requirements Engineering, I would like to point you to five critical success factors that I would recommend the tester to start digging into:

1. Requirements attributes

Requirements are much more than “just” the sentence; consider documenting rationale, priority, requirements type, related use case etc. Requirements attributes are properties of a requirement. They capture important additional information about a requirement. Usually the requirements attributes evolve into a card (e.g., user story card) being used in a project or organization (see figure 2). Don’t go overboard, define a practical set of attributes that all have added value.

Requirement #:		Requirement Type:
Description:		Event/Use Case:
Rationale:
Source:
Fit Criteria:
Priority:

2. Requirements acceptance criteria

Acceptance criteria (also called fit criteria) complete the definition of the requirement. We have to be able to tell whether a solution completely satisfies, or fits, a requirement. Acceptance criteria will make requirements measurable. It is often much easier to add concrete acceptance criteria than to write a 100% unambiguous requirement. Acceptance criteria in some way detail the requirement.

3. Requirements rules

The discussion on “what are good requirements?” is endless. Of course it depends on the context but most importantly it needs decisions. A concrete and usable requirements rule set should be defined that leads to “good enough” requirements in your context. Discuss and define rules on issues such as identification, annotation, changes, consistency, language, brevity, unambiguity, rationale, quantifiability and use of compound requirements.

4. Requirements templates

Instead of re-inventing the wheel over and over again, use templates when defining both functional and non-functional requirements. They provide consistency and contribute greatly to a higher level of clarity. It is even more efficient, so why not tomorrow? For stories typically the following format is applied “As a <role>, I want <goal/desire> so that <benefit>”. Other common templates include:

• The <stakeholder> shall be able to <capability>;
  e.g. “The order clerk shall be able to raise an invoice”
• The <product> shall be able to <action> <entity>;
  e.g. “The launcher shall be able to launch missiles”
• The <product> shall <function> <object> every <performance> <unit>
  e.g. “The coffee machine shall produce a hot drink every 10 seconds”

5. Requirements reviews

Reviews are by far the most effective and efficient quality assurance measure to find defects. However, this is only true if applied well. Balancing “practicality vs. theory” is very important here. Understand the difference between a walkthrough and inspection; these are different processes, with different stakeholders and different objectives. Start with your objectives and define a review process that matches these objectives.

The IT world is changing and testers need to change accordingly. Testers need to broaden their knowledge and skills. One of the most important and common additions is to get involved in Requirements Engineering. The five success factors have shown themselves to be a great way to get started and to get involved.