Letters to the Editors: Testing in Scrum
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
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...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
By SD Times News Team
July 1, 2008 —
I have read several articles in Software Test & Performance (an SD Times sister publication) about testing in Scrum or other agile software development approaches, and every one of them gives the misimpression that agile software has no documentation of the requirements. Therefore, the testers must test for what the developers say the software should do, which is a moving target.
This misconception would, of course, lead to chaos and lots of rework, especially given the rate that requirements change in agile software development. The way to make testers effective in agile software development is quite simple:
1. When the developers “negotiate” the requirements for the upcoming iteration with the customers, the testers must be full participants in those conversations. This includes asking clarifying questions, noting where requirements are untestable and pointing out other gotchas that experienced testers will see.
2. The testers immediately translate the requirements that are agreed upon in those conversations into test cases. Those test cases serve as the requirements documentation for the upcoming iteration. As soon as possible, the testers and developers collaborate in automating those test cases.
3. When requirements change, testers are immediately involved because everyone knows that the test cases must be changed accordingly.
Note that having business analysts (BA) document the requirements in ambiguous text, and then testers translating them into test cases (usually after the software has already been developed), is wasteful and leads to arguments about different interpretations of the textual requirements.
Going straight to unambiguous test cases avoids the extra step and finger-pointing. It does mean that testers should learn some BA skills. This can be accelerated by retraining some of the BAs to be testers.
Proactive participation by testers resolves the problems:
• Communication is three-way, not one-way.
• Requirements are documented as test cases (and everyone now knows what the software delivered by the end of the iteration is supposed to deliver).
• Testers are first-class team members contributing throughout the process, not second-class members playing catch-up at the back end).
Instead of complaining, be proactive and get involved in the entire software development process flow. It would represent an increase in responsibility for testers, but that should be a welcome change.
Steven Gordon
Independent Software Developer and Agile Coach
Phoenix
sgordonphd@gmail.com
Give Pick its due
I read your article about virtualization with some amusement. I am an old Pick database programmer, and Pick has done virtualization since the 1970s.
The Pick OS will load and run on just about any platform out there, including Microsoft’s. It uses simple Basic and a host of built-in tools to create one of the easiest-to-use and yet most versatile three-dimensional relational database models on the market. Yet, it never, ever merits mention in any of the “mainstream” media periodicals.
Just about every buzzword and acronym you guys punch out every month, Pick has been doing since bell-bottoms and afro hairdos were in style. All the techno-weenies out there owe a great deal of what’s happening in their careers to this venerable OS, yet I’ll bet less than 5% have ever heard of it.
Had Dick Pick not passed away in the mid-1990s, things might have been different today. But I can tell you this: Wherever you find a Pickie out there, they’ll tell you that they wouldn’t trade their “legacy system” for all the whiz-bang buzzword-laden toys in the world. So how about a nod to the good old days once in awhile?
Gary Lass
Wilsonville, Ore.
A response to an editor’s question
Re: Feedback on 'Zeichick's Take: What's Microsoft up to, withdrawing its Yahoo bid?'
My feeling is that the engineers at Yahoo want nothing to do with Microsoft. If Yahoo does get acquired and the engineers go someplace else, what exactly are they buying?
Bruce Garlock
Related Search Term(s): Testing & QA, virtualization, Microsoft, Yahoo
Share this link: http://www.sdtimes.com/link/32407