Agile Testing: A Practical Guide for Testers and Agile Teams

With large software development shops, agile development is often first implemented in one team or just a few teams. If your agile team has to coordinate with other teams using other approaches such as phased or gated development, you have an extra set of challenges. If some of the external teams tend to be dysfunctional, it’s even harder. Even when an entire company adopts agile, some teams make the transition more successfully than others.

Your team might also run into resistance from specialist teams that are feeling protective of their particular silos. Lisa talked to a team whose members could not get any help from their company’s configuration management team, which was obviously a major obstacle. Some development teams are barred from talking directly to customers.

If third parties are working on the same system your team is working on, their cultures can also cause conflicts. Perhaps your team is the third party, and you’re developing software for a client. You will need to think about how to mitigate culture-based differences. Part V goes into more detail about working with other teams and third parties, but here are a few ideas to get you started.

Advanced Planning If you have to coordinate with other teams, you will need to spend time during release planning, or before the start of an iteration, to work with them. You need time to adapt your own processes to work with others’ processes, and they might need to change their processes to accommodate your requests. Consider arranging access to shared resources such as performance test specialists or load test environments, and plan your own work around others’ schedules. Your stakeholders might expect certain deliverables, such as formal test plans, that your own agile process doesn’t include. Some extra planning will help you to work through these cultural differences.

Chapter 15, “Tester Activities in Release or Theme Planning,” and Chapter 16, “Hit the Ground Running,” talk about what testers can do to help with planning and coordinating with other teams.

Act Now, Apologize Later We hesitate to make suggestions that might cause trouble, but often in a large organization, the bureaucratic wheels turn so slowly that your team might have to figure out and implement its own solutions. For example, the team that couldn’t get cooperation from the configuration management team simply implemented its own internal build process and kept working on getting it integrated with the officially sanctioned process.

If there aren’t official channels to get what you need, it’s time to get creative. Maybe testers have never talked directly to customers before. Try to arrange a meeting yourself, or find someone who can act as a customer proxy or go-between.

Empower Your Team

In an agile project, it is important for each development team to feel empowered to make decisions. If you’re a manager and you want your agile teams to succeed, set them free to act and react creatively. The culture of an organization must adapt to this change for an agile project to be successful.

Chapter 4, “Team Logistics,” talks more about separate functional teams and how they affect the agile tester.

Barriers to Successful Agile Adoption by Test/QA Teams

Any change faces barriers to success. Organizational culture, as we discussed in the previous section, might be the largest obstacle to overcome. Once organizational culture has become well established, it’s very hard to change. It took time for it to form, and once in place, employees become committed to the culture, which makes it extremely resistant to alteration.

This section discusses specific barriers to adoption of agile development methods that can be encountered by your testers and QA teams.

Loss of Identity

Testers cling to the concept of an independent QA team for many reasons, but the main reason is fear, specifically:

Fear that they will lose their QA identity

Fear that if they report to a development manager, they will lose support and programmers will get priority

Fear that they lack the skills to work in an agile team and will lose their jobs

Fear that when they’re dispersed into development teams they won’t get the support they need

Fear that they, and their managers, will get lost in the new organization

We often hear of QA managers asking questions such as, “My company is implementing agile development. How does my role fit in?” This is directly related to the “loss of identity” fears.

Chapter 4, “Team Logistics,” covers ideas that can be used to help people adapt.

Additional Roles