Testing in agile

Testing in Agile

http://qtp.blogspot.com 1

Table of contents
1. Traditional style QA
2. Agile Approaches
3. An Agile Tester
4. Traditional vs. Agile
5. Role Testers Play
6. Testing & Testers on Agile Projects
7. Question: While a developer is coding a task, it is impossible for a tester to
test it (it doesn't exist yet). What then is the role of a tester at this point.
8. Question: Is the tester now involved in unit testing? Is this done parallel to
black box testing?
9. Question: What does the tester do during a sprint where primarily
infrastructural changes have been made, that may only be testable in unit
testing?
10. Specific Technical Skills For Agile Tester‟s Toolkit


Traditional Style Quality Assurance

Process and tools are a key part of QA and Testing.

QA people seem to love documentation.

QA people want to see the written specification.

And where is testing without a plan?

So, is there a role for QA in Agile projects?

Maybe, but the role is different, the tasks are different.


Agile approaches are changing the conversation
about software development

Agile shifted our attention to small teams.
.
Incrementally delivering quality software.

The old ideas about testing at the end of the coding phase no longer applicable.

We need to think about the role of Quality.

Assurance in Agile Projects.

Definitely NOT business-as-usual.


An Agile Tester
A professional tester who embraces
change, collaborates well with both technical and
business people, and understands the concept of
using tests to document requirements and drive
development.
Agile testers tend to have good technical
skills, know how to collaborate with others to
automate tests, and are also experienced
exploratory testers.
They‟re willing to learn what customers do so that
they can better understand the customers‟
software requirements.


Traditional vs. Agile Testing
Phased Model e.g. Waterfall

Requirements Specifications Code Testing Release

Time

Agile:
F Iterative & Incremental
E
Each story is expanded, coded & tested
D D Possible release after each iteration
C C C
A B A B A B A B


Traditional vs. Agile Testing
Traditional Agile
In the phased approach diagram (see previous Agile is iterative and incremental (see previous
slide), it is clear that testing happens at the end, slide). This means that the testers test each
right before release. The diagram is idealistic, increment of coding as soon as it is finished. An
because it gives the impression there is as much iteration might be as short as one week, or as
time for testing as there is for coding. In many long as a month. The team builds and tests a little
projects, this is not the case. The testing gets bit of code, making sure it works correctly, and
“squished” because coding takes longer than then moves on to next piece that needs to be
expected, and because teams get into a code- built. Programmers never get ahead of the
and-fix cycle at the end. testers, because a story is not “done” until it has
been tested.
Tests are usually created from a requirements Rather than creating tests from a requirements
document. document that was created by business analysts
before anyone ever thought of writing a line of
code, someone will need to write tests that
illustrate the requirements for each story days or
hours before coding begins.


Role Testers Play
The role of the tester with agile methods is an area that has received increasing attention.
Initially with a focus on unit testing and „acceptance‟ testing it appeared the system tester
did not have a role in agile.

Unit Testing
Acceptance
Testing & System Testers are no longer
required?

Typical responsibilities for testers in agile can include (not limited to):
As Cem Kaner put it:
„The nature of the tester's role
changes in iterative projects. • Facilitate communication between the technical & business stakeholders
1
We are no longer the high-
profile victims, we are no 2
• Support early validation of requirements
longer the lonely advocates of
quality, we are merely (!) • Help the business stakeholders define acceptance criteria
3
competent service
providers, collaborating with a • Create automated acceptance tests
group that wants to achieve 4
high quality.‟
• Perform manual/exploratory tests on early-stage code
5

Testing and Testers on Agile Projects


It comes as no surprise to testers that
working software is not the same as code –
the tester clearly needs to be involved in not
only assessing the product, but in deciding
how the product is to be assessed.
However, with automated unit tests in the
hands of the coders, and confirmation-
focused acceptance testing driven by the
customer, testers should be aware that they
will not be the sole – or even the primary –
owner of deciding what works, and what
doesn‟t.


Testers need to be able to interact directly
with designers and coders to understand the
technological imperatives and restrictions that
affect the software and its unit tests.

Conversations and shared
understandings
Overall less
documentation
will take the required
place of

some documentation http://qtp.blogspot.com 11

Testing will be driven by what is important to a user, rather than to
fulfill a procedural requirement. It is better to have communication
between tester, customer and designer than to maintain
independence of the test team.

In practice, it is common to find large-scale automated unit
testing on agile projects, to confirm that code works as expected.
The product will be judged by the customer typically by
manual, confirmatory tests, with close observation for
undesirable behaviors. Testing by testers is often driven by the
need to measure the system‟s performance and to find surprises
– tools are very much in evidence, but rigid test scripts and
procedures do not give the requisite opportunity for
discovery, diagnosis and exploitation.


Testers are key collaborators with the customer, and on
some agile projects will take on much of the role of the
customer in designing and executing confirmation-driven
acceptance tests. However, although testers traditionally
make good customer advocates, working closely with a
customer is preferable to becoming a proxy.
Test strategies which lean heavily on an unchanging set
of requirements (for example: designing and coding tests to be
bought together with code late in the project; prioritizing tests based on
a fixed risk assessment; testing only what has been agreed in the
contract; reporting bugs only against fixed requirements) may be
considered to be fatally flawed in the light of this value.
Iterative collaboration is favored over a negotiated bill of
work.


While a developer is coding a task, it is
impossible for a tester to test it (it doesn't
exist yet). What then is the role of a tester
at this point.


Testers can prepare their test plans, test
cases, and automated tests for the user
stories before (or while) they are
implemented. This helps the team
discover any inconsistency or ambiguity
in the user stories even before the
developers write any code.


The tester could be working with the
customer to fine tune the stories in the
sprint.


They can often be involved in designing
the tests that the coder will write to perform
TDD.


If the agile team is fairly advanced then the
tester would normally be writing the ATDD
(Acceptance Test Driven Development)
tests. These could be in a tool such as
Fitnesse or Robot Framework or they
could be more advanced ruby tests or
even some other programming language.
Or in some cases, simple record and
playback can often be beneficial for a
small number of tests.


They would obviously be writing planning
some exploratory testing scenarios or
ideas.


The tricky thing to comprehend sometimes
for the team is that the story does not have
to be complete in order to drop it to the test
stack for testing. For example the coders
could drop a screen with half of the fields
planned on it. The tester could test this
half whilst the other half is being coded
and hence feedback in with early test
results. Testing doesn't have to take place
on "finished" stories.


Is the tester now involved in unit testing?
Is this done parallel to black box testing?


Don’t do Testers only test code that
Testers Unit Tests passes all of the automated
unit, integration and acceptance
tests, which are all written by
the developers. This split may
be different elsewhere, though;
for example your testers could
be writing automated
acceptance tests.

The whole point of unit tests is to test
the software is correct to avoid wasting
time later down the line. It's all about
instant feedback


What does the tester do during a sprint
where primarily infrastructural changes
have been made, that may only be
testable in unit testing?


Testers workload will vary between
sprints, but regression tests still need to be
run on these changes...


You may also find that having the testers
spend the first couple of days of each sprint
testing the tasks from the previous sprint may
help, however it's better to get them to nail
down the things that the developers are going
to be working on by writing their test plans.


Ensure that project or sprint requirements are
clear, measurable and testable. In an ideal
world each requirement will have a fit criterion
written down at this stage. Determine what
information needs to be automatically logged
to troubleshoot any defects.


Prepare a project specific test strategy and
determine which QA steps are going to be
required and at which project stages:
integration, stress, compatibility, usability, perf
ormance, beta testing etc. Determine
acceptable defect thresholds and work out
classification system for defect
severity, specify guidelines for defect
reporting.


Specify, arrange and prepare test environment:
test infrastructure and mock services as
necessary; prepare test data; write scripts to
quickly refresh test environment when necessary;
establish processes for defect
tracking, communication and resolution; prepare
for recruitment or recruit users for beta, usability
or acceptance testing. Write test scripts.


Ideally the tester would be working with the team
and the customer (who by the way, is part of the
team!) to define the planned stories and build in
some good, detailed acceptance criteria. This is
invaluable and can save loads of time later down
the line. The tester could also be learning new
automation techniques, planning test
environments, helping to document the outcome
of the planning.


Specific Technical Skills For Agile
Tester‟s Toolkit


Automation Skills

For automation to -> we need to apply
succeed -> good design practices

a single &
We strive to keep each automated test to
clear purpose

Learn how to evaluate and choose the right tools, so you
can help your team create maintainable automated
regression tests. You can free up time for essential testing
activities such as exploratory testing.

Acceptance Test-driven Development

Communication skills and good domain
understanding enable testers to help business
experts give good examples of both desired and
undesired system behavior.

We can turn these examples into tests that
help the programmers understand what code to
write. This is called acceptance test-driven
development, and it is a major step toward
building quality into the code and preventing defects.


Learning Styles

auditory learn by
Learning learners listening
Styles visual Learn by
learners see pictures

We all have blind spots that may prevent us from learning or triggers
where we shut down and don‟t hear the message anymore. Keep
your emotional “hot buttons” in mind and focus on what you can learn
from instructors, material, or teammates to enhance your abilities.
Mentors with different backgrounds or from other industries besides
testing and software development might work best with your learning
style. Don‟t limit yourself to coaches, mentors, and instructors who
work specifically in software testing.


Learning Resources Examples

Many good software

Testing books

Plenty of free material on the Internet

Resources your peers can provide

Communities of practice are another good place to
find mentors and learn together

Conferences are an obvious way to get a lot of new
ideas in a very short period of time

Mailing lists and social networks

Testing communities, such as Weekend Testers

References
• AGILE TESTING A PRACTICAL GUIDE FOR TESTERS AND AGILE
TEAMS by Lisa Crispin & Janet Gregory
• http://sqa.stackexchange.com/questions/1824/the-role-of-a-
software-tester-in-an-agile-environment
• http://searchsoftwarequality.techtarget.com/news/1243805/Role-
of-testing-in-agile-projects
• http://www.kohl.ca/blog/archives/000116.html
• http://www.mcbreen.ab.ca/talks/CAMUG.pdf
• http://newsweaver.ie/qualtech/e_article000847213.cfm?x=b11,0,w
• http://stackoverflow.com/questions/1640911/role-of-testers-in-
agile
• LEARNING FOR AGILE TESTERS, Part 2 by Lisa Crispin and Janet
Gregor, Better Software Magazine Sept/Oct 2011


Testing in agile

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Testing in agile

Semelhante a Testing in agile (20)

Último

Último (20)

Testing in agile