Agile Dev Method Testers

8/6/2019 Agile Dev Method Testers

http://slidepdf.com/reader/full/agile-dev-method-testers 1/13

Task 1

Task 2

F ood for thought

A Practical Guide to Dening Testing Practices

By Peter Varhol, Seapine Solutions Evangelist



Copyright © 2010 Seapine Software, Inc.

This work is licensed under the Creative Commons Attribution-Noncommercial-No

Derivative Works 3.0 United States License. To view a copy of this license, visit

http://creativecommons.org/licenses/by-nc-nd/3.0/us/ or send a letter to Creative

Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

Seapine is proud to be a member of the Agile Alliance.



Table of Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0 4

Traditional Testing and the Transition to Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0 5

The Traditional Starting Point . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 0 5

Developers and Agile . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . 0 6

Agile and Testers: It Only Makes Sense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0 8

Steps to Quality Sotware With Agile Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1



Here’s how testers can redefne testing or Agile d

including a list o activities that can help turn te

essential part o any Agile process.

IntroductionEnterprise application development teams are increasingly

adopting Agile sotware development techniques as the

principal method o building custom applications or business

advantage. Agile methodologies, such as Scrum, Extreme

Programming, Feature-Driven Development, and Agile Unifed

Process, oer the ability to iteratively develop applications

with participation rom the end user community.

Whatever the Agile process used, the role or testers is not

always clear. Testers who seek to better understand how testing

can impact Agile development methodologies, and their roles

in Agile testing, must take the lead in defning just what those

roles are. By understanding Agile development processes and

how testing can improve quality in these processes, testers can

defne their role as essential to building quality sotware.



rom the process. Instead, one or more busin

interact with users to determine the business r

which are passed on to developers and testers. Te

developing plans and individual tests to validate

against the requirements. Testers not only look

sotware bugs, but also or deviations rom

requirements. In this manner, they ensure bot

level o sotware quality and a specifc ftness o

purpose.

Because sotware is complex, testers put in a la

o work both beore and during testing. Whil

are translating requirements into specifcations

preparing test plans and test cases. This docum

Traditional Testing and

the Transition to Agile Traditional testing practices have taken their lead rom

the Waterall model o sotware development, where

requirements gathering, sotware design, and implementation

ollow a deliberate and oten lengthy path. While quality

remains important with all Agile practices, it can be dicult

to map existing quality strategies to a new and accelerated

methodology.

The Traditional Starting PointIn traditional sotware development methodologies,

testers meticulously examine requirements, determine the

appropriate way o measuring quality, and devise a plan to

assure those requirements have been implemented through

unctional and regression testing during the latter stages o

code development. The prospective sotware user is removed



which are high-level scenarios o how the prospecwould be used as a part o a business process.

The team, including the product owner, dev

testers, take these user stories, organize the

them as a basis or designing and building

incrementally. Typically taking three to fve us

a time, developers will reserve anywhere rom

month to implement that subset o stories, depeAgile approach used and the complexity o the

eatures supporting those stories are coded, and

that time those eatures are operational. The do

works with developers to answer questions

ambiguities as the stories are translated ro

processes to sotware eatures.

easily run into the hundreds or even thousands o pages.

Once the development team starts building the sotware,

testers execute the test plan, running relevant test cases as the

eatures gradually become available. Bugs and deviations rom

requirements are logged and described, and developers fx

bugs as well as write new code.

Developers and AgileAgile methodologies ocus on immediate and rapid code

development, and less on upront documentation. They do

this through involvement by product owners rom the user

community, who work closely with the development team to

defne and validate the sotware. Domain experts defne the

unctional requirements o the sotware through user stories,



Ater that set o stories has been implemented,expert validates the sotware with respect to thos

the process begins again with the next set o use

process is perormed rapidly, and the application

and built almost continually, so the coded a

eatures can be deployed at any point in time.

Because the sotware can be built at the end o ea

and has been validated by domain experts, itbe deployed to the business at any time. This

doesn’t have to be a year-long development

which the business needs have likely changed.

can be deployed early and oten, making eature

users early, while adjusting later eatures in resp

eedback and changing business needs.

Def ine Requirements

Story F inding/In it ia l

Estimat ion

H ig h-Leve l Planning

System Test ing

R EL EASE

No

YesWrite Story and Scenario

Stories Left to P lay?

Qual ity Assurance

Dep loy

Execute F unctiona l ityand Accep t ance T ests

Begin Iteration

Figure 1. Agile development repeats a sequence o code, test, and deploy



measure their completion. This is a business aspe

that is not typically the ocus in traditional metho

I the domain expert is the principal author o the

likely that he or she is making assumptions abouor the business process that is implicit in the story

not apparent to the development team. These

can lead to misunderstandings with the deve

may not ully comprehend the assumptions or p

Testers are in an ideal position to work with the do

to clariy assumptions and make them explicit, an

any ambiguities in those stories beore developer

rom them.

The business analyst has oten flled this ro

business analysts and testers can work together

this process. By combining responsibilities, testers

analysts each do what they do best—turn user r

into high-quality applications.

Agile and Testers: It Only Makes SenseAt frst glance, an Agile process seems to leave little or

application testers to accomplish. The connection between

the end user and the developers appears to be direct, so

a need to ensure the fnal product was what users wanted

seems unwarranted. And, because the domain expert triesthe sotware multiple times during the process, mid-course

corrections seem seamless and straightorward. Developers

can fnd and fx the obvious bugs, while domain experts ensure

ftness or purpose.

However, independent testing is still vital. Quality is still one o

the most important requirements in an enterprise application,

and testing is the primary way o veriying quality and assuringthat the process produces quality sotware. But testers have to

substantially change their approach to doing their jobs in order

to assume an essential role in Agile development.

Because o their unique position in the application development

liecycle, testers are best equipped to connect business needs

with actual results. In particular, testers are in the best position

to codiy user stories, and to determine how to objectively



Agile methodologies tend to leave acceptanc

to the domain expert, but that person is unlik

expert in evaluating sotware, even against crite

defned. Testers are especially qualifed to fll that

it is the essence o the proession. In traditional treerred to as acceptance testing—the practice

that every business requirement has been satis

a corresponding sotware eature. To acilitate

testing, testers need to be intimately involved wit

user stories into application eatures. Doing so

ability or them to understand what the user

intended, and how it was translated into the appl

In Agile development, acceptance testing needs to

at the user story level. Making the crucial transitio

to implemented eature and back to story requires

in the story refnement, the breaking down o

eatures, and the development o cases to test tho

Because testing is accelerated, it must be ocused on the needs

o the user community in addition to technical quality. All test

cases should tie back to the user stories. By enabling testers

and domain experts to work together to defne the scope o

the sotware, the testers are in the best position to determine

how best to test the stories once they have been implemented.

Test ing Act iv it ies

Tec h no logy-

Fac ing

Technica l

Testing

Deve lop mentSup p ort

Bus inessT est ing

Business

Sup p ort

Business-Facing

Figure 2. Testers have both technology-acing and business-acing responsibilities



A requirements and test management package

testers to record user stories and resulting ea

tracking acceptance test results back to both eat

stories.

Likewise, unctional, regression, and acceptance

be perormed manually, at the cost o addition

resources. Ater tests are validated, most can

automatically, even as part o the build process

to accelerating testing and ultimately user accep

application, automation ensures repeatability o

part o the Agile development process.

This level o up-ront involvement makes getting rom user

story to acceptance test signiicantly easier. Tracing the

implementation o user stories has the potential to be much

aster and simpler, and require ar less overhead. Because

developers aren’t writing extensive specifcations, and test

plans aren’t required to reect those non-existent specifcations,

testers can go right to building test cases that reect the

particulars o one or more user stories. An acceptance test case

should enable the product owner to veriy and validate that

the user story has been implemented correctly.

Virtually all o these activities can be improved and accelerated

with automation. Tracking a story rom inception to acceptance

test can be done manually, but that requires testers to spend

time examining documentation to perorm that activity.



3. Translate testing requirements into test cases

as possible. Work with users and business ana

to ensure that the test cases reect real busine

Work with developers to devise technology-a

4. Automate test cases and test execution so tha

be rerun automatically as part o the build pro

automation ensures that any regression bug is

corrected quickly.

5. Track test case execution to ensure the ftness

application. Be able to report on test execution at

so decisions can be made about application dep

6. Trace requirements rom inception to delivery

business needs have been adequately address

may need to add requirements and tests later in

the process, or delete obsolete requirements.

Steps to Quality SoftwareWith Agile ProcessesFor testers to take a leadership role in assuring quality in Agile

sotware development and delivery, they have to work with,

and at the pace o, the project. Testers must work with both

users and developers in defning the project and ensuring its

quality and ftness or the user business needs.

Following are the key steps to preparing and executing testing

on an Agile project:

1. Get to know the domain expert and user community.

Understand undamentally the business goals o

the application. Your testing goals serve that group.

2. Break user stories into prioritized testing requirements

and track those requirements to completion. Use

automated systems to capture user stories, distill

requirements, and trace requirements through to

implementation and back to user stories.



These are the major ways that testers can demo

and make essential contributions to sotware d

and delivery in an Agile process. An equal ocus

business and the technology, with support or th

plus the development project, is critical in ens

make a complete contribution to project success

o these activities can also ensure timeliness and

o testing activities, not only in the current iteratio

iterations as well.

Business-Facing

Funct ional T ests E xp lor at or y T est ingS cenar iosUsabi l ity Test ing

S ecur ity Testing

T echno logy-Fac ing

C r

i t i q

u e

P

r

o d u c

t S

u p p o r t i

n g t

h e

T e

a m

Unit TestsC om

p onent Tes

ts

“- i l ity" Test ing

A lp ha / Beta

Examp lesStory TestsPrototyp esS imu lations

Ag i le Test ing Quadrants

Q2 Q3

Q 4 Q 1

P e r f or mance Load Test ing

User Accep tance Test i ng

Figure 3. Many testing activities can be automated, supporting project and team goals



Peter Varhol is a well-known writer and speaker on software and technology

topics, having authored dozens of articles and spoken at a number of industry

conferences and webcasts. He has advanced degrees in computer science,

applied mathematics, and psychology, and is currently Solutions Evangelist at

Seapine Software. His past roles include technology journalist, software product

manager, software developer, and university professor.

About the Author

Documents

Agile Dev Method Testers