half-truths about agile testing - stickyminds · the purpose and or consequence of a half truth is...
TRANSCRIPT
T10 Concurrent Session 5/5/2011 11:15 AM
"Half-Truths about Agile Testing"
Presented by:
Clinton Sprauve Borland (a Micro Focus company)
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ [email protected] ∙ www.sqe.com
Clinton Sprauve A senior product specialist for Silk Testing Solutions at Micro Focus, Clinton Sprauve has more than fifteen years of experience in the software quality assurance industry. Previously he was the senior product marketing manager for Silk Testing Solutions at Borland Software and Segue Software, and served as a senior technical sales engineer for both companies. Clint also has been an independent consultant specializing in test management and test automation.
Half-Truths About Agile TestingClint Sprauve
Senior Solutions Engineer, Micro Focus
What is Agile Testing?Agile Testing is a software testing practice that follows the principles of agile software development. Agile testing does not emphasize testing procedures and focuses on ongoing testing against newly developed code until quality software from an end customer's perspective results. Agile testing is built upon the philosophy that testers need to adapt to rapid deployment cycles and changes in testing patterns - Wikipedia
What is a half-truth?The purpose and or consequence of a half truth is to make something that is really only a belief appear to be knowledge, or a truthful statement to represent the whole truth, or possibly lead to a false conclusion. - Wikipedia
Half-Truth#1: Testing in Agile is totally different than traditional testing
The Whole Truth
It’s different, but not completely different
The tasks are the same, but the speed and entry points differ
i.e., unit tests, functional tests, regression, performance, etc. are still necessary
It’s not about how you test, but how early and how often
Half-Truth #2: Since everyone is responsible for quality, we don't need testing specialist
The Whole Truth
Team roles make a differenceEveryone is responsible for quality, but you need specialistspecialist
Why: Bandwidth of testing responsibilities
Developers are not the experts in every aspect of software development (i.e., performance testing, security testing, automation frameworks, etc.)
Half-Truth #3: Traditional/proprietary testing tools won't work in Agile
The Whole Truth
It’s not about the tool
How robust is your test framework, code reuse, and test ydesign
The problem: many test tools use proprietary scripting languages, or bastardized versions of industry standard languages
Half-Truth #4: Now that we're Agile, testers need to step up their game and write code
The Whole Truth
Again, specialty roles do exist in Agile Some are automation experts, some are subject matter experts
Everyone on the team should not be involved inEveryone on the team should not be involved in automation
Utilize your team members skill sets to their advantage
Do not force non-technical team members to write code if they don’t understand basic programming concepts
Half-Truth #5: Outsourcing or off-shoring the testing will kill our project
The Whole Truth
As the application matures, so does the amount of functionality
Even with automation, most teams can’t handle the necessary amount of testing within each sprint
Outsourcing is definitely not the cure, but will be hurt by bad processes and lack of control/communication
Outsourcing for the sake of warm bodies will harm the project, not outsourcing itself
Summary
The SDLC “game” hasn’t changed, just speed and agility g g , j p g yneeded to achieve your testing goals
Don’t take a purist approach to Agile, but a practical one
You have the right skill sets; utilize your team members to the best of their abilitiesto the best of their abilities
Remember, testing is testing; the challenges are the same whether you’re traditional or Agile
