Communicating test status, progress, and product quality

Change takes place rapidly in Agile projects.

This change means that test status, test progress, and product quality constantly evolve, and testers must devise ways to get that information to the team so that they can make decisions to stay on track for successful completion of each iteration.

In addition, change can affect existing features from previous iterations.

Therefore, manual and automated tests must be updated to deal effectively with regression risk, because Agile teams progress by having working software at the end of each iteration.

Monitoring progress

To determine when the team will have working software, they need to monitor the progress of all work items in the iteration and release.

Testers in Agile teams utilise various methods to record test progress and status, including test automation results, progression of test tasks and stories on the Agile task board, and burndown charts showing the team’s progress. These can then be communicated to the rest of the team using media such as wiki dashboards and dashboard-style emails, as well as verbally during stand-up meetings.

Using tools to generate status reports

Agile teams may use tools that automatically generate status reports based on test results and task progress, which in turn update wiki-style dashboards and emails.

This method of communication also gathers metrics from the testing process, which can be used in process improvement.

Communicating test status in such an automated manner also frees testers’ time to focus on designing and executing more tests.

Burndown chart

Teams may use burndown charts to track progress across the entire release and within each iteration.

A burndown chart represents the amount of work left to be done against time allocated to the release or iteration.

An example diagram of a burn down chart, where points on the Y axis are plotted against days on the X axis. Point numbers are plotted on the graph, with lines tracking remaining points and ideal velocity.

Figure 1: A burndown chart

Task board

To provide an instant, detailed visual representation of the whole team’s status, including the status of testing, teams may use Agile task boards.

The story cards, development tasks, test tasks, and other tasks created during iteration planning are captured on the task board, often using colour-coordinated cards to determine the task type.

During the iteration, progress is managed via the movement of these tasks across the task board into columns such as to do, work in progress, verify, and done.

Agile teams may use tools to maintain their story cards and Agile task boards, which can automate dashboards and status updates.

Testing tasks

Testing tasks on the task board relate to the acceptance criteria defined for the user stories.

As test automation scripts, manual tests, and exploratory tests for a test task achieve a passing status, the task moves into the done column of the task board.

The whole team reviews the status of the task board regularly, often during the daily stand-up meetings, to ensure tasks are moving across the board at an acceptable rate.

If any tasks (including testing tasks) are not moving or are moving too slowly, the team reviews and addresses any issues that may be blocking the progress of those tasks.

The daily stand-up

The daily stand-up meeting includes all members of the Agile team including testers.

At this meeting, they communicate their status.

The agenda for each member is:

What have you completed since the last meeting?
What do you plan to complete by the next meeting?
What is getting in your way?

Any issues that may block test progress are communicated during the daily stand-up meetings, so the whole team is aware of the issues and can resolve them accordingly.

Customer satisfaction surveys

To improve the overall product quality, many Agile teams perform customer satisfaction surveys to receive feedback on whether the product meets customer expectations.

Metrics

Teams may use other metrics like those captured in traditional development methodologies, such as test pass / fail rates, defect discovery rates, confirmation and regression test results, defect density, defects found and fixed, requirements coverage, risk coverage, code coverage, and code churn to improve the product quality.

As with any lifecycle, the metrics captured and reported should be relevant and aid decision-making. Metrics should not be used to reward, punish, or isolate any team members.

When you are ready, select Next to continue.