Let’s do a test


Don’t worry, we’re not going to take an exam. This is about test management in agile projects. At first glance, test management and agility seem to have little to do with each other. Scrum, for example, recognizes neither the role of the test manager nor of the tester. However, it would be incorrect to conclude that testing doesn’t have a particular value in agile projects. Individual tests, component tests and system tests are indispensable when developing software-intensive systems – even in agile projects. However, they do not all run – like in projects that are orientated on the V Model – as delimited test levels in phases, or successively. In the framework of releases and sprints, the steps with which the implemented features are integrated and tested follow more often and in shorter frequencies than classical processes. But if you cannot orientate yourself on fixed test levels with established responsibilities and roles, how can you decide which tests are required in an agile project?

An answer to this question is given by Marick [1] and, in a bit more detail, by Crispin/Gregory [2] with their concept of test quadrants. It offers a team simple assistance to categorize tests and check if all relevant test sorts have been considered.

Concept of test quadrants

The test quadrants come from two axes: the vertical axis distinguishes between the specialist and technological tests. The horizontal axis spans from the team-supported tests with which the quality of the implementation by the team is examined, to product-questioning tests, which determine whether the developed product corresponds to the expectations of the stakeholders.

With the help of these axes, four test phases can be distinguished:

  • Technical, team-supported tests (Quadrant Q1): These are unit tests and component integration tests. Unit tests are often automatized in programming-language dependent test environments.
  • Specialist, team-supported tests (Q2): This category includes all tests that answer the question: are all features implemented as was required? Here it is also about the function tests with which the fulfilment of the functional requirements is examined. Tests of prototypes and simulations also belong in this category.
  • Specialist, product-questioning tests  (Q3): The focus here is the “business-suitability” of the solution from the viewpoint of the user. Amongst other things, here it is checked that the usability requirements are fulfilled. As well as usability and user acceptance tests, the testing of usage scenarios, alpha and beta tests and explorative tests are also in this category.
  • Technical, product-questioning tests (Q4): All tests that are related to non-functional requirements or quality requirements fall into this category: this includes load tests, performance tests, access tests, data security tests and stress tests that are often executed with specialized test tools. Further tests in this category include those of the solution’s maintainability, scalability and migratability.

Quadrants Q2, Q3 and Q4 have one thing in common: the relevant tests, which are executed manually to a large degree, should answer the question: Does the software fulfil the stakeholders’ requirements? So they are tested “against” the requirements.*

If an agile team have agreed on which development results related to which requirements should be tested, then they don’t “just” have to “collect” and “test” all the related test cases. However, it should happen so that the tests

  • Can be planned and controlled,
  • Are repeatable,
  • Are traceable and remain so.

These aspects of test management – predictability, repeatability and traceability – are a case for software.

The application life cycle management software objectiF RPM supports requirements-driven, agile processes in projects. What is more obvious than expanding functionality to requirements-driven test management? With version 4.1, objectiF RPM has new, corresponding features. The test management workflows are developed user-specifically with the tool. But the foundational principle remains the same.

Create bugs that are planned to be fixed, tested again and execute regressions tests – this is not the whole story of test management with objectiF RPM. But today I will leave you with these first impressions.

[*]Tests in Q1 ask the question: Does the software do what the developers resolved to do? It is answered through unit tests. The expansion of the unit test suite used and the successful run of unit tests are implementation-related tasks that are not located in the context of requirements-based test management. That is why we have excluded it from this post.

By the way, if you want to know more about objectiF RPM, there’s more detailed information here.


[1] Marick, B. (21. 08 2003). Exploration Through Example. From My Agile testing project: http://www.exampler.com/old-blog/2003/08/21/#agile-testing-project-1

[2] Crispin, L., & Gregory, J. (2008). Agile Testing: A Practical Guide for Tester and Agile Teams. Amsterdam: Addison-Wesley Longman.

What makes a successful Project Management process? How do I find the right business process? Which methods are useful? Ursula Meseberg is a graduate mathematician and co-founder of microTOOL. She is fascinated with current trends and has made a name for herself as an author of professional articles.

EN Subscribe to our newsletter
0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published.