4aa3-2489enw agile automation

7/30/2019 4AA3-2489ENW Agile Automation

1/4

Agile automation: A primer on testautomation in Agile projectsBusiness white paper


2/4

2

January February March April

1

omponent

Stable component

1 1 1

2 2

3 3

4 4

QA automates once stablein Sprint+1

Figure 1: The Sprint+1 Law of Automated Testing

2

Heres a methodology riddle: What is the one aim of Agile, without which a project becomes little betteroff than it wouldve been with traditional Waterfall?

The early discovery of issues

Where sequential methods leave application validationto a mass effort at the end stages of the project,

Agile concentrates teams on developing potentiallyreleasable code for each sprint. This means that sprintby sprint, the work of the project team is put througha proper quality vetting, with the aim of uncoveringproblems and changes early enough to be addressablewithout the usual last-minute general panic.

So crucial is this aim that most Agile teams understandquality to be the responsibility not of a specificindividual or department, but of the entire team.Indeed, this all-hands quality concept is important,because properly validating an application as itdevelops poses a unique set of challenges. Foremostamong these is the role and use of automated testing.

ant live with it, cant live without it Ask a QA Director whose team has recentlyengaged in Agile projects how test automation isbeing leveraged, and youre likely to see her closeher eyes and wish herself somewhere else. Its anunderstandable response. Since automated testingrequires an investment in designing and developingthe framework and scripts, the payout is usuallyhighest when applied to mature (read: stable)applications. Under Waterfall methods, the majorityof the application is baked before arriving in thetesters hands. But Agile projects, with their embrace

of regular change and ever-evolving features, are anautomated testers nightmare.

And yet, the hard truth is that without automatedtesting, Agile delivery isnt possible. Unlike unittesting, which focuses almost exclusively on thefunctionality within the current sprint, the challengesof system tests expand with each sprint. Systemtesting must encompass not only the new functionalityof the current sprint, but also features from previoussprintsas well as regression testing any legacyfunctionality. Automated testing is the only way toensure complete coverage of both legacy and newfunctionality, performance and security, all insprint-time.

Put another way, Agile without test automation isessentially Waterfall by another name. Developersmay create code and run unit tests on a regular sprintcadence, but proper system validation is deferredto later and later phases; there simply isnt time tomanually test the accumulating functionality fromsprint to sprint. Inevitably the team encounters surprise

problems late in the game, and must incur budgeand/or deadline overruns to address them. Projecworking in this mode may give off the appearancspeedbut only until just before the end.

Where to startFirst things first: incorporating test automation rethat teams have some standing criteria for decidiwhat is to be automated. No project, whatever itsmethodology, will automate every last test. Manutesting will always play a vital and necessary rolas well.

In general, test automation makes sense for: functionality which is critical to the business or

supports many concurrent users; functionality that has been assigned specific

service-level agreements (SLA); functionality which touches multiple areas of th

application (or other applications); tasks which are either repetitive or error prone,

as data loading, system configuration, etc; testing that involves multiple hardware or softw

configurations.

Establishing the test automation criteria upfront hto the team to make consistent, pragmatic decisioabout automation, and will reduce the cycles anddecision analysis which are unfavorable to Agilesprint-time.

Speed and (not or) quality As a general rule of thumb, we advise customersautomated test creation lag by no more than onesprint. In other words, the exit criteria for a seconsprint includes the agreed upon automation for thfunctionality of the first sprint, and so on.

Note: This paper is first in aseries on effective testing inAgile projects.


3/4

January

1

GUI-less component GUI elementG Business ProcessBP

May

G1

5

1

2

3

4

June

G1

5

G2

1

2

3

4

J

G

G

B

Multi-layered testing allows automationin advance of GUI

February

1

2 2

March

1

3

4

April

G1

1

2

3

4

Figure 2: Multi-layered Automated Testing in AgileThis rule recognizes that rarely is there enough timewithin a sprint to automate the tests of that sprint. But italso lessens the temptation to let test automation slideto later and later sprints. Furthermore, this sprint+1law of automated testing helps to ensure (a) that timefor test automation is allocated to each sprint, and(b) that if the team is not able to complete its targetautomation, the gap in remaining work is treated justas a code gap would be. That is, either the sprint isextended to complete the work, or the outstanding

tasks are moved to the backlog for allocation tofuture sprints.

In speaking with customers who are struggling tointegrate automated testing into Agile, our firstquestion involves just this use of the backlog. Is thebacklog being used to capture test automation tasksthat were planned but left incomplete in the sprint?

All too often, the answer is no. The upshot of thisis that critical work remains hidden to the scrummaster. Again, think of it in terms of code: whatwould be the ramification if the backlog wasnt areliable measure of completed features? The work

to automate tests is as necessary to Agile projectsuccess as code creation.

The plot thickens As a final complication, modern applications are notthe stovepiped things of several years ago. Todaysapplication is more often a conglomerate of headless(that is, GUI-less) services and sub-applications. Thismeans test automation can no longer assume eachcomponent will have a GUI element to record against.However, these componentized or compositeapplications also provide automated testers anadvantage in Agile. With the right tools, teams are ableto start automated testing before the GUI componentsare stable, or even available.

In early sprints, teams may be engaged primarilyat the component or service layer. This means testautomation that is centered around API, protocol, and

Web service validation. As the application evolves,the team develops test automation for the GUI andbusiness process (that is, cross-application) layers.

Having developed automated tests from the servto GUI layers, the team is well positioned in latesprints to create more complex test scenarios whtraverse multiple layers of the application stack wthe same testalso called multi-layered testing. example might be a test that fetches data via a wservices or API interface to a database, and thenthe data for the rest of the test scenario at the GUlayer. This strategy provides greater test coveragwhile uncovering defects that might not otherwisencountered until production.


4/4

Get connectedwww.hp.com/go/getconnected

Get the insider view on tech trends, alerts, andHP solutions for better business outcomes

opyright 2011 Hewlett-Packard Development ompany, L.P. The information contained herein is subject to change without notice. The onlywarranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing hereinhould be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

AA3-2489ENW, reated January 2011; Updated March 2011, Rev. 1

onclusion While many Agile teams will say quality is ateam-wide responsibility, too few recognize that thismeans test automation is co-equal in importance tocode. Successful Agile teams know: Time must be explicitly allocated for test automation

in each sprint Automation should begin as early as possible and

should not lag by more than one sprint

When assessing the results of a sprint, theautomation goals should be considered as vitalthe development objectives

Multi-layered testing allows for test automationadvance of GUI stability, and furthers test cove

To hear about the real-life experiences of how Horganization has applied test automation in their projects, visit YouTube at:http://www.youtube.com/hewlettpackardvideos#p/search/1/LhdFgoHOUSw

Shift the way your organization thinks; transition from traditional waterfall software approaches to iteraagile methodologies with HP Software, visitwww.hp.com/go/agile .
http://www.youtube.com/hewlettpackardvideos#p/search/1/LhdFgoHOUSwhttp://www.youtube.com/hewlettpackardvideos#p/search/1/LhdFgoHOUSwhttps://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11^44268_4000_100__&jumpid=ex_R11374_us/en/large/eb/go_agilehttps://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11^44268_4000_100__&jumpid=ex_R11374_us/en/large/eb/go_agilehttp://www.youtube.com/hewlettpackardvideos#p/search/1/LhdFgoHOUSwhttp://www.youtube.com/hewlettpackardvideos#p/search/1/LhdFgoHOUSw

4aa3-2489enw agile automation

Documents