Out of the Frying Pan...
Stories Columns Opinions Resources
Preflight builds spread wings for smoother projects
Developers are increasingly turning to preflight builds, allowing them to experiment with ...
|
Coverity creates program to enforce code adherence
The Architecture Analyzer uses mapping technology from the company's Software DNA static a...
|
QCon 2008 features domain-driven development
This year's QCon invites speakers like Eric Evans and Dan North to talk about domain-drive...
|
.NET similarities prove golden for Silverlight
Microsoft has focused on making Silverlight 2 symmetric with the .NET platform, and that h...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Advanced Corda CenterView™ Data Visualization for the BusinessObjects™ Intelligence Platform
Corda Technologies presents a white paper on pervasive BI. The BusinessObjects business in...
|
From Mobile to SOA: A Guide for Optimized Application Deployment
Customer need has driven the emergence of multiple computing tiers. Today’s application d...
|
e-Kit: Web Application Security
Is your network secure? What about your web applications.
If IT security is your top p...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
By Edward J. Correia
April 15, 2008 —
SAN MATEO, CALIF—Rob Sabourin is smitten with Scrum. For proof, mention the development framework and watch his body language, as I just did. First you get a wry smile. Then he leans in to engage you in conversation.
“I love Scrum,” says Sabourin, a 25-year developer and the founder of development consultancy AmiBug. “I have worked in many lifecycle models from traditional waterfall methods through complex spirals to modern evolutionary approaches. Scrum shines in turbulent project contexts in which business, organization and technical factors are constantly in flux.” Scrum is intended to help teams deliver working shippable code in short iterations.
But the transition to Scrum can take many traditional independent system testers out of their comfort zone, Sabourin warns. “Scrum challenges many common notions about development. If you have been testing as part of an independent team, you may be in for quite a surprise moving to Scrum.”
In traditional projects, for example, test teams often find defects that escaped from the previous phases of development. “In Scrum, testers are part of a self-organized team charged with getting things done. Testers work hand-in-hand with developers and other team members. Testers are involved in all aspects of development: planning, elaborating stories, testing, debugging and delivering working code.”
As part of his practice, Sabourin helps independent testers make a successful transition to Scrum. They emerge with different scars and some important lessons learned.
Scrum 101
Sabourin advises teams to use Scrum frameworks to enable delivery of working, shippable code in reasonably short periods. “Some projects have one-week iterations, but most clients choose a Sprint of between two and four weeks,” he says.
The Scrum project backlog is a live, prioritized heap of potential requirements, which he says includes User Stories, Capabilities, Constraints and Product Characteristics or Quality Factors. “The product owner is responsible for actively managing the backlog. Potential entries come from customers, marketing ideas, architects and team members,” and the backlog evolves as development progresses. Backlog entries contain just enough information to prioritize them but require further elaboration to implement. “They are detailed as late as possible, often after an implementation decision is made.”
The Scrum team and product owner select high-priority project backlog entries to implement in the Sprint. “During the planning meeting, developers and testers estimate and scope out the work to do,” Sabourin says. The result is a selection of items moved from the project backlog into the Sprint backlog. “During the iteration, the team focuses on fulfilling the Sprint backlog.”
During planning testers and developers determine how to code and test each story. The team begins the Sprint with a strong idea of how it will end. To paraphrase Steve Covey, “Begin with the End in Mind—First Things First”.
The dynamic of development is facilitated by the Scrum Master, who ensures the team is in sync and represents the team to external stakeholders. “Daily stand-up meetings facilitate communications and keep team members aware of progress. The Scrum Master will block distractions, make sure the team remains on track, and facilitates and supports the team’s self-organization.”
Testers work hand in hand with developers throughout the Sprint, Sabourin says, as traditional roles are set aside as required to adapt to the work at hand. “Testers prepare test scenarios, test data and work with builds prepared on-the-fly during the iteration. Developers are often challenged to test and testers may also be asked to develop code as part of the Sprint.”
The Sprint ends with a demonstration of working code that has passed all tests set out during the planning phase. “Any changes, clarifications or refocusing have been done with full involvement of the product owner to ensure no surprises at the end.” Then a Sprint retrospective involving all team members is held to identify changes to improve subsequent iterations.
Role of Testing in Scrum
The traditional role of testing falls into two broad camps: gatekeepers and information providers.
• Gatekeepers act as the guardian of quality and block the release of weak, ineffective or dangerous products.
• Information providers offer massive objective information about the state of the project under development. What works? What doesn’t work? What bugs must be resolved?
Some Scrum team members might be primarily testers, others might be primarily developers, and still others may take on other roles. But all team members may be called upon to test or to support testing during the Sprint. The tester works with the developer and is both a consultant and an active participant. “Before the code is written, the tester works with the developer to decide what it means to confirm the code has been implemented correctly,” Sabourin explains. Elaboration of story tests before the coding starts is a very important blend of design and requirement analysis. The tester is helping the developer decide what it means to fulfill the Story.
Basis of Testing in Scrum
In conventional system testing, testers often base “testware” on sources of information such as requirements, designs, usage scenarios, code, support information and fault models.
But in a Scrum project, the basis for testing is very different. “Strategies to assess correctness must be determined during planning,” Sabourin says. “The amount of documentation available is minimal [and] the tester must use their creativity and judgment to come up with effective ways to assess correctness.”
Side-by-side testing also may be used to identify inconsistencies and differences, Sabourin adds. “Subject-matter experts and customers can help assess correctness, and testers can use a series of heuristics to guide validation. I have seen many cases in which the tester points out an inconsistency to the developer and then works to understand and resolve the concern. The developer can inspect and modify code while the tester varies conditions to build a good understanding of the problem at hand.”
Next week, Sabourin describes one recent adventure in Scrum migration and the problems he faced down as system testers tried to improve an already chaotic project. In essence, he helped the testers take “the dive from the frying pan into the fire.”
Share this link: http://www.sdtimes.com/link/32026