QASymphony / Blog / 4 Habits of Highly Effective Software Testing Teams
4 Habits of Highly Effective Software Testing Teams
Effective software testing teams work collaboratively with other teams, staying involved with a project from the initial concept to the end. They have “flow” that is relatively predictable.
Less effective software testing teams inadvertently cause their own problems; they might hold back involvement until “code complete,” or work on large batches of features at a time. This can happen for many reasons; weak test management, credibility or trust problems between testers and developers, or just inertia, following the same practices that worked well enough fifteen or twenty years ago.
While broken teams can be broken in many ways, high-functioning teams tend to have a few things in common. Over time, they tend to manage the work better, work more closely with development teams, have more technical skill, and work to develop credibility.
The most effective test teams have several traits in common, including:
One holds test management responsible for reporting project status to higher management, as well as performance reviews and resource allocation.
The other point of view, the one that supports the software testing team and company goals, wants test management to have a servant role. In this case, the manager is responsible for coaching and mentoring team members, and removing any impediments to getting work done. In that world the value of management is the increase in value they create for the technical staff, something Andy Grove, co-founder of Intel, defined in his landmark book “High Output Management.”
Effective test management looks much more like view 2. These managers work closely with the test and development team to observe blockers, and facilitate anything they might need to be productive. The days of the detached, disengaged test manager are over.
2) Work Closely with Development Teams
When programmers and testers work as separate teams, the first part of the release cycle is dominated by programmers writing new software; testers bide their time until they are given the first pieces of functionality. New code may be high quality when programmers use design tools like test driven development and behavior driven development.
However, if they don’t test first the first build can be problematic. Creating a stumbling cadence where the testers and programmers spend time passing code back and forth. Finding only the low hanging fruit: pages that fail to submit, error messages caused by bad date formats, and problems that occur when entering too much text in a field.
Testers that work closely with programmers, perhaps by pairing — having two people work together on one task, can find these simple problems while the new code is still being developed. When a new test build is available, the test team can spend time finding deeper and more important problems since the easy problems never made it past the programmer’s computer.
3) Get Involved in Technical Activities
By working together problems are found earlier, and eventually, even prevented. With higher quality initial builds, work that would have required multiple testers to perform mass inspections for days, may now only take a few hours for one person. Better builds mean there are fewer traditional software bugs to be found — errors from submitting unicode, long strings, characters in a text field, bad date formats, etc. Testers will have to find a deeper place to contribute, often by becoming technical.
4) Build Credibility with Business Stakeholders
Good test teams have credibility with the technical and management team.
Part of software testing is learning the skill of creating a bug report in the form of a persuasive essay. Every bug report is designed to persuade a decision maker that this code change is more important than some other piece of development work. Many testers spend time in meetings providing additional information about the reported problem, and arguing that this bug should be fixed first.
Testers with credibility don’t experience this problem. These testers have trust and respect in their teams to the extent that their decisions, observations, and judgements (within reason) are not questioned. When credible testers discover and take the time to report a problem, programmers and managers take them seriously and fix the problem. These testers also get approval for projects they want to work on and approval on resource requests without long discussions. Developing credibility with a development team, and management, can mean more bugs fixed and less time debating about what is important enough to fix right now.
Most teams can benefit from improvement on one of the four – so pick the weakest one and work at it – and let us know how it goes on twitter @QASymphony!
The State of Test First Methodologies 2016– Hundreds gave their thoughts and the results are in. Download your free copy.