Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
Agility and Risk: Challenges for your Agile QA Strategy
Transcript of Agility and Risk: Challenges for your Agile QA Strategy
is it? What does it
mean to be
agile? How do you know
how agile you are? Courage + Safety = Confidence Key Points Quality trumps
Quantity Priority trumps
Productivity Do each thing right, rather than trying to do more
Avoid deferring testing 'phases' to late in the project
Foster a culture of elegant simplicity in design Do things in order of importance, rather than trying to work faster
The business must accept responsibility for prioritisation
Prioritise by business value, not technical dependency Big Changes
are Painful Make change natural, easy and welcome. Change a little, often.
Help the team see progress in the 'big picture' of their project.
Measure & celebrate the benefits of change. Business Alignment
What motivates your IT staff?
What demotivates them?
Comparable with business stakeholders? "A late change in requirements...
is a competitive advantage"
- Mary Poppendieck "Code that isn't tested doesn't work.
This seems to be the safe assumption."
- Kent Beck "The product of testing is
- David Evans Tester Challenges Modes of
Working Skills &
Training Hiring & Retaining Testers dedicated to project teams
Testers and developers co-located and collaborating
Testers supporting business people Things to consider:
Do you have enough people?
Will they fit in a mixed-skill team?
Are they comfortable with co-location?
Do they have sufficient domain knowledge? Automation Testability Domain
Knowledge Scaling Up Specialist
Services Outsourcing and
Models What can you do Invite a senior developer or architect to discuss what can
be done to improve testability on your applications, e.g.
Moving logic out of GUI
Centralising and overriding date/time
Patterns: Dependency Injection, Inversion of Control Testability Investigate open-source and commercial acceptance testing frameworks
E.g. Fitnesse, Cucumber, EasyB
Get a developer and a tester to work together on this Automated Acceptance Testing Improving Team Communications Whole Team
Test-Driven Automate, Automate,
Automate The whole team is responsible for quality
Don't ask 'how many testers?', ask 'how much testing?'
Measure the whole team on running, tested features Tests are both verification and specification
Unit Test-Driven Development produces better code
Acceptance-Test Driven Development produces better designs You will not succeed without robust test automation
Automate most of your tests below the GUI
Don't assume your existing tools are suitable If you are not already doing so, introduce these ideas in your team:
Daily stand-up meetings (15 minutes, simple status updates only)
Retrospectives (monthly team forum for improvement ideas)
Technical book clubs to learn new techniques or tools The rule of the iteration:
working, tested software every time
Every iteration creates an incremental change to the evolving system
The new features of an iteration must be tested before we are ‘done’
Time to create and execute tests must be factored into the iteration today? Don't confuse
'complicated' "...landing a
man on the
safely to earth."
Difficult to do
to express Remember the
agile principle of
Simplicity General Rule:
testers are dedicated, full-time members of agile teams
Assign testers to teams, based on their domain knowledge
Don't get hung up on ratios - use testers to improve capability
The whole team is responsible for testing and quality
Consider a 'toolsmith' role for automation General Rule:
let the specialists follow the need for the specialism
If performance (security, usability...) is critical to the project, dedicate a specialist tester to it
For scarce resources, share services across teams that need them
Use the specialists to coach and advise the generalists
Avoid the trap of deferring specialist testing into separate phases General Rule:
Don't offshore your testing!
Don't try distributed agile until you have mastered co-located agile
Avoid dividing projects by role
Factor in the cost of low-quality communication Common
Concerns "We can't find enough testers
to resource all our agile development teams"
"Our testers are not able to keep up
with the output from development"
"There is not enough time
to complete regression testing"
"Developers complete their stories in a Sprint,
but the testers always overrun" What's the
common thread? Building the thing wrong Building the wrong thing Building the right
thing, too late Building something that doesn't last ...or incompatible with other platforms Spending more
than the thing
is worth ...or can't be used by those who need it ...or can be used by those who shouldn't Quickly building a thing that's too slow Building a quick thing, too slowly The agile tester's primary role:
extend the mental reach of the internal Customer
Train your testers in the details of the business
Have them shadow end-users where possible
Encourage pairing of testers with business users The fastest way to improve test efficiency:
improve the testability of your software
Expose programmatic interfaces
Mock external systems
Centralise date/time access What does 'small-a' agile mean?
Nimble, flexible, lean, fit
Alert, responsive, attentive
Conserve energy, avoid waste
Good at following a moving target One third agile,
one third non-agile,
one third chaotic.
Agile is the fastest growing segment. Value Focus
How responsive are you to the market?
What is your concept-to-cash cycle time?
How quickly do you get customer feedback? Agility
is a state of mind,
not a process. Domain Knowledge
Test automation frameworks Personality and 'team fit' will override other criteria
Involve your teams in the selection process
Favour recent agile experience, and beware of 'patches' Be aware that agile does not suit every personality
Look at alternatives
Don't let good agile testers morph into developers (unless they want to!) Test-Driven Development requires tests to be automated
before the feature is implemented
You need appropriate frameworks
Unit-level TDD is different to Acceptance-level TDD
Do this automation mostly below the GUI http://www.forrester.com/rb/Research/agile_development_mainstream_adoption_has_changed_agility/q/id/56100/t/2 uestions nswers Asking the right
(Test analysis & design) Getting fast and consistent
(Test execution) Some suggestions:
"Agile Testing" by Lisa Crispin & Janet Gregory
"Bridging the Communication Gap" by Gojko Adzic
"User Stories Applied" by Mike Cohn
"Scaling Lean & Agile Development" by Craig Larman & Bas Vodde
"Test Driven" by Lasse Koskela Agility and Risk:
Challenges for your Agile QA Strategy David Evans Agile Quality Coach Bergen, Gothenburg, Stockholm
May 2010 David@thinkalikeconsulting.com
Twitter: @DavidEvans66 This presentation available at www.prezi.com Thanks!
Questions? Don't Forget:
Iqnite Conference, Stockholm, 29th-30th September
Agile Testing in the Financial Sector, London, 15th July
Agile Testing Days, Berlin, 4th-7th October