4 Habits of Highly Effective Software Testing Teams

software testing teamsEffective 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:

  1. Good test management and reporting
  2. Working closely with development
  3. Getting involved in technical activities
  4. Building credibility with business stakeholders

Let’s dive into these traits:

1) Test Management and Reporting

There are two common views regarding the role of test management.

  1. One holds test management responsible for reporting project status to higher management, as well as performance reviews and resource allocation.
  2. 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.

Technical testers are able to work directly with programmers to design and create automated tests. Rather than the typical code, test, automate lag most companies experience, features created by a developer and tester pair are committed to the source code repository along with a set of tests. Technical testers frequently work in the continuous integration to get automated tests running after each new product build, or in debugging problems to propose fixes, adding an additional service to the delivery team. Technical testers have a range of skills that starts with being able to open the javascript console to review errors, to writing SQL statements,  all the way to writing production quality code.

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

More Great Content

Get Started with qTest