Agile Testing Fact and Fiction
Stories Columns Opinions Resources
Bob Muglia named president of Microsoft STB
Muglia joins Robbie Bach and Stephen Elop as a president of Microsoft, with Muglia heading...
|
Curl's new data services kit works with AMF
According to Curl executives, users who need to bring data into Adobe Flash or Flex applic...
|
SCO asks for Jan. 16 deadline for reorganization plan
The Chapter 11 reorganization plan was originally due last Wednesday, but SCO asked for an...
|
Pegasus acquires AccuSoft imaging SDKs
The acquisition brings the ImageGear imaging SDK and NetVue document management software i...
|
Short Takes: January 1, 2009
In this issue, the editors take a look at Bjarne Stroustrup and his ideas about computer e...
|
Windows & .NET Watch: Knocking off at 5 for a quiet weekend
Every IT worker and software development manager would love to enjoy their time off withou...
|
Integration Watch: Maven goes commercial
Sonatype, Jason van Zyl's company, has expanded its array of software and support products...
|
Windows & .NET Watch: Add to cart? Maybe not
For those setting up e-commerce websites, cart software looks like it would be a good way ...
|
Zeichick's Take: Remembering the ‘Rules of the Garage’
Hewlett-Packard has long been an inspirational company, not just because of its current pr...
|
Letters to the Editor: JavaFX for Eclipse?
A reader criticizes Sun for its inability to get JavaFX out there, while another clarifies...
|
From the Editors: Clouds in the rear-view mirror… and windshield
Cloud computing became extremely popular this past year, and for good reason, as it offers...
|
A year of peace
What a year! In the past 12 months, we’ve seen a lot of change – some good, some bad. The ...
|
Defining – and redefining – your app dev lifecycle
The waterfall is dead. A new generation of applications and architectures has
changed t...
|
Make your builds of STAR quality
As your company becomes more and more agile, the pressure’s going to grow on a natural bot...
|
Business intelligence is everywhere, the challenge is to see it clearly
Executives and managers love business intelligence. In our turbulent economic times, BI to...
|
From Mobile to SOA: A Guide for Optimized Application Deployment
Customer need has driven the emergence of multiple computing tiers. Today’s application d...
|
By Edward J. Correia
September 23, 2008 —
If your company is practicing agile development, you might have been faced with some of the same challenges as George Wilson. As Business Group Manager at AIG Computer Services, he simultaneously managed IBM mid-range and PC development projects in a TickIT management environment, which requires ISO 9001 QA certification. Now, as co-founder and general manager of test automation tool maker Original Software, he preaches agile practices as the best means to achieve quality.
"Agile projects are an excellent opportunity for QA to take leadership of the [testing] processes," Wilson says. Rather than take a back seat while developers drive the ship, he recommends that testers take the lead. "Who else is better placed to bridge the gap between users and developers, understand … what is required, how it can be achieved and how it can be assured prior to deployment?" This requires that the QA team be fluent in agile themselves, so Wilson offers the following facts to debunk some common agile testing myths:
Myth One: You only need to unit-test—TDD testing is sufficient
Test Driven Development is a good start, but for those who think it's all there is, "for the vast majority of commercial developments this simply isn’t true. Even strong proponents of agile development recognize the need for their armory to include a range of testing techniques...including white box, black box, regression testing, stress testing and UAT," said Wilson.
Therefore, the most effective agile projects will include investigative (black box) testing efforts that support (rather than compete) with white box testing. "Good investigative testing will reveal problems that the developer missed before they get too far downstream," said Wilson.
Myth Two: You can reuse unit tests to build a regression test suite
Has anyone ever told you that conventional downstream testing is unnecessary because every line of application code has a corresponding test case? "Some TDD proponents ... suggest that by reassembling unit tests, everything from User Acceptance Tests to Regression Tests can be performed," said Wilson.
While this may sound feasible, Wilson says it isn't realistic because the granularity and objectives of white box unit tests developed in TDD serve a different purpose than downstream black box testing. "While the overall objective of a unit test is to prove that the code will do what is expected, the aim of regression testing is to ensure that no unexpected effects result from the application code being changed. These two objectives are not synonymous. Checking that an attribute has a valid date format [for example] is not the same as checking that for a given input, the value of the field contains an expected date."
Myth Three: We no longer need testers or automation tools
Not true. Testers perform a "different and equally valid role from their development colleagues," says Wilson, and should therefore be have an equal place at the project table. "It is [also] widely recognized that traditional test automation tools have failed to live up to the hype of the vendors." Perhaps vendors (no offense, Original) should play down the hype.
Myth Four: Unit tests remove the need for manual testing
Few would disagree that manual testing is repetitive, expensive, boring and error-prone. And while TDD can reduce the amount of manual effort needed for functional testing, it does not remove the need for further manual or automated black box testing. "By automatically capturing the tester’s process and documenting their keystrokes and mouse clicks, the tester will have more time for the interesting, value-add activities, such as testing complex scenarios that would be difficult or impossible to justify automating. Though manual testing is a time-consuming (and therefore expensive) way to find errors, the costs of not finding them are often much higher," said Wilson.
Myth Five: User acceptance testing is no longer necessary
In his experience with agile development, Wilson says that acceptance testing is often positioned as working with the customer to resolve incorrect requirements rather than correcting functionality that does not map to what the user needs. And maybe it's actually both. "When the user initially defines their requirements, they do it based on their initial expectations. When they see the system 'in the flesh,' they will invariably come up with different or additional requirements," he says.
While the agile process might reduce the frequency of this happening, Wilson believes it is unreasonable to expect the approach to resolve them entirely, so there should be no expectation that user acceptance testing will be obviated. "This is especially true when it comes to the business user signing off approval of the user interface, since they may have envisaged something different from the developer."
The Software Test & Performance Conference begins tomorrow. I hope to see you there.
Share this link: http://www.sdtimes.com/link/32884