5 ways to align agile testers and developers

By: Stephen Frein

Your team is agile. They write user stories and work in short iterations. They start each iteration with a planning meeting, and close it out with both a demo of their work and a retrospective on how things went. Your agile testers and developers convene a daily stand-up session to assess their progress. They sit close to one another in the office and do a lot of work gathered around whiteboards. They don't emphasize documentation or try to plan things in much detail beyond the current iteration. Overall, their rhythms and ceremonies are noticeably different from their pre-agile days.

Yet, some aspects of their work seem not to have changed much. On many agile teams, testers end up working in waterfall fashion, waiting for the hand off of a user story from developers before beginning the bulk of their work. This approach creates the same pitfalls as in waterfall projects: hurried test efforts, incomplete testing, slow feedback cycles, and a fragmented sense of quality ownership.

For many testers, the shift to agile has been in name only. The scrum master will ask if a story is ready for QA. Developers still talk about dropping code for testers to review. User stories often don't make it to testers until the last day or two of the iteration, and when the stories come, the testers have to work hurriedly to finish them before the end of the sprint. Stakeholders wonder aloud if QA will finish on time, and sometimes the testers have to work late into the night or over the weekend to complete testing so the stories can be accepted in time for the next iteration to start.

Many teams work this way. For whatever reason, their agile transformations stop at the development-testing divide. While the overall work proceeds in an iterative style, each iteration proceeds like a small waterfall, following the same design-develop-test-deploy sequence that agile is supposed to have overcome. Testing gets treated as a phase separate from development and remains compressed at the end of the window, just as it always was.

The agile ideal of intertwined construction and testing, such that testing informs and guides construction rather than merely critiquing its outputs, seems hard to realize. Testing remains the duty of a specialized few, rather than the responsibility of the whole team.

Construction and testing can't intertwine in a symbiotic whole without developers and testers working in tandem. Just as two developers might pair to work through a problem, developers and testers can pair up in order to blend the threads of construction and testing into a single continuous rope. The challenge is to figure out what this day-to-day pairing might look like.

The most recognizable ceremonies of agile, such as planning poker and stand-ups, are easy to describe and mechanically replicate. Teams can emulate these readily enough, so acting agile is manageable, even if difficult to fully master. It's the smaller day-to-day behaviors that are challenging, because it's difficult to say what these behaviors look like, to know if you're doing them correctly, and to sustain them consistently.

The following five practices will help developers and testers break out of "scrummerfall" dynamics and work symbiotically, rather than serially.

1. Testers and developers should jointly emphasize a test-first approach
Testing will inform and benefit construction the most when testing is present early in the development process. The clearest manifestation of this is the test-first approach. The developer should know what tests will be run so the tests can be anticipated as part of construction. Before construction of a user story begins, the developer and tester should discuss the kinds of testing to be performed on the story. This will enable testing to help inform construction, even if the developer isn't following formal, test-driven development practices. Advising the developer on what scripted tests the tester plans to run doesn't prevent the tester from introducing additional exploratory tests or other variations down the line.

2. Testers should test on developers' machines as they build new features
The idea of a code drop or hand off implicitly assumes that the developer's job is done and the tester's job is ready to begin. A better approach is to have the tester testing on the developer's machine throughout the process, even before the code is fully completed and checked into the source repository. A tester who is looking at the developer's work in near real time can give earlier feedback that identifies ambiguities and prompts needed improvements. There's no reason to wait for a formal build before giving such feedback, although the formal build also must be tested.

3. Know what the developers have tested, in code or otherwise
The developer's testing efforts should be well understood by the tester. Since good testing is driven by an understanding of risk, the tester will benefit from knowing what tests the developer has run, either in code or manually. An understanding of developer test efforts also allows the tester to identify areas with and without coverage, and to make better decisions about where to invest testing time.

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/