Solution Spotlight AGILE ALM: ATDD TO CONTINUOUS INTEGRATION

Transcription

1 Solution Spotlight AGILE ALM: ATDD TO CONTINUOUS INTEGRATION

2 A gility is all about producing a high-quality product in a shorter timeframe. In the past, organizations either sacrificed quality for speed or speed for quality. With Agile techniques such as ATDD and continuous integration and automation, organizations are able to have both speed and quality. This Solution Spotlight introduces the basics of ATDD and continuous integration including the benefits, trends and challenges of each technique. PAGE 2 OF 15

3 CONTINUOUS INTEGRATION: TOOLS AND TRENDS Crystal Bedell deployment and continuous delivery: Two trends that share their beginning in continuous integration. Regardless of how your organization is evolving beyond continuous integration, the CI tool you use plays an important part in your success. WhatIs.com defines continuous integration as a software engineering practice in which isolated changes are immediately tested and reported on when they are added to a larger code base. The premise of CI is to get feedback as early as possible because the earlier you get feedback, the less things cost to fix, says Sean Kenefick, Research Director, Application Platform Strategies, Gartner Inc. In addition to saving organizations money by catching problems earlier in the software development process, CI tools provide overall visibility into projects. Anyone can glance at a CI dashboard and basically see the health of the project, says Kenefick. Without the early feedback that CI provides, organizations suffer more than additional costs. If you don t get the early feedback, you ll be fixing things PAGE 3 OF 15

4 late. You ll have integration issues where people check in code and it breaks other people s code, says Kenefick. You ll have horrible, difficult merges because if you don t do CI, you re putting merges off. Merging code three weeks after writing it is much different than merging it right after you write it. TRENDS IN CONTINUOUS INTEGRATION Experts and analysts agree that continuous integration is paving the way for other trends that are quickly gaining momentum; namely, continuous deployment and continuous delivery. Both trends encompass CI and seek to address what happens after changes go into the build loop. The biggest evolution that we re seeing is people moving from CI to what they re calling continuous deployment, says Jeffrey Hammond, Principal Analyst, Forrester. Once changes are made, they are integrating and building them as soon as possible, at least on a daily basis... With continuous integration changes go immediately into the build loop and you end up with lots of builds. What do you do with them? deployment addresses that, he says. But, according to Paul Duvall, author of Integration: Improving Software Quality and Reducing Risk, continuous deployment can go a step further. Simply said, continuous deployment implies that you re deploying PAGE 4 OF 15

5 your software to some environment, but it doesn t mean that you re delivering software to users, he explains. Delivering software to users on a frequent basis is what continuous delivery is all about. deployment could be continually delivering software to just your testing environments. This is excellent, but you haven t necessarily gotten it to production yet. delivery implies continuous deployment, while continuous deployment does not imply continuous delivery. Whether your organization is focused on continuous deployment or continuous delivery, a CI tool is an important piece of the puzzle. CI tools help to facilitate not only building, testing and deploying software, but the entire release process, says Duvall. POPULAR TOOLS FOR CONTINUOUS INTEGRATION According to Kenefick, contextual Gartner research shows that folks are no longer going to big bang tools or methodology. They re letting individual groups choose their own tools and practices to see what works. The ones that work are trickling out. Kenefick acknowledges that allowing groups to use the tool of their choosing can create challenges when it comes to collaboration. However, he says, Enterprises are finding success with that approach. Things are getting PAGE 5 OF 15

6 better because we re letting people experiment. Organizations wishing to experiment with alternate CI tools have plenty of options. Popular open source tools include Hudson, Jenkins (the fork of Hudson), CruiseControl and CruiseControl.NET. Commercial tools include ThoughtWorks Go, Urbancode s Anthill Pro, Jetbrains Team City and Microsoft s Team Foundation Server. Most of the players in the CI market are pretty well established and the tools provide similar services. They don t greatly differ, even the open source ones, says Kenefick. The more expensive tools aren t necessarily better than open source and low cost tools. You just need to look at them and understand what they can do. CONTINUOUS INTEGRATION TOOL CAPABILITIES A common feature among CI tools is strong support for software configuration management (SCM) tools, says Kenefick. To this end, CI tools have plug-in systems that allow them to integrate with SCM tools as well as add functionality. If you want to create a test environment on the fly or a virtualized system to run on, a plug-in will allow you to write code for that, Kenefick explains. Other features to consider when evaluating CI tools cited by the experts we PAGE 6 OF 15

7 interviewed: visualization of the release process, a customizable, easy-to-read dashboard, trending, tool integration (issue management, peer review, testing, etc.), and the ability to create a process workflow. Ultimately, though, the CI tool that you choose should integrate with your ALM system. The idea is that you should be looking for best of breed and what will meet your needs, and then make sure it can integrate with your system, says Kenefick. If your ALM doesn t allow these integrations, you ll be stuck with the lowest common denominator. For a comprehensive resource on continuous integration, see integration: Achieving speed and quality in release management. PAGE 7 OF 15

8 ACCEPTANCE TEST-DRIVEN DEVELOPMENT: CUSTOMERS DRIVING TESTS Lisa Crispin Though development (TDD) has proven that writing before coding can produce better designed and higher quality code, often customer requirements can be misunderstood. This can be remedied by using a technique called acceptance development (ATDD) which will have customers involved in the test design process earlier. Whether you re a CIO, a stakeholder or a developer, ATDD is a technique that is important to understand. WHAT IS ATDD? ATDD is a technique aimed at helping the development team to collaborate with customers up front. By asking questions, hidden assumptions will surface and examples of desired system behavior will be revealed before the code is written. By using new test frameworks such as FIT and FitNesse, teams are able to turn examples into executable specifications that guide development. This technique had several different names. Brian Marick blogged about PAGE 8 OF 15

9 driving projects with examples. Joshua Kerievsky described story testdriven development. I first heard the terms acceptance test driven planning and acceptance test driven development from Richard Watt and David-Leigh Fellowes. Because Brian Marick s Agile testing matrix proved so useful, I preferred the label customer development or CTDD. To me, this reflected the intention that we write business-facing that reflect customer needs. I m not a good trend-setter, though this term did NOT catch on! Today, the term acceptance development or ATDD, which is used by expert practitioners and coaches such as Elisabeth Hendrickson, is widely used. Gojko Adzic has popularized an alternative description, Specification by Example or SBE. In his book of the same title, he presents case studies of over fifty teams successfully practicing this approach. Whatever the label, many teams all around the globe are successfully collaborating with their customers to get examples and requirements, turning those into executable, and using those to produce the software that the customers really want. Many new test libraries and frameworks are available to support these efforts. PAGE 9 OF 15

10 HOW ATDD WORKS Agile values direct us to avoid analysis paralysis and big design up front. However, we do need to know what customers expect for each user story before we start writing the code. Say we have the following user story: As a retail website customer, I would like to be able to delete items out of my shopping cart so that I can check out with only the items I want. We want the customer to tell us, via and examples, how she ll know when this story is complete. We ask open-ended questions to help the customer think about the feature from multiple viewpoints. For the story to delete items out of the shopping cart, we might ask questions such as: Should there be a dialog to confirm a delete? Is there a need to save the deleted items for later? Can you draw a picture of how you want the delete function to look? What should happen if all items in the cart are deleted? What if the user has two sessions open with items in the cart, and deletes an item in only one of the sessions? We draw on whiteboards (real or virtual) with our customers, and use PAGE 10 OF 15

11 brainstorming and visualization techniques such as mind mapping and story mapping. We express the resulting examples as executable, starting with the happy path, in an appropriate automated test framework. In the case of this example, we d most likely find that this story is more of an epic, and slice it into smaller increments. As the programmers write the code, they automate the happy path test, and we start adding different conditions, exploring different aspects of behavior, including boundary and negative. As we develop the and code in tiny increments, once the automated pass, we ll dive deeper with exploratory testing, which will probably produce more desired and undesired behaviors represented by. Automated specifications are only part of our strategy to delight our customers. We also demo each increment of the new feature to the stakeholders, and tweak the functionality as needed. When the are passing, they may form part of our automated regression test suites. Once green, they must stay that way. If a regression failure occurs, or a test needs updating to reflect a change to production code, we stop what we re doing and get it passing again. PAGE 11 OF 15

12 A REAL-LIFE EXAMPLE My team had to experiment to find the sweet spot for providing just the right level of detail to the coders. I started out by collaborating with our product owner to write dozens of detailed, weeks in advance. When coding began, the programmers found that the intricately detailed obscured the main purpose of the story. In addition, the test design was incompatible with the code design they had evolved using TDD. We learned to write high level together as a team during our iteration pre-planning and planning meetings. This gives us a shared understanding of the big picture for each story. Once coding begins, a tester works with a programmer to specify a basic happy-path test. Once that test passes, the tester specifies more test cases. This process is a series of tiny test-code-test iterations, building up small slices of the user story. Collaborating on these may reveal conflicting ideas about how the code should work. For example, the tester expects that when the shopping cart is empty, the user is returned to the main shopping page, but the programmer expects the user to remain in the empty shopping cart. They go talk to the product owner, and perhaps other stakeholders, to decide the desired behavior. Discussions like these flush out hidden assumptions and reduce the chance for PAGE 12 OF 15

13 missed or misunderstood requirements. THE BIGGEST BENEFITS OF ATDD ATDD helps us nail the business needs on the first try, and become part of our short feedback loop in the form of automated regression suites. But the most important benefit of these has already been delivered: writing the requires communication among testers, programmers and business experts. Another major plus is that the become living documentation. When you run your automated regression with each code check-in, you re forced to update the as code is changed or added. If a business person has questions about how some feature works, we can go right to the automated to demonstrate the actual behavior. This type of documentation, in my experience, is far more useful than a text document that never gets updated after the code is released. It takes a big investment of time to learn to do ATDD effectively. While your team is experimenting to find the approach and tools that work best for your situation, you ll deliver less new functionality with each iteration. However, each user story released will meet customer expectations, and you won t waste PAGE 13 OF 15

14 time with re-work. By writing the right code, supported by automated regression that provide quick feedback, you ll keep your technical debt low. You ll build a library of living documentation. Like my team, yours will deliver business value frequently, while working at a sustainable pace, and realize a huge return on your investment in ATDD. PAGE 14 OF 15

15 FREE RESOURCES FOR TECHNOLOGY PROFESSIONALS TechTarget publishes targeted technology media that address your need for information and resources for researching products, developing strategy and making cost-effective purchase decisions. Our network of technology-specific Web sites gives you access to industry experts, independent content and analysis and the Web s largest library of vendor-provided white papers, webcasts, podcasts, videos, virtual trade shows, research reports and more drawing on the rich R&D resources of technology providers to address market trends, challenges and solutions. Our live events and virtual seminars give you access to vendor neutral, expert commentary and advice on the issues and challenges you face daily. Our social community IT Knowledge Exchange allows you to share real world information in real time with peers and experts. WHAT MAKES TECHTARGET UNIQUE? TechTarget is squarely focused on the enterprise IT space. Our team of editors and network of industry experts provide the richest, most relevant content to IT professionals and management. We leverage the immediacy of the Web, the networking and face-to-face opportunities of events and virtual events, and the ability to interact with peers all to create compelling and actionable information for enterprise IT professionals across all industries and markets. PAGE 15 OF 15