Crispin, Lisa - Agile Testing - A Practical Guide for Testers and Agile Teams

Beware the Quality Police Mentality

Be a collaborator, not an enforcer. It might bug you if programmers don’t follow coding standards, but it’s not your job to make sure that they do so. Raise your issues with the team and ask for their help. If they ignore a critical problem that is really hurting the team, you might need to go to your coach or manager for help. But do that in a “please help me find a solution” vein rather than a “make these people behave” one. If you’re seeing a problem, chances are high that others see it too.

Vote with Your Feet

You’ve been patient. You’ve tried every approach you can think of, but your management doesn’t understand agile development. The programmers still throw buggy, untestable code “over the wall,” and that code is released as is despite your best efforts, including working 14-hour days. Nobody cares about quality, and you feel invisible despite your best efforts. It might be time to look for a better team. Some teams are happy the way they are and simply don’t feel enough pain to want to change. Lisa worked on a team that thrived on chaos, because there were frequent opportunities to figure out why the server crashed and be a hero. Despite a successful project using agile practices, they went back to their old habits, and Lisa finally gave up trying to change them.

See the bibliography for some good resources on being an effective change agent for your team.

Summary

In this chapter, we talked about how cultural issues can affect whether testers and their teams can make a successful transition to doing agile development.

Consider organizational culture before making any kind of change.

Testers have an easier time integrating into agile teams when their whole organization values quality, but testers with a “quality police” mind-set will struggle.

Some testers might have trouble adjusting to the “whole team” ownership of quality, but a team approach helps overcome cultural differences.

Customer teams and developer teams must work closely together, and we showed how testers can be key in facilitating this relationship.

Large organizations that tend to have more isolated specialist teams face particular cultural challenges in areas such as communication and collaboration.

Major barriers to success for testers for agile adoption include fear, loss of identity, lack of training, previous negative experiences with new development processes, and cultural differences among roles.

To help introduce change and promote communication, we suggest encouraging team members to discuss fears and celebrating every success, no matter how small.

Guidelines such as a “Tester Bill of Rights” give testers confidence to raise issues and help them feel safe as they learn and try new ideas.

Managers face their own cultural challenges, and they need to provide support and training to help testers succeed on agile teams.

Testers can help teams accommodate manager expectations by providing the information managers need to track progress and determine ROI.

Change doesn’t come easy, so be patient, and work on improving your own skills so you can help your team.

Chapter 4 Team Logistics

Agile teams stress that face-to-face communication is critical to the success of a project. They also encourage using the “whole-team” approach. What does this mean to the testers? This chapter talks about some of the issues involving team structure and physical logistics. There’s more to creating a cohesive team than just moving chairs and desks.

Team Structure

Having separate functional groups can make life difficult for agile teams. Constant communication is critical. Team members need to work closely with one another, whether the work is done virtually or in the same physical location.

We use the terms “QA team” and “test team” interchangeably here. It can be argued whether “QA teams” are really doing quality assurance or not, but the term has become a common one attached to test teams, so we use it too.

Independent QA Teams

Many organizations, both large and small, think it is important to have an independent QA or test team in order to get an honest opinion about the quality of a product. We’re often asked the questions, “Is there a place for a test organization in the whole-team approach?” and “If so, what is its role?”

Some of the reasons we’re given for wanting to keep the QA team separate from the development team are:

It is important to have that independent check and audit role.

The team can provide an unbiased and outside view relating to the quality of the product.

If testers work too closely with developers, they will start to think like developers and lose their customer viewpoint.

If the testers and developers report to the same person, there is a danger that the priority becomes delivering any code rather than delivering tested code.

Teams often confuse “independent” with “separate.” If the reporting structure, budgets, and processes are kept in discrete functional areas, a division between the programmers and testers is inevitable. This can lead to friction, competition, and an “us versus them” attitude. Time is wasted on duplicate meetings, programmers and testers don’t share a common goal, and information sharing is nonexistent.

There are reasons for having a QA manager and an independent test team. However, we suggest changing the reasons as well as the structure. Rather than keeping the testers separate as an independent team to test the application after coding, think about the team as a community of testers. Provide a learning organization to help your testers with career development and a place to share ideas and help each other. If the QA manager becomes a practice leader in the organization, that person will be able to teach the skills that testers need to become stronger and better able to cope with the ever-changing environment.

We don’t believe that integrating the testers with the project teams prevents testers from doing their jobs well. In fact, testers on agile teams feel very strongly about their role as customer advocate and also feel they can influence the rest of the team in quality thinking.