How to motivate the testers in your team (and keep them motivated)

In many IT projects you will often end up in a situation where it’s time to retest bug reports. Integration tests and system testing will all be completed but the system is not ready for acceptance testing just quite yet so the next ten weeks will be dedicated to the retesting of bug reports. Depending on the development process you normally work in, these ten weeks will be called different things; in Agile, for example, they may be 5 sprints of 2 weeks.

The million dollar question here is “How does a test manager keep their test team highly motivated during this phase?

Many people want to have interesting and challenging tasks to carry out. Experienced testers will very often find that the newly developed features are both interesting and challenging to work but at the point when all the tests have been run and the only thing that remains is the retesting of bug reports, levels of motivation may very well fall.

While it may not feel like a very challenging and engrossing portion of the tester’s work, retesting of bug reports is a very important portion of work indeed. For a tester with less experience retesting may be a great way to learn about the system and thus gain useful knowledge for future projects.

So, how do you motivate the testers in your team and keep them motivated?

1 – Set clear goals

Different people are motivated by different things, therefore it is important to find out what motivates your specific employees. It is also important to set goals that everyone in the team can jointly work towards achieving. One goal may be that in time for an agreed upon week’s end there may no longer be any bugs of the highest priority. If the goal is met you can celebrate it with a fun activity for the team or a cake for coffee break, or given that it is Friday, beers in the office. Ask your employees what motivates them and then take the initiative to make the work as varied as possible.

Another way to make retesting fun can be introducing exploratory testing for each bug report to further ensure that the errors truly are rectified and any new errors have turned up in testing. This is done by testers not only testing the scenario in the bug report, but also testing around the scenario.

2 – Increase task variety

To further increase the variety of work, the test leader can let one of the team members at a time focus on other test tasks for a few days, on condition that other testers do not become overloaded with bug reports. The tester who is not retesting  bugs can review the test cases for the last time and ensure that they truly are up to date. Questions such as “Have we covered all the necessary test cases based on the functional and non-functional requirements?” and “Are the test cases ready to be handed over to maintenance?” will need to be answered.

Another task could be to perform an additional regression test round of some test cases. If there are many bugs in the same system area and consequently many patches, it may be important to test through that area again using regression test cases. This is to ensure that new bugs are not introduced.

3 – Hold an exploratory bug bash

In the middle of the retest period it may be advantageous to do something with all testers to strengthen the team spirit. If many bugs have been fixed, it’s a good idea to ensure that no new errors occurred or that the quality of the system has deteriorated. An activity that is good for the quality, motivation and team spirit is to have an exploratory bug bash.

This can be done by setting up a two day session-based testing event based on various test assignments. Planning a bug bash is everything; ensure that time is used as well as possible during the two days. Prepare the tasks, hardware, software, test environment, test data and ensure that the right equipment is available. Book a meeting room where you can sit undisturbed and lay out a schedule for the day with sessions, breaks, lunch and time to report the bugs you find. If you have new testers in the team, hold a presentation on session-based testing for them a few days before so they know the objectives for the two bug bash days.

On the first day, hold a short presentation about what the goal for the days is. Make sure that everyone gets a little time to go through their tasks so they have what it takes in terms of test data, equipment etc. before the first session begins. When the first session begins, all testers should be able to start testing immediately. There must be time to report bugs found after the session. Although bugs can be noted during the session, they must also be reported according to the project’s bug tracking process. Between each session, it is good to stretch our legs before it’s time for the next session. All assignments should be prioritized and when a tester is finished with his mission after a session, he takes the next task with the highest priority. If a tester is not finished with the task during a session, he or she should continue with the same task during the next session.

4 – And after the bug bash…

When the two days are over, some new bugs will certainly have been found and there will be a need to prioritize them. The test leader will now have a clearer picture of the quality of the system and how the bug fixes have affected the system. It’s time for the testers to return to retesting but they will hopefully be more motivated to test for a few more weeks.

If it turns out that some parts of the system are of inferior quality, it is good to set up a smaller bug bash for maybe two of the testers. They can perform exploratory testing only within the specific problem area in order to further ensure the quality and to find possible errors.

After a bug bash it is an advantageous to hold a retrospective meeting where testers can participate and speak up about what was good and what was not so good so you next time know what to keep as it is and what to improve.

Summary

• Find out what makes your employees motivated.

• Select test activities that make the work as varied as possible during less challenging phases of a project.

• Have an exploratory bug bash.

• Serve coffee, it’s a classic that usually works.

The next step

There are also a number of other blog posts about agile work that might be of help to you. A few examples are “Is the test leader needed in the Agile world?” and become more exploratory with pair testing.