|
|
Test-Driven Everything When you hear people talk about test-first or test-driven, you probably think of testing the code. Test-driven practices help developers reduce defects and increase the value in the code and the designs they deliver. Sadly, "test-driven" is too often confined to the coding trenches, and project communities miss the value of test-driven as a way to produce more value and less waste in other areas. David Hussman challenges you to think about test-driven beyond the coding realm. In addition to test-driven development, it is possible to test drive projects, meetings, and more. David begins by describing test-driven development and why it is often devalued or even dropped. Then he explains about using project chartering and story test-driven development as concrete tools for infusing test-driven everything across your project community. As a result, you will find defects, remove duplication, and discover dependencies sooner.
|
David Hussman, DevJam
|
|
|
From Concept to Product Backlog: What Happens Before Iteration Zero Many agile methodologies start with a product owner walking into a room with a pile of money and a stack of prioritized story cards and then telling the development team to start building a system. These same methodologies often eschew any form of "big upfront" activities and leave us in such a rush to deliver business value that we don't have time to do architecture, user/task research, etc. While a pile of story cards may be the first thing the development team sees, this is rarely the first set of activities in a project. In reality, the customer usually comes with a problem and some vague idea of how to solve it with technology. Someone must help the customer crystallize his vision, design the product, get the necessary funding, and populate the initial product backlog. Gerard Meszaros provides an overview of what needs to go on "behind the scenes" from project conception to the start of development in earnest.
|
Gerard Meszaros, ClearStream Consulting
|
|
|
Are We There Yet? Defining "Done" "Are you done yet?" The answer to this question may sink your career, your team, and your project. If you respond with a "yes," you may be forced to take on additional work you can't handle. If you say "no," you may be branded as someone who can't get things done. Mitch Lacey notes that this innocent question is asked countless times on almost every software project. Establishing an upfront, common understanding of "done" can save teams and businesses countless hours of rework, process-thrash, unclear communication, and hidden work. Mitch describes what a "done list" is, how it adds value, and the value it communicates to stakeholders. Mitch takes you through an exercise on how to establish a common understanding of done and provides an exercise that you can use with your project teams.
|
Mitch Lacey, Mitch Lacey & Associates, Inc.
|
|
|
Agile Acceptance Testing Using .NET FitNesse FitNesse is an open-source test automation tool that enables business users, developers, and testers to cooperate on agile acceptance testing. FitNesse allows them to build a shared understanding of system requirements that ultimately produces the software that is genuinely fit for its purpose. Gojko Adzic presents an introduction to agile acceptance testing. He discusses when to use FitNesse, when not to use it, and how to start writing acceptance tests with this free tool. Gojko explains how to make the most of automated acceptance tests by focusing on business rules, how to overcome workflow constraints, and how to avoid common testing pitfalls. He describes features specific to the .NET FitNesse test runner, including cell handlers and embedded symbols, that allow you to save time and effort in writing and maintaining tests. Join in to see if FitNesse fits into your .NET testing world.
|
Gojko Adzic, Neuri Ltd.
|
|
|
Lessons Learned in Acceptance Test-Driven Development Acceptance Test-Driven Development (ATDD), an application of the test-first practice of XP and agile development, can add enormous value to agile teams that are proficient in these practices. Moving from awareness of ATDD to being proficient at practicing ATDD comes about only after learning some important lessons. First, no one group can "own" the process. Second, ATDD is first about helping the customer and the team understand the problem; then it is about testing. Third, writing automated acceptance tests in ATDD is not the same as writing automated tests with typical automation tools. Antony Marcano shares his experiences with ATDD-the good, the bad, and the ugly-and the many other lessons he's learned in the process. Discover the benefits and pitfalls of ATDD and take advantage of Antony's experiences so that you avoid common mistakes that teams make on their journey to becoming proficient practitioners of ATDD.
|
Antony Marcano, Testing Reflections
|
|
|
Are Agile Testers Different? On an agile team everyone tests, blurring the lines between the roles of professional developers and testers. What's so special about becoming an agile test professional? Do you need different skills than testers on traditional projects? What guides you in your daily activities? Lisa Crispin presents her "Top Ten" list of principles that define an agile tester. She explains that when it comes to agile testers, skills are important but attitude is everything. Learn how agile testers acquire the results-oriented, customer-focused, collaborative, and creative mindset that makes them successful in an agile development environment. Agile testers apply different values and principles-feedback, communication, simplicity, continuous improvement, and responsiveness-to add value in a unique way. If you're a tester looking for your place in the agile world or a manager looking for agile testers, Lisa can help.
|
Lisa Crispin, ePlan Services, Inc.
|
|
|
Driving Development with Tests: ATDD and TDD A perennial wish of testers is to participate early in the projects we test-as early as when the requirements are being developed. We also often wish for developers to do a better job unit testing their programs. Now with agile development practices, both of these wishes can come true. Development teams practicing acceptance test-driven development (ATDD) define system-level tests during requirements elicitation. These tests clarify requirements, uncover hidden assumptions, and confirm that everyone has the same understanding of what "done" means. ATDD tests become executable requirements that provide ongoing feedback about how well the emerging system meets expectations. Agile developers who also are practicing test-driven development (TDD) design methods create automated unit tests before writing component code.
|
Elisabeth Hendrickson, Quality Tree Software, Inc.
|
|
|
Test-Driven Analysis: Focus on the User, Not the Code Test-driven analysis (TDA) focuses on the system at the user interface level. By concentrating on scenarios from the users' point of view, TDA examines the inputs and outputs of a system and how the state of that system changes as a result of actions performed on the system. Further, TDA concentrates on creating tests that help developers and business analysts understand the problem domain and the system requirements. Ken Pugh explores how tests created during TDA efforts relate to user acceptance tests and how the TDA tests can propagate to those created in a test-driven development framework. Together with Ken, you’ll create analysis tests for a sample system and differentiate between various types of tests-acceptance, analysis, and design. This class is about the process of inquiry we need during analysis to answer the question "I know you're ready for testing, but what are you testing for?"
|
Ken Pugh, Net Objectives
|
|
|
The Impact of Poor Estimating and How to Fix It Running Scrum by-the-book for three months, the team was continually failing to meet its delivery commitments. As a result, trust between the business managers and the team degraded almost to a point-of-no-return. Even holding bi-weekly retrospectives, the team could not pinpoint the problems causing their inability to release iterations on time. Mitch Lacey was asked to assist the team in finding the root causes of the problems. He analyzed multiple aspects of the project-from individual work items to planning meetings. Multiple issues were identified, but one thing stood out above all others-the estimation process they used had caused the team to miss its deadlines again and again. Mitch discusses the estimation problems the team was having, how they were fixed, and the resulting improvements in customer satisfaction value delivered.
|
Mitch Lacey, Ascentium
|
|
|
Continuous Integration: The Cornerstone of a Great Shop Jared Richardson believes that of all the development practices being promoted today the best single practice is continuous integration. It's a simple concept-you run a software program that monitors your source code in an automated version control system. When anything changes, your code is automatically checked out, re-built, and all the automated tests are re-run. Continuous integration gives you an early warning if anything in the most recent changes broke the software. Continuous integration forces you to use 100 percent source code management and demands a solid, automated build script. It provides a framework for your automated tests to grow, live, and thrive. Continuous integration becomes a new "team member" who keeps a constant eye on your code and provides the reminders you need to keep the product solid and your team on track.
|
Jared Richardson, 6th Sense Analytics
|
