• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Flow for agile testing - lssc11 proceedings
 

Flow for agile testing - lssc11 proceedings

on

  • 785 views

 

Statistics

Views

Total Views
785
Views on SlideShare
781
Embed Views
4

Actions

Likes
0
Downloads
9
Comments
0

2 Embeds 4

http://www.linkedin.com 3
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Flow for agile testing - lssc11 proceedings Flow for agile testing - lssc11 proceedings Document Transcript

    • Using Flow approaches to effectively manage Agile Testing by Yuval Yeret Yuval@AgileSparks.comABSTRACT This paper will focus on improving agility in complex environments, where it isnot realistic to finish all required work, and especially testing work, within one sprint,so classic agile iterations fall short. This paper will introduce a more generic flow-based recipe for these environments. I will outline techniques for visualizing andreducing testing batch sizes within sprints/releases using Cumulative Flow Diagrams,discuss how to deal with the testing bottleneck that is so common in productdevelopment organizations, and discuss how to deal with policies rooted in thecurrent big batch approach to product development.
    • 2INTRODUCTION A rapidly increasing amount of organizations want to become more agile thesedays. Several field case studies show that when an enterprise-level organizationundertakes this endeavor, it ends up having a significant stabilization/hardeningphase, usually in the order of 30% of the effort and schedule of the whole release.This is a result of the high transaction costs associated with running testing cycles,aiming to locally optimize the testing efficiency by reducing the number of cycles andthe pursuit of scale economy. The lean/kanban practitioner will be worried by thispoint, and will not be surprised to learn that a lot of waste, ineffective handoffs, andmountains of rework usually ensue. The result is typically low predictability as towhether this stabilization phase ends on time and whether the end result will be inrelease-level quality. This is the culmination of the big batch thinking that is inherentto traditional software development approaches. It also drives a destructivecycle oflonger and longer stabilization phases when we see we cannot deliver quality on time.We set a policy of longer stabilization feature freeze. We have less time to actuallydevelop so we run aneven faster and more reckless development cycle. Testing is deemed more and more expensive, so we try to make it moreefficient by running less and less cycles. Integration is deemed expensive andproblematic, so we set a policy of integration just after the parts are complete and inhigh quality, while forgetting that the real quality challenges of the day are theintegration aspects, which should be dealt with as early as possible.GOING AGILE ALL THE WAY When such an organization starts the move to agile, several scenarios canmaterialize. The ideal alternative is for agile teams to take on all of the stabilizationwork as part of their definition of done and deliver working, tested software that isrelease ready within each increment/iteration/sprint. Furthermore, accompaniedwith massive test automation, this minimizes the regression/stabilization cycle effort,and the stabilization phase can be expected to shrink dramatically.AGILE IN COMPLEX ENVIRONMENTS Another scenario happens in more complex environments. When moving to full-scale agile teams, the regression effort and the scope of testing coverage required arestill extremely high, making it an impossible endeavor for the agile team to solve theproblem as easily as before. First, it is not always feasible to complete all therequired testing work on a story within a sprint. Second, even if it is possible,ensuring no regression impact due to those stories is a transaction cost that is eithernot feasible or not economically reasonable. Third, sometimes the work required to
    • 3take a story to release-level quality is again more than a sprint can contain. Aspectslike Enterprise-Readiness, Performance, and Security, applied to a big legacy system,require specialized approaches, special skills, labs, and time. Typically the agile teamruns at a certain pace, delivering a certain level of working and tested software. Thenthere is a process outside the team of taking that software and making it releasequality. The focus of this work is to assist organizations in managing this complexprocess, applying lean/agile principles of product development flow in order toreduce the overall price of quality and improve the overall predictability.Figure 1. Testing Gaps in Complex Agile EnvironmentsA MORE EVOLUTIONARY APPROACH TO AGILITY Another scenario is the organizations that want to improve their developmentprocesses using a more evolutionary approach (Anderson2010). In this context, theconcept of an agile team doesn’t even necessarily exist, so the level of “doneness” ofwork is even lower at the outset.LOOKING FOR A SPECIFIC SOLUTION TO ESCALATING RELEASE COSTS Lastly, we see several organizations that are looking specifically for a solutionto this problem. They are not looking to become more agile per se but they arefocused on reducing the cost of releasing and improving their due date performance.Yes, they see that it will allow shorter releases and better maneuverability, but it is asecondary side benefit for them.IMPROVING STABILIZATION IN COMPLEX SCENARIOS This paper will present a recipe that can be applied to these scenarios in orderto reduce the cost of stabilization while improving its predictability by applying the
    • 4principles of agility and flow without assuming full team-level agility and engineeringpractices. I want to emphasize the last point. The typical agile practitioner will claim thatall of this headache can be resolved by going on the agile diet,that extremeprogramming accompanied by a strict pure Scrum process will resolve all of theproblems. I tend to agree. But not all organizations want to (or can) go on thisextreme "diet." Not all of them can afford the change on a short time frame, and evenworse, at the higher levels of complexity and enterprise scale, agile would certainlyhelp but it would not be enough to resolve the problem completely. As the reader willsee later on, the recipe includes certain key practices from the agile diet, albeit in aform that can be adopted as part of an evolutionary process.IDENTIFYING A GOOD SOLUTION How will we know we have a good solution for our problem? We will have toimprove in two key aspects. The first is to achieve a major reduction in the length ofthe stabilization/hardening phase. The second is to dramatically improve thepredictability of the release due date while still meeting the release criteria.WHAT CAUSES THE PROBLEM Let us start our journey towards a solution by understanding what the rootcauses of the problem are. Figure1 shows a current reality tree (Dettmer 1998) thathelps us understand the cause and effect relationships. Why is stabilization cost so high? Mainly because we get late feedback on ourdecisions, and we know that late quality is more expensive quality. Why do we getlate feedback? Because we prefer to work in big batches due to high costs of everystabilization cycle and since we believe it is the efficient and right way to do things.We believe we cannot really achieve good coverage and certainty about the quality ofthe release without running a big batch once everything is ready. In addition,sometimes features aren’t ready for feedback until late in the cycle. Why?Sometimesit is because they are big features. Another reason is that we are notfocusing on just a few features, we are working on many features in parallel (featureper engineer sometimes) which means they will take a lot of calendar time due toexcessive multi-tasking at the organization level. Note that even if eachengineer/team is single-tasking, if we are multiplexing stories/work from variousfeatures, then at the organization/release level we are still multi-tasking. (Why, bythe way, do we typically see many features in progress? We tend tobelieve it is moreefficient, minimizes coordination overhead, gives more ownership to the FeatureOwner, and many engineers prefer to run solo.)
    • 5Figure 1d Current Reality of Stabilization Costs All this means quality is “added” after the fact. As documented in Capers JonesCost of Quality (1980), the later we find and deal with defects the more expensive itbecomes.Late quality is expensive. With this dynamic in place, we have two options: protect the quality andcompromise on due date performance orprotect the due date and compromise onquality, whether explicit or implicit. The team is driven hard, way beyond sustainablepace, and they find the ways to "make ends meet." Bugs are ignored, quick and dirtylocal fixes are applied, etc. This increases the lack of predictability of how this sagawill end and when.WORKING TOWARDS A SOLUTION So what do we do about the problem? One option we discussed before is to goagile all the way.We will not outline the details of this solution here to maintainbrevity. Note though that even in some agile team scenarios leftovers of untestedunfinished work will accumulate after each sprint. Beyond high stabilization costs,sometimes the gap grows to such an extent that there is no option but to throw awayfeatures that were already developed once it is understood there is no way to testthem in the release. When this happens, the morale of the team sinks. We usually seeit happening around the time the developers are asked to go help the testers dealwith the remaining features that are not trashed. In addition, there is typically a drive towards developing functionality as fast aspossible and leaving defects for later. This policy makes sense when a feature freeze
    • 6phase is mandated. The main thing the developers can do during this period is fixdefects. If you fix defects earlier, you deliver less functionality until feature freeze. Ifyou CAN defer defect fixing to after the feature freeze cutoff date, this is what youwill do. This problem exists even in some agile teams.DONE IS DONE The first step towards a solution is to consider a feature as "Done" only if it iscompletely finished and can pass its release-grade criteria. This means it has passedall of its test coverage, and all the defects that need to be fixed and verified to passrelease grade criteria have been dealt with. (For project management purposes wewill track which features are done, and which are still in progress.) The importantpoint to note is that even if stories or aspects of this feature have been completed inan agile team, the feature itself will be considered just work in progress.LIMITING FEATURES IN PROGRESS Next, limit the amount of features that can be in progress. Allow the startingof a new feature only if a previous one is really finished and release ready and theamount of open defects is below a certain low threshold.This limit synchronizes theproject.However, it doesn’t require the extreme synchronization that happens insidean agile team.DEALING WITH THE TESTING BOTTLENECK AT THE TACTICAL LEVEL Developers will be asked to optimize features reaching Done rather thanfeatures reaching Coded. This might mean investing more in quality at the coderlevel (automated unit tests come to mind), reducing the number of defects deliveredwith the code by doing code reviews or pair programming, etc. Readers familiar withthe Theory of Constraints will recognize this as exploiting the testing constraint –exploit being one of the 5 5 focusing steps–[The goal Cox, Jeff; Goldratt, Eliyahu M.[1986]
    • 7Figure 2. What developers can do during an active testing bottleneckAVOIDING THE DANGERS OF BOTTLENECKS In many cases, even after increasing quality of Coded features a testing gapwill still be apparent.Are we really asking developers to slow down and avoid codingnew features? This might lead to lost capacity in the release and to lower capabilitiesover time if the developers “forget how to run fast” (Anderson 2004 ). We want toavoid this. Instead, let’s identify work types that don’t need to go through thebottleneck or that require less capacity from it. Choose work that is not testing-heavy, or items that can be tested without the involvement of the testingbottleneck.This introduces an internal operations factor into the priority filter, butclearly this optimizes for overall business value outcome.INVESTING TO ELEVATE BOTTLENECKS To elevate a testing bottleneck, create a backlog of engineering investmentsthat will improve testing capacity, usually by reducing the amount of work neededper feature.The best example is, of course, test automation that can convenientlyalso be developed by developers. This backlog solves the slowdown problem. It also isa more sensitive solution than “Have slack in the system” to the slack created bysprint commitment and Limited WIP. Involve your teams in building the EngineeringInvestment backlogs to increase their commitment to this approach. Experiencealoshows that higher commitment exists when working to elevate rather than locallydeal with a problem.THE TEST AUTOMATION PYRAMID HELPS ELEVATING BOTTLENECKS In the context of testing, leverage the recommendation of the “TestAutomation Pyramid” (Crispin and Gregory, 2009) to achieve a win-win: Reduce thecost of test automation by doing more of it in layers that are cheaper to maintain,like
    • 8unit testing and service/api-level testing rather than at the UI level, and benefitfrom the fact that these layers are closer to the comfort zone of the developers.Extend the “Pyramid” to all of the testing aspects required to get a feature torelease-ready. Considering this work as part of the flow/bottleneck optimizationpicture is key to achieving lower stabilization costs and better release flows.Considerthis a form of “Continuous Stabilization” or “Continuous Hardening”.Figure 3. What developers can do to elevate a testing bottleneck
    • 9SAFELY TRANSITIONING TO A SHORTER STABILIZATION PERIOD Finally, choose when to go into stabilization (and stop developing newfeatures) based on metrics presented earlier. If the number of open defects is low,and there is a low amount of feature work in progress, it might be safe to proceedfurther with new features. If defects are mounting, and lots of features are inprogress, risk is high, and it is best to aim for stabilization as quickly as possible, or atleast to stop the line, reduce the work in progress, and then reconsider.Figure 4. Dynamic decision to go into hardening phase
    • 10CONCLUSION To summarize, in many product development scenarios, whether agile or not,escalating stabilization costs are a painful problem in need of a solution. Lean/agileapproaches can help reduce the problem. We outlined a solution relying on an end-to-end pragmatic approach that doesn’t require a revolution in the way the product isdeveloped, instead driving an evolutionary focused improvement by tying all the partstogether and aiming at global optimization. This solution can be applied in the field aspart of agile implementation projects, on a standalone basis, or as a preamble thatwill drive the understanding that a more agile approach needs to be adopted as a wayto improve on the bottlenecks identified by this method.
    • 11REFERENCESAnderson, David (2010). Kanban, Blue Hole Press, Sequim, WashingtonDettmer, H. W., (1998) Breaking the constraints to world class performance. ASQ Quality Press, Milwaukee, WI.,pp 69-102.Jones, Capers (3rd edition 2008) Applied Software Measurement, McGraw Hill, New York, NY, USAGoldratt, Eliyahu M. &Coxx, Jeff(1986). The goal: a process of ongoing improvement, North River Press, Great Barrington, MAAnderson, David (2004) Four Roles of Agile ManagementCutter IT Journal. Retrieved 10 March 2011 from http://www.agilemanagement.net/AMPDFArchive/FourRolesFinalRev0804.pdfCrispin Lisa & Gregory Janet (2009) Agile Testing: A Practical Guide for Testers and Agile Teams, Addison-Wesley Professional, Reading, MAReinertsen, Don (2009). The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, Redondo Beach, CA