Testing for agile teams . What's the difference between this and other testing ? What are the goals for such testing ? Is agile testing needed at all ? Why ? You will find some answers inside and mist likely will be directed to the right way.

1. Testing for scrum teams.
Introduction.
Dennis Popov
depo@berlingskemedia.dk
denys.popov@gmail.com
July 2010, Berlingskemedia.dk

2. Plan
• The agile values and testing
• Agile thinking for testers
• Agile tester itself
• Bill of rights
• Goals artifacts and tools

3. The Agile Values
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."
www.agilemanifesto.org

4. What is testing

Software testing is a process of an investigation
conducted to provide stakeholders with
information about the quality of the product or
service under test.

5. What is it needed for ?

Software testing provides an objective,
independent view of the software to allow the
business to appreciate and understand the risks at
implementation of the software (thanks to Wikipedia)

6. Testing and scrum
An agile project is a close team;
everyone shares ownership of the code and of the quality of the product.
If the testers are squeezed, it may be that they are becoming the
gatekeepers of quality, and that the practice of collective ownership is
compromised.
Tester's role tends to fall into two main parts:
- enhancing the confirmation tests at unit and acceptance levels. This means
that developers should help testers to understand unit tests . Testers will
propose changes and pay attention to the situation when unit test seems
to be missing.
- identifying, diagnosing and exploiting unexpected behaviors. They also
bring automation skills to your customer, automating some or part of their
acceptance testing.
- developers can do Mini-demo to Testers on their local environments

7. Agile Thinking for testers

Not a “quality police” but Helps business to express
their needs

Constant feedback's to business

Ready to inner-team communications

Courage to ask questions and get answers

Search for simple ways (does not always mean easy
ones)

Be ready for frequent changes

Self organized. Bring value even when there is no
functionality to test. Use different hats.

8. SCRUM Testing is Different

The biggest difference is that in Scrum project, the entire
development team takes responsibility for quality. This
means the whole team is responsible for all testing tasks,
including acceptance test automation. When testers and
programmers work together, the approaches to test
automation can be pretty creative!

SCRUM isn’t about ‘roles’, it’s about a tight integration of
skills and behaviors. Testing is an integrated activity in
Scrum team. The development team needs continual
feedback, with the customer expressing their needs in
terms of tests, and programmers expressing design and
code in terms of tests. In Scrum team, the tester will play in
both the customer and programmer ‘roles’. He’ll focus on
acceptance testing and work to transfer his testing and
quality assurance skills to the rest of the team.

9. The Old Strategies Won’t Work
•Detailed test planning
• Not enough time
• Too many changes

Old metrics won't work
•Dedicating a phase for testing
• You don’t get to define entry and exit criteria
• Iterations will move on without you
•Change control
• Changes are now commonplace
•Being in a position of authority
• You need to learn how to express concerns without really being able to judge
software correctness authoritatively

10. What is agile tester. Activities
* Negotiate quality with the customer (it’s not YOUR standard of quality, it’s what the customer desires and is willing to
pay for!)
* Clarify stories, flush out hidden assumptions
* Enable accurate estimates for both programming and testing tasks
* Make sure the acceptance tests verify the quality specified by the customer
* Help the team automate tests
* Help the team produce testable code
* Form an integral part of the continuous feedback loop that keeps the team on track.
you will communicate more, with your coders and your customers.
- you will need to have (or will rapidly gain) a deeper understanding of the technology and the code
- you will no longer be the gatekeeper
- you will share more risk, and feel an increased sense of ownership
- you will personally fix more bugs

State the alternative strategies

List the pros and cons of each strategy

Give a forecast of costs
You can be a Bad Customer!

11. Tester - A bad customer hat.
A bad customer does things that aren’t ‘happy path’ interactions; they perturb and may
break the system. It’s worth considering whether a particular action is that of an incompetent
user, an expert/speedy user or a malicious user. A tester can use his or her knowledge of
possible problems and ware a hat of a bad customer. Some trigger ideas include:
- Empty sets, null inputs
- Invalid parts of input – characters, values, combinations
- Time changes
- Unusual uses
- Too much – long strings, large numbers, many instances
- Stop halfway / Jump in halfway
- Wrong assumptions
- Making lots of mistakes, compounding mistakes
- Using the same information for different entities
- Triggering error messages
- Going too fast

12. What sort of stories should a tester
bring?
- User stories that involve edge cases
- User stories that involve malicious intent
- Stories that aren’t for the users
- Infrastructural stories – ie loading the DB for setup
- Unexpected / unconsidered quality criteria
- Consequences after time / under load
- Experiments, rather than stories – like thought
experiments?
- Bugs that need fixing, but can’t be fixed right now

13. Challenge: Are Testers Obsolete?

With developers doing unit testing, do we still need to have
“QA” testers?

Some teams have fired testers when adopting agile. They have then
regretted this.

Some teams are using developers for acceptance testing.

One of the main reasons why we still need dedicated testers – is an
instant feedback from testing.

Dedicated testers bring two benefits:
− Focus on customer usage over technical implementation
− Focus on uncovering flaws over confirming completeness

14. Tester's Bill of Rights

You have the right to bring up issues related to quality and
process at any time.

You have the right to ask questions of customers and
programmers and receive timely answers.

You have the right to ask for and receive help from anyone
on the project team, including programmers, managers, and
customers.

You have the right to make and update your own estimates
for your own tasks and have these included in estimates for
stories.

You have the right to the tools you need to do your job in a
timely manner.

You have the right to count that all team is responsible for
quality of the product

15. goals for agile teams
•How can we get testers to be part of a team? Doesn’t this force
them to sacrifice their integrity?
•Testers have been an oppressed group and have often stuck together
to provide mutual support.
•It’s time to let go of this.
•Testers should co-locate with developers and analysts.
•Agile only works when there is lots of both formal and informal
communication within a team.

Each team member should be ready to ware “tester's hat”

16. artifacts for agile testing p 106

Metrics that will measure team's progress

Test strategy rather than test plan – a long
term plan of actions and activities.

17. tools for testing
http://www.opensourcetesting.org/unit_php.php
Web Protocol Drivers for Functional Testing
PHPUnit http://www.phpunit.de/
Simple test http://www.lastcraft.com/simple_test.php
Load Testing Tools
Celenium ide
Functional testing: FitNesse
Load testing: LoadUI http://www.loadui.org/
SOAP testing http://www.soapui.org
GreenHopper plugin for Jira.
http://www.atlassian.com/software/greenhopper/tour/scrum.jsp

18. Recommendations

Accept SCRUM

Love scrum

Live scrum

19. Materials

Agile testing. A practical guide for testers and agile teams. Lisa Crispin, Janet Gregory,
2010, 464p.

Testing computer software. Cem Kaner, Jack Falk, 2001, 544p.

Wikipedia

Bret Pettichord's blog (http://blogs.stickyminds.com/)

Lisa Crispin's articles http://www.methodsandtools.com/archive/archive.php?id=2

www.testingexperience.com