This document provides an overview of agile testing and acceptance test-driven development. It discusses key principles of agile testing including writing tests early and often, providing continuous feedback, keeping tests simple, and practicing continuous improvement. It defines the differences between unit tests and acceptance tests, and best practices for acceptance test automation and design. The document emphasizes treating testing as a collaborative conversation rather than just finding defects.

1. Agile Testing

2. © 2011 VersionOne 2
Steve Ropa
Agile Coach
Certified Scrum Master
Certified Scrum Product Owner
19 years software development
11 years programming
8 years director of development
10 years Agile experience
XP
Scrum
Welcome & Introductions
Blog: http://blog.versionone.com/blog/
Email: steven.ropa@versionone.com

3. © 2011 VersionOne 3
What is Agile After All?

4. © 2011 VersionOne 4
We are uncovering new ways of developing software
by doing it and helping others do it. Through this
work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to Change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.
Agile Software Development

5. © 2011 VersionOne 5
• Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
• Welcome changing requirements, even late in
development. Agile processes harness change
for
the customer's competitive advantage.
• Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
• Business people and developers must work
together daily throughout the project.
• Build projects around motivated individuals.
Give them the environment and support they
need,
and trust them to get the job done.
• The most efficient and effective method of
conveying information to and within a
development
team is face-to-face conversation.
• Working software is the primary measure of
progress.
• Agile processes promote sustainable
development.
The sponsors, developers, and users should be
able
to maintain a constant pace indefinitely.
• Continuous attention to technical excellence
and good design enhances agility.
• Simplicity--the art of maximizing the amount
of work not done--is essential.
• The best architectures, requirements, and
designs
emerge from self-organizing teams.
• At regular intervals, the team reflects on how
to become more effective, then tunes and
adjusts
its behavior accordingly.
Principles of Agile

6. The Agile Mindset
Self organizing teams
Emphasis on customer value
Creating great software, not engineering a process
Communication is key
Mentality of sufficiency

7. © 2011 VersionOne 7
• Ten Principles of Agile Testing
Agile Testing

8. © 2011 VersionOne 8
How a Testers Life Changes
• Tests are not “What Comes After
Development if We Have Time But We
Never Have Time”
• We need to identify and write tests
early and often
• Automation baby, Automation
• The relationship of acceptance tests
to requirements needs to be tight.
• Relationship between programmers
and testers is tighter
• Collaboration over confrontation
• Entering Defects is not enough
• We are finally being recognized and
utilized as a vital part of development,
not just a gatekeeper

9. © 2011 VersionOne 9
• Tests are the ultimate in feedback
• By writing the tests first, we provide a “goal”
• Tests are a conversation, not just writing defects
• We are the beginning, middle and end of the
conversation
Provide Continuous Feedback

10. © 2011 VersionOne 10
• Sometimes, a story needs a little help
• Dude’s Law (David Hussman)
– V = W/H
• Think beyond whether the requirements are met.
– Will this actually provide value?
– Will the customer want to use it?
• And yes, be excellent to each other
Deliver value to the customer

11. © 2011 VersionOne 11
• What is the most useful Agile tool?
– The human voice
• Defect tracking tools can deceive you, don’t trust
them
• Don’t accept “brush offs”
• Develop a shared language
– Be the bridge between customers and technical teams
Enable face to face communication

12. © 2011 VersionOne 12
• We have a lot of history to overcome
– Remember the tester stereotypes?
– How many of us have worked in a “silo environment” where testers don’t
talk to stakeholders or programmers?
• “How does testing keep up with development?”
• Be willing to fail
• Be willing to assert your views during planning sessions
Have Courage

13. © 2011 VersionOne 13
• Simple is usually harder to do
• Do the simplest thing that could possible work
• Many small simple tests will give you more results than a few
large complex tests
• The power of work not done
Keep it simple

14. © 2011 VersionOne 14
• This is not a formal thing, but
an attitude
• I have a set of tests
– They all pass
– I bet I can find two more tests
that will make the product
even better
• I don’t have all of my tests
automated
– I can automate three new tests
each sprint
– I’ve been automating three per
sprint, I bet I can do five.
• Refactoring ain’t just for
programmers
Practice Continuous Improvement

15. © 2011 VersionOne 15
• Team culture imbues every aspect of agile
development
• Don’t wait for someone to tell you what your role
is.
• Take all of the knowledge you can possible get
from the team
– Learn a programming language
– Learn a new testing technique
– Learn about the financials behind a product.
Self Organize

16. © 2011 VersionOne 16
• Software development is a social activity
• The technology part is the easy part
• Remember:
– We value individuals and interactions over processes and tools
• All members of the team are equal
– You don’t have to assert it
– Assume it to be the case, and it will be
Focus on People

17. © 2011 VersionOne 17
• We are spending *WAY* too much of our time doing
this to not enjoy it
• Find little ways to enjoy it.
• Celebrate successes
Enjoy

18. © 2011 VersionOne 18
Assuring Quality is not about finding errors
Assuring Quality is about creating the best
product the first time
Quality Assurance

19. © 2011 VersionOne 19
• Automated unit tests confirms the code is
doing what we say it will do
• Automated Acceptance Tests confirm the
code is doing what we want it to do
• Another way of looking at it:
– Unit Tests ensure we make the software right
– Acceptance Tests ensure we make the right
software
What is Acceptance Test Driven Development

20. © 2011 VersionOne 20
• In its purest form, the acceptance test is the
statement or condition that must be
satisfied for a story to be complete
• Acceptance tests are the closest thing to
“requirements” in the agile world
What is an acceptance test

21. © 2011 VersionOne 21
• More often than not, this ends up being
QA/Testers
• Anyone can write an acceptance test
• A product owner who writes good
acceptance tests is worth their weight in
gold
Who should write acceptance tests?

22. © 2011 VersionOne 22
• Unit tests are small, light, and never touch the external world
• Acceptance tests touch as much of the real world as can be
touched.
The difference between unit tests and acceptance tests

23. © 2011 VersionOne 23
• There are many forms that an acceptance test can take.
• What we want to make sure of is that it is a clear statement of
what the user wants to do, and what they expect to see
happen.
• An acceptance test is a binary. It can pass or it can fail, there
is no in-between
What does a good acceptance test look like?

24. © 2011 VersionOne 24
• Automate everything possible
• Record and playback is fine, but not enough
• As with unit tests, don’t be afraid of “hard
coding” some test values.
• Don’t forget the “unhappy path”
Acceptance Test best practices

25. © 2011 VersionOne 25
• During a sprint, when I find a defect…
– I can log a defect into a bug tracking
system, and hope someone has time to
work it before the release
– I can write a failing acceptance test that
illustrates the defect.
•I talk to the programmer about the issue and
the test
•When the test passes, its as if the defect never
existed
Instead of logging a defect…

26. © 2011 VersionOne 26
• We have a lot of different tools in our
box
• They are all good tools by themselves,
but the whole is much greater than the
sum of its parts
Bringing the whole thing together