I'm a strong believer they must be part of the team.
If you have a testing organization within your company, then before agile was implemented you were probably used to pitching "completed" work over the wall and crossing your fingers. Then there was a period of quiet before the wave of bugs came flowing back over the wall.
Going agile is about decreasing the distance between these two points drastically. Actually, TDD (test driven development) is about removing that distance completely. With this philosophy, it is important for a team going through an agile transition to deal with this issue. Instead of the test team relationship being "us and them", you have to find a way to fold the test resources directly into your team. Resources should be slightly more dedicated and must participate in planning and sprint review. Even if they don't aid in prioritization, planning, and design, their presense in the room insures that testing is built into the DONE criteria for sprint work and the timelines are realistic. Their insight can catch issues early, especially those surrounding performance or mis-use of the system. They get a view of what is coming down the pipe so that they can get ahead of the curve and stop being behind the eight ball.
My best experiences with testers on a scrum team occurred when they attended the daily scrum. Also, if they sat with the team throughout the day, they could mentor the team on their unit and acceptance tests to insure the basic logic and validation was covered. They spent more of their time catching the "really hard to find" bugs. They could modify performance and load testing scripts before the work was complete so that system tests could be run almost immediately instead of always being a sprint behind.
The sooner you embrace non-developers into your agile team, the sooner you see these types of benefits. These same points would hold true for usability, user interface, or business analysts.
If you want to know more about testing in agile, I just read a great post by rfleming on whether testing is about uncovering defects or changes. It triggered me to write this because I like his points and they are insightful, but I believe the issue he discusses can be reduced if you strive towards the points I raise here.
Kevin - I agree with your points, especially about co-locating test team members with developers (if possible) and with test team members attending stand-ups. In fact, anyone responsible for project deliverables or recipients of the downstream deliverables may need to attend stand-ups. Depending on the project that means test team, business analysts, product management, marketing, writers, trainers, support, etc.
ReplyDeleteRobin fleming