Top 10 Takeaways from the TISQA Conference: Agile Testing in the Carolinas

5) Avoid scrummerfall

Quentmeyer: Agilists need to beware of moving from a true sprint to a 2-week waterfall process. (This unproductive combination of scrum and waterfall development is sometimes referred to as scrummerfall.) All team members (testers, developers, user assistance developers) should be invested all the time – there is no linear movement from "phases" of coding, testing, and documentation during a sprint. There are no scheduled code freezes or build dates that drive the schedule. Sprint end dates are firm. Unfinished work may be rolled into another sprint, but sprints are not extended so that work can be completed. During each two-week sprint, you all work to develop working, tested, well-documented software – and at the end of the sprint, you’re all done.

6) Automate regression testing to enable it to keep pace with product development

Quentmeyer: Manual regression testing simply cannot keep pace with development enhancements. As the number of enhancements increases, the number of required regression tests also rises, and more and more time is required to complete the testing manually. Instead, automate acceptance test cases as they are developed and incrementally build a regression test suite. By automating regression testing, you’ll have more time for manual exploratory testing that will root out issues that routine regression testing may not uncover.

7) Focus on "done" and define, up front, what "done" means

Quentmeyer: Tasks are not done; stories are done, and the story is done only when it passes the acceptance criteria. Testers are crucial to developing the acceptance test (or demo) for a story. Every member of the team who worked on the story is responsible for saying it is done.

8) Bugs: find ‘em and fix ‘em - as part of the software development process

Quentmeyer: Bugs in production are never a good thing, and finding the source of a bug in production nearly always takes longer than implementing the fix. If we focus on test driven development, one key benefit is that every time a unit test fails, we have identified a bug before it goes out the door. Fixing that defect immediately is much faster than finding and fixing it in production, because during development you know exactly what code was changed and where that code resides.

Walker: Defect tracking during development can be valuable when you have a distributed development team (particularly when they are in different time zones), but may not be the most efficient way of routinely handling bug fixes during development. A central concept in Agile development is to value interaction over process, and defect tracking is a process. If it’s easier for someone on the team to say, "Hey, I’m having a problem with…" and another team member (who knows what code he’s been working on and what the likely source of the problem is) can fix it in five minutes, then it can literally take longer to log and track a defect than to fix it. The bugs are addressed earlier (because they are not waiting in a queue), and the team continues to make progress toward their goal of quickly producing working software.

Page 3 of 4

< Previous Page 1 2 3 4 Next >