Explanation of testing under agile methodologies.

1. TESTING IN AGILE TEAMS
A Practical Guide for Testers and Agile Teams
Sunday, January 13, 13

2. Inspiration
•Tester point of view
•Agile vs Waterfall
•Tools & Techniques
Sunday, January 13, 13

3. Agile quick recap!
Agile testers
Work to ensure that their team
delivers the quality their
customers need
Sunday, January 13, 13

4. Agile vs Waterfall testing
Waterfall Agile
• Strictly enforced gated phases ending
with a rushed testing phase and a delayed • Agile is iterative and incremental.
release. • Programmers never get ahead of the
testers, because a story is not “done” until
• Testing happens at the end, right before
it has been tested.
release.
Sunday, January 13, 13

5. Agile testing?
It includes just about everything beyond unit and component
level testing:
✦ functional, ✦ stress,
✦ system, ✦ usability,
✦ load, ✦ exploratory,
✦ performance, ✦ end-to-end,
✦ security, ✦ and user acceptance.
Sunday, January 13, 13

6. Agile Testing Quadrants
Sunday, January 13, 13

7. Tests that Support the Team
Biggest difference between testing on a traditional project and
testing on an agile project
They guide functionality development
When automated, then provide a safety net to prevent refactoring
and the introduction of new code from causing unexpected results.
Sunday, January 13, 13

8. Tests that Support the Team
Quadrant 1
Sunday, January 13, 13

9. Tests that Support the Team
Quadrant 1
Major Purpose: Test-Driven Development
All of the testing in the other quadrants can’t make up for
inadequacies in this one
TDD it’s more about design than testing
Gives a safety net to refactor
Lacking these core agile practices tend turning into “mini-waterfalls.”
Must have speed in their feedback
Incremental approach for legacy systems
Sunday, January 13, 13

10. Tests that Support the Team
Quadrant 2
Sunday, January 13, 13

11. Tests that Support the Team
Quadrant 2
Also drive development, but at a higher level.
Requirements
Provide the big picture and enough details to guide coding.
Prototyping
Define and verify external quality, and help us know when we’re done.
Part of an automated regression suite and run frequently
Sunday, January 13, 13

12. Tests that Critique the Product
The word “critique” isn’t intended in a negative sense. A critique
can include both praise and suggestions for improvement.
Feedback should be fed back into the left side of our matrix and
used to create new tests to drive future development
Sunday, January 13, 13

13. Tests that Critique the Product
Quadrant 3
Sunday, January 13, 13

14. Tests that Critique the Product
Quadrant 3
Even when business-facing tests pass, they might not be delivering
what the customer really wants.
It’s difficult to automate business-facing tests that critique the
product, because such testing relies on human intellect, experience,
and instinct.
You won’t have time to do any Quadrant 3 tests if you haven’t
automated the tests in Quadrants 1 and 2.
Sunday, January 13, 13

15. Quadrant 3 Tests
Demonstrations Early and often
Scenario Realistic Testing Flows and Data provided by the
customer
Exploratory Testing As you test, you learn more about the system
under test and can use that information to help design new tests.
Usability Testing Personas
Check Competition
Sunday, January 13, 13

16. Tests that Critique the Product
Quadrant 4
Sunday, January 13, 13

17. Tests that Critique the Product
Quadrant 4
We worry about deficiencies in the product from a technical point of view.
Nonfunctional requirements include configuration issues, security, performance,
memory management, the “ilities” (e.g., reliability, interoperability, and scalability),
recovery, and even data conversion.
Not all projects are concerned about all of these issues, but it is a good idea to have a
checklist to make sure the team thinks about them and asks the customer how
important each one is.
It needs a specialized skill-set.
May result in new stories and tasks
Sunday, January 13, 13

18. Quadrant 4 Testing
Security Specialized training & tools
Maintainability Code reviews, pair programming, standards,etc
Interoperability Consider communicated systems and test
Compatibility Use different OS’s, browsers, machines
Reliability how long can the system run before it fails the first time?
Performance, load testing
Installability Ready to deploy any-time. Deploy early, often and
automated.
Do not left until the very end! It might be too late...
Sunday, January 13, 13

19. Sunday, January 13, 13

20. Other concepts
Sunday, January 13, 13

21. Shared Responsibility
No matter what resources have to be brought in from outside
the development team, the team is still responsible for
getting all four quadrants of testing done.
Sunday, January 13, 13

22. Managing Technical Debt
Is taking shortcuts, hacks in quick fixes, or skips writing or
automating tests because it’s under the gun
Like financial debt, “interest” compounds in the form of higher
maintenance costs and lower team velocity.
Applying agile principles to do a good job of each type of testing
at each level will, in turn, minimize technical debt.
Sunday, January 13, 13

23. Iteration Planning
Consider all viewpoints
No story is “Done” until it’s fully tested.
Don’t be afraid to raise a red flag when a story seems to be
growing in all directions
The start of an iteration is the last chance to ensure that the
stories are testable and that adequate test data is provided.
Sunday, January 13, 13

24. Dealing with bugs
Within iteration bug? if possible to fix: Fix + Test
Log all production bugs or the ones that can’t be fixed right away
Set rules, like “Bugs counter should never get higher than 10”
If you find a lot of bugs in one area, think about combining them
into an enhancement or story.
If a “bug” is really missed functionality, choose to write a card for
the bug and schedule it as a story.
Sunday, January 13, 13

25. Testing checklist
Sunday, January 13, 13

26. Summary
Use the Agile Testing Quadrants as a guide to help you plan testing that will cover all
the angles.
Guiding development with tests helps make sure you don’t miss something big
Use exploratory testing to learn more about how the application should work,
Make your test environments as similar as possible to production, using data that
reflects the real world
Evaluate how your current stories fit into the grand scheme of the business.
Sunday, January 13, 13

27. Q&A
Sunday, January 13, 13

28. Thanks!
Tomas Alabes
Sunday, January 13, 13