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.
Deja vu all over again
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.
4. Know what the developer is worried about
The tester should know where defects were found during unit testing and what parts of the code seem most complicated or worrisome. Knowledge of where the developer feels least confident or what the developer would refactor if time permitted is enormously valuable to the tester. The developer should share any white box considerations (for example, integration with an especially complicated service layer) that will help the tester determine where to spend their time.
5. Cross-train: Developers and testers should learn from one another
The developer should help the tester understand the code base, along with any related test code, while the tester should help the developer understand the test suite and the rationale behind related test techniques. A tester who understands the code base will be in a better position to look for trouble spots and areas of potential breakage. A developer who understands the test suite and how to build better tests will create a stronger product and write better test code.
Escaping scrummerfall
These five practices can help developers and testers break down waterfall-era habits and realize the benefits of integrating construction and testing. By further blending their roles, developers and testers can enhance product quality and remove the inefficiencies of more traditional models in which hand offs and code drops are the main touch points between developers and testers.
Although there are many benefits to be gained from these practices, there are potential risks as well. If developers and testers work more closely together and the notion of a hand off disappears, developers will feel less pressure to get stories ready for QA consumption. They'll scale back their own quality-focused efforts, assuming the tester will make up for any needed diligence in the new, blended testing model. In these situations, some gentle encouragement and tutoring from the tester, such as steering the discussion toward how the developer might have caught an issue through automated testing, should typically be enough to keep both parties in harmonious balance.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
