Successful management techniques to empower software QA teams

A key concept of agile software development is the release of software in short development cycles, which creates feedback loops that will become more shorter and productive the more an agile team works together. A project manager (called a “Scrum Master” in Scrum) is responsible for facilitating and making life easier for the entire agile team, which can include developers, testers, business analysts, and other project stakeholders.  The project manager does this by obtaining the necessary resources for the team and solving problems that can crop up on fast-paced development projects.  The role of the agile project manager doesn't generally include technical activities such as planning and scheduling, which are better left to the team as a whole. 

Testing is crucial to successful agile development, especially if your team is practicing test-driven development, since this is how flaws are detected and eliminated before the software is deployed.  On an agile team, testing is the responsibility of the whole cross-functional team and not relegated to a few Quality Assurance specialists.  If something goes wrong on an agile project that results in buggy software, the whole team will brainstorm what's wrong with the testing processes. Here are five management techniques that are useful in building consensus in a fast-paced environment on the best ways to improve your software testing efforts.

1. The wary of testing best practices--especially those that overemphasize documentation.

Software teams can often be sidetracked by following "cookie-cutter" best-practices, such as those meant to define the order of testing on an agile project or the best way for one team to communicate with another.  There's no one perfect way for a team to be agile or to do agile software testing, which is why agile is defined in the Agile Manifesto by its principles rather than by specific best practices.  One of those principles is "working software over comprehensive documentation," which means agile projects shouldn't get bogged down by checklists and documentation when work is handed off from one group to another.  Agile project management focuses on continuous improvement, scope flexibility, team input, and delivering high-quality working software rather than documentation.

Context-driven testing is a testing approach that attempts to take into account the ways in which the software is expected to be used in the real world.  Members of the "context-driven" school of testing believe that there are no "best practices" of testing, but rather that testing is a set of skills that allow the tester to choose or create testing practices to suit each unique situation. (For example, the testing practices used to test airplane control software will be much different than that used for testing gaming software.)  Other basic principles that context-driven testers follow include the following:

  • The value of any practice depends on its context.
  • People, working together, are the most important part of any project's context.
  • Projects unfold over time in ways that are often not predictable.
  • The product is a solution. If the problem isn't solved, the product doesn't work.
  • Good software testing is a challenging intellectual process.
  • Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products. 

2. Pay attention to your team's velocity--especially if your QA team members complain of overwork.

Velocity is an agile measure of how much work a team can do during an iteration.  The metric is designed to help teams estimate how much work they can complete in a given time period based on how quickly they've completed similar work.  Velocity is measured using a unit chosen by the team, either a real unit like engineering hours or engineering days or an arbitrary unit like story points used by scrum testing teams.

At the beginning of an iteration, each agile team estimates the work that they're about to do in terms of the units they've chosen.  The team also chooses the interval or duration of each iteration for which the velocity will be measured. (A common interval is a week).  To calculate the velocity of your agile team, you add up the estimates of the features, user stories, requirements or backlog items successfully delivered in an iteration. It usually takes a few iterations for velocity measurements to stabilize since teams often find that they've "bitten off more than they can chew," or have overestimated their capacity to deliver a feature.

Once the velocity measurement is stabilized, each team can accurately estimate the amount of work that they can do in the current iteration by assuming that they can achieve the same amount of work as the last iteration. This allows project managers to track the amount work left to do on a project versus the time left to do it using tools such as burndown or velocity charts.  If you're overloading QA members with work, there is a good chance you have a logjam created by trying to deploy too many units of work per iteration.  Lowering the work estimate per iteration should improve the stability of your deployment process and increase team velocity going forward, which can be verified by the burndown or velocity charts.

Team velocity can be measured by a burndown chart

Image Source: Pablo Straub 

Team velocity can also be measured by a velocity chart.

Image Source: TechBudha

There are three main points to remember about agile team velocity:

a. Velocity is not a direct measure of productivity.  You can't compare the velocity of two different teams because the two teams are being measured in different, arbitrary units chosen by each team. Say, for instance, you have a QA tester who has had experience doing performance and functional testing for Big data sets using Hadoop or MapReduce tools.  The work estimate for how long it takes that team to deliver some specific Big Data functionality per iteration will be considerably shorter than another agile team that doesn't have the same testing experience.

b. Your velocity measurement needs to be recalculated when new members are introduced to the team since it takes time to bring the new member "up to speed" on the code base and the overall development and testing processes used by the group.

c. Similarly, if new technology is introduced to the team (such as replacing an enterprise DBMS with a Hadoop cluster), then your team's velocity measurement should be recalculated.

3. Pair Testing

Knowledge transfer via pair testing is one of the most efficient way to train new members and maintain agile team velocity, assuming your team has senior testers or developers who are willing to share their knowledge and time with new team members. Pair testing is similar to pair programming, which is an agile software development technique in which two programmers work together at one workstation.  In pair testing, two team members work together at one keyboard to test the software application. One does the testing and the other analyzes or reviews the testing. This can be done between a tester and a developer or a business analyst or between two testers with both participants taking turns at driving the keyboard.  Pair testing is useful in breaking down communication barriers between developers and testers and creating interdependency between people in functional silos– thus building strong workplace alliances.

4. Be wary of too much consensus on your agile team--remember the importance of the "devil's advocate" role.  

Because of the desire for fast consensus among self-organizing agile teams, there's a risk that collaboration will devolve into groupthink among close-knit agile teams.  Defined in the early 1970s by research psychologist Irving Janis, groupthink refers to the social phenomenon by which groups limit themselves by developing internal norms that minimize conflict and discourage independent thinking.  Symptoms of groupthink on an agile team include team members who are consistently in agreement with little discussion during daily standups, iteration planning or review meetings. 

According to this Wikiversity definition: "Groupthink is a type of thought exhibited by group members who try to minimize conflict and reach consensus without critically testing, analyzing, and evaluating ideas."  A QA tester, especially one that practices freestyle exploratory testing, can combat this tendency toward groupthink on an agile team by playing the role of critical evaluator or "devil's advocate," and asking tough, "what if"-type testing questions that challenge the rest of the team's decisions and choices.

5. Recognize and Improve Your Team's Feedback Loops 

Feedback loops that Agile XP programs follow

Image Source: DonWells

A feedback loop is the time between when a developer writes a line of code and when someone or something executes that code and provides information about how it behaves.  If software isn’t tested until the very end of the release cycle, as it is in traditional waterfall development, the primary feedback loop can be measured in months. (See Release Plan detail in the figure above.)  Luckily, with agile test management the software is ready to test almost from the time the first line of code is written. And agile teams typically employ several levels of testing to uncover different types of information. 

If your team is practicing pair programming, then the observer member of the developer pair should be doing code review, which is intended to improve the overall quality of your software as it's written. Pair programming is a form of feedback, since developers will constantly discuss the best available options with each other.  The length of this feedback loop is very short, typically just seconds or minutes.  After the code is compiled, automated unit tests check the behavior of individual functions/methods and code interactions. They’re run often, and provide feedback in minutes.  Similarly, automation integration, system and acceptance testing that check the behavior of the system end-to-end will provide feedback in minutes. 

The length of the feedback loop for pair negotiation, or pair testing (see above), can usually be measured in hours.  Issues raised during pair testing can then be discussed at daily standup meetings, which make up their own feedback loop.

Manual testing, particularly manual exploratory tests, take longer to schedule and perform because a human must be available to run them.  Also, since exploratory testing is done in a more freestyle fashion than scripted testing, it takes time for the manual tester to design these tests, as well as any follow up tests needed to confirm the initial test results. The feedback loop for manual acceptance tests can usually be measured in days. 

Finally, the feedback loops for iteration planning (see velocity discussion above) and release planning are usually measured in weeks and months. 

The shorter you can make any or all of the feedback loops, the more your team will benefit since these loops enable agile teams to learn fast and adjust.  Similar to the way your team can increase overall team velocity by normalizing its workload between developers and testers during iteration planning, optimizing each of these individual feedback loops will help your team deliver higher value with better quality--and at a much faster pace.

Learn more about other company's approach to QA success by attending the upcoming session of Atlassian Summit 2016– The Future of QA at Atlassian.

Related Articles: