The explicit role of testing and testers in agile projects

Posted on Posted in Agile, Dashboard, Smart, Smart use cases, Testing, User stories

Not all agile processes and approaches recognize the role of testing explicitly, other than stressing the importance of unit testing. However in short iterative projects, testing is key from day one.

On of the agile approaches that does explicitly describes the role of testing – and of having testers on-board – is the agile process Smart. One of the characteristics of this process is that its main unit of work is the smart use case. Smart specifies the life-cycle of a smart use case. By default it includes design, test design, development, testing, rework and acceptance.

Smart use cases versus user stories

In many projects additional stages are introduced. In my current project the explicit importance of testing is easily visualized in the following dashboard.

Dashboard from my current Smart project

All smart use cases go through this life cycle. This is a rather different approach than working with user stories. At the start of an iteration in Scrum (yes, I know iterations in Scrum are often referred to as sprints) each chosen user story needs to be split up in individual tasks. Due to the heterogeneous character of user stories, this is a repetitive activity. Smart use cases are a much more standardized unit of work, and thus can go through a standardized life cycle, without the need to split them up further.

Test stages in implementing smart use cases

From the picture it might not be all that clear, but in our current project our smart use cases go through 5 testing stages:

  • Unit testing. A developer implements (in stage Working) the code for a particular smart use case. Next to developing the code, the developer also implements the unit test for the smart use case. These unit tests are vital for regression testing the use cases (at each build).
  • Developer testing. Right after the developer finishes working on a particular smart use case, he moves the post-it to the stage developer testing. Here another developer picks it up and runs the use case to avoid basic mistakes.
  • Testing. Next the smart use case is moved to the Testing stage. Here a tester compares the smart use case implementation to the design. In most cases the tester will use a process cycle test, or a use case test to identify test scenarios and write test cases.
  • Acceptance testing. When the tester has declared the use case ok, acceptance testing is performed by the domain experts in the project. Due to the limited availability of the domain experts in most agile projects, it’s the tester who does most of the work. Acceptance testing becomes a lightweight black box test.
  • Approval testing. Last but not least, twice per iteration the newly accepted use cases are presented to the end users. The end users approve the smart use cases as soon as possible.

When an anomaly is found during either one of these stages, the smart use cases are moved to rework, validate the possible change. After that the smart use case re-enters the regular cycle.

This approach ensures high quality code and totally removes the need for extensive user acceptance testing at the end of a project.

2 thoughts on “The explicit role of testing and testers in agile projects

  1. Thanks for posting a concept cycle of how to implement certain things when working on a project. The steps I usually used were kind of similar but not identical. This one is much more detailed and better.

Comments are closed.