Blog post

Should I Embed Testers in the Dev Team?

By Thomas Murphy | June 08, 2010 | 1 Comment

QualityAgile

At IBM’s Innovate conference a four person panel (Scott Ambler, Kim Warner, Reed Figgins, Brian Massey) addressed several issues with Agile and Testing.  The starting question was the title line here.  Agile generally thinks about small teams 5-15 people who work in close proximity (possibly the same room) with each other.  Teams with the greatest success with Agile are co-located teams because they have the highest level of collaboration and this drives knowledge sharing and quality.  Embedding testers in the agile team means that you are taking a proactive approach to quality and a recognition that quality is broader than just the code.  However co-location will create the largest disruption, some of the test team may not fit well, and it can over time (if a team stays together) create blind-spots as the team begins to think more alike.  While you should embed testers in agile teams, you should also have independent teams (potentially organized in COEs) that focus on automation, load/stress/performance, and to act as an independent IV&V team.  The bottom line is Agile can provide many benefits but it is a transformation and requires discipline and the right people and not everything will fit in the agile box.

Leave a Comment

1 Comment

  • Paul Ronan says:

    Its important to get both levels of testing working; embedded for specialist/functional knowledge and external for integration and stress testing. There is a need to ensure that the local test capability is gaining knowledge as quickly as the developers who are building pbi’s. This is not always that easy to do, especially if the testers are considered second class citizens. I believe a nice polished multi level testing strategy is worthless unless the developers are designing for testability and will commit (with project management backing) beyond unit testing into integration. system and so forth.