On the 23rd January 2019, I gave my very first 99 second talk at the #MidsTest meetup in Birmingham. This blog post is inspired by the talk I gave. 

I once had a case where an automated test had failed. After some investigation, it was found that this had been due to a new bug that had been introduced to the software. While discussing this new defect, one of the developers jokingly said, “You didn’t find this bug, the automated test did”. In reply, someone else said “Yeah, but Louise designed the test”.

This made me think: Who did find the bug?

Multiple automated test tasks that lead to bug discovery

There are so many tasks involved in test automation, including:

  • Developing test automation framework
  • Developing automated test cases
  • Maintaining automated test cases and framework
  • Selecting which automated tests to run
  • Analysing test results, and investigation of failed tests

Which of these tasks led to the discovery of the bug? If these tasks were run by multiple people, then no single person can claim to have found the bug.

If the automated framework did not exist then the test case itself could not exist. If the test case was not run, then there there is a chance that the issue may have remained unknown to the test team. Once a potential error was known to the test team, then there would not have been any additional investigation or exploratory testing carried out to find the precise details of the bug.

In my experience, an automated test rarely ‘finds’ a bug but only highlights areas of concern within the application. The precise details of the bug only become known once someone has analysed the test results and investigated the source of the failure.

How about bugs found using Manual Testing?

If the testing strategy includes a combination of manual and automated testing, then credit should not only be given to the manual tester. The inclusion of automated testing can help free up additional manual testing time. This often leads to increased test coverage, and more defects being found. Just like bugs found due to an automated test failure, it is a combination of testing activities that led to the bug being found.

There are some test teams who rely solely on manual testing. In these cases, effort should be focused on ensuring that all areas of the application receive adequate test coverage instead of finding as many bugs as possible. Bug hunting should be a team sport, and teams are not in competition with each other.

But it is the developers who fix the bugs….

The testers may be the ones who find the bug, but it is the developers who fix the bug. Of course, the developers wouldn’t know about the bug in the first place if it wasn’t for the testers.

Developers and testers should work together to improve the software. There are some who feel that developers are the ones who create the bugs and they need testers to help fix their mistakes. Others feel that testers are just trying to find bugs and problems with the software. These are both very dangerous mindsets to have.

Both parties want the application to work, and to be fit for purpose. This can only be achieved if the developers and testers work together. It is through collaboration between the test team and development team that the quality of the software is improved

Take responsibility, not credit

Recognition for hard work is essential, however it should also be recognised that more defects can be found by combining the skills of the testing team.

Quality is the responsibility of the entire team – testers and developers. Each member should make use of their particular skill sets to benefit the team and the software. Finding and fixing defects is one of the best methods for improving the quality of the software.