A couple of weeks ago, the Sydney testers meet up group got together to talk about how to introduce testing to an organisation. Drinks were had (thanks SoftEd!), stories were shared, debates were had and friendships were formed. Here are a few of the points that I took away from the discussion.
Introducing testing is not just about introducing testers
Introducing testing to a new team means changing the way the team develops software. It’s not enough to simply add testers and expect testing to happen. Integrating testing into the software development lifecycle is something that involves the way every team member works.
Authority is important
If you are to be a catalyst for change, you need enough authority to be able to instigate the change. Often this kind of authority can come with being an outside consultant. It was noted that sometimes the fact that you are being paid a huge sum of money in order to introduce new practices can lead to you having a stronger voice in the organisation. Being a contractor can have similar advantages. It was discussed that, as a contractor, you’re less affected by the politics of the organisation and this enables you to introduce change more easily.
Developers can test too
There was some debate about the difference between testers and developers, and how to tell if someone is “destined” to be a tester versus a developer. Testers can program, and developers can test, and it’s beneficial for both testers and developers to have these skills. The difference is the individual’s personal preference, and level of skill in these areas.
The value in testing isn’t always readily apparent, especially to high-level managers. Demonstrating the value in testing activities is an important part of introducing testing to an organisation. Metrics such as bug counts can be used to help show value, but they can also be misused. For example, if testers help developers to improve their own testing skills then the amount of reported bugs may decrease, and this would look bad for a team that uses bug reports as a metric to show test team effectiveness. For this reason it’s important to demonstrate that testing is more about preventing bugs than finding bugs.
To automate or not to automate
Introducing automated GUI tests is a project risk, and is an activity that is often underestimated in terms of time cost and skill requirement. There is always a maintenance cost that needs to be considered when introducing automated tests. Automation metrics can also be easily misused. On the other hand, if considered well, automated testing can be a valuable asset to many software development teams.
The tester mindset
Testers do need a negative mindset to perform some kinds of testing activities. But good testers need to be able to switch out of this mindset at will or they’ll just become unpleasant to work with, and this is not good self-marketing for the testing team.
A few follow-up topics were suggested, including “how to recruit testers” and “how blurred should the line be between testers and developers?”
You can find information on upcoming Sydney Tester Meetups on the meetup homepage.