What is the journey from 'Waterfall' to 'Agile'?

This story originates in the decision by project management to set up the development process with Agile in mind.

This calls for a test process that has been adapted to Agile, and a test process which is more integrated with the development process. In the mapping of the new process we have used our knowledge of TMap, TMap HD, the book “TMap in Scrum” and our knowledge of Agile and Scrum.

User story

Our first step in drafting a new approach was defining a user story for the test process. This is to ensure that our goals are clear to all concerned. It also gives us a foothold to assess our own process critically. The test process will also have to comply with all predefined acceptance criteria before it can be classified as "Done".

User story test process

Now that the purpose has been established, we want to compose some basic principles and values the "new" process has to comply with. The tools of the book ”TMap NEXT in Scrum” and our interpretation of the Agile Manifesto formed the input for drafting the principles and values. Next we have categorized these values on the basis of the four elements of TMap HD. This way of working has given us the necessary tools to present and communicate our intentions and process clearly.

The TMap HD elements


Just enough documentation

  • Each defect is discussed immediately with the developers, after which all involved decide on the severity and on the period within which there must be a solution. Only defects that are not resolved the same day are documented.
  • The required tests are specified in logical test cases only and worked out no further.


  • For each meeting a timebox is agreed upon in advance. This should prevent the meeting being bogged down in details and therefore be unnecessarily long, without adding value. This is consistent with the LEAN philosophy to minimize waste.
  • After the appointed time, the meeting is suspended, a follow-up can be scheduled, if deemed necessary.


Automated regression

  • The regression test is automated using Selenium IDE. After each deployment / drop on the test server this test is performed to validate the quality of the most critical parts.
  • There is a fixed point in the test process, at which the regression test set is maintained and the most important new tests are added.

Automated test design

  • We use tooling, such as COVER, to automatically generate logical test cases.


Early involvement in development process

  • By evaluating User Stories and screen designs we get involved in the design process. This should ensure the quality of the translation from requirements to actual functionalities.
  • We get involved in the development process by providing support for the preparation of unit tests and by evaluating these tests.


T-Shaped individuals

  • Besides our test work, where our expertise lies, we contribute to drafting the requirements.
  • We are a good sparring partner in the preparation of user stories because of our knowledge of the requirements and business process. 
  • Our knowledge of testing helps developers in the preparation of unit tests. Through this involvement, we are expanding our technical knowledge.


  • To ensure the success of this process, we need the input and cooperation of the entire team.
  •  All stakeholders can influence the severity and priority of the tests.
  • We can influence the design and the development.

Now that we defined these values we are ready to implement this new approach. In our next blog we will explain which building blocks we have used to acheive this.

Kristel Beekmans and Thomas Vink are test engineers working for Sogeti