|
Overview
A 2-day course for testers and developers. The first day focuses on what testers can do to provide up-front, "test-first" acceptance tests, which also serve as readable, executable specifications. The second day the team will implement and execute the tests using a pre-selected test framework’s primary format. Prior to the course, assistance will be given to help choose the particular collaborative tool appropriate for the team and their domain:
Tabular tools: Suitable for domains that are data-driven or equation-heavy, such as many financial or scientific applications. Tools available include Ward Cunningham’s Fit, ObjectMentor’s FitNesse, and Rick Mugridge’s FitLibrary.
Given/When/Then tools: Suitable for domains that are rule-based or workflow-oriented, such as most customer-facing web applications. Tools available include RSpec, Cucumber and Robot Framework.
The two are not mutually exclusive, technically or conceptually.
Details
This course emphasizes Acceptance Testing, the practice of creating tests for the acceptance and “done-ness” of a story. We will look at refining and estimating stories based on answering the questions “How would I test that?” and “How will I know we’re done?” Developers and testers will learn about Acceptance-Test Driven Development, the practice of writing these tests before the code is developed, and how testers provide the final touches on business analysis and requirements specification on an agile team. Attendees will work together to write acceptance tests, and to use the chosen tool to connect the tests to the system under test. Developers will learn how to build small, simple test-to-production translators (in either Java or C#) which connect the tests to the system under test.
Developers will not be developing code beyond these translators, and labs will be completed when tests “fail successfully.” The labs do require at least one computer with an IDE, and the testing framework installed. Assistance is available to help you choose the particular collaborative tool appropriate for your team.
.
Level
Basic to intermediate
Prerequisites
Familiarity with basic Agile roles and activities.
Audience
Primarily testers and developers who will be working on an agile team. Business analysts, XP “customers” and Scrum “Product Owners” would also benefit from attending.
Learning Objectives
1.The role of testers in refining and estimating stories
2. Writing acceptance tests for stories without having to wait for the functionality to exist
3. Testing stories rather than interfaces and interactions
4. Writing tests collaboratively in a team setting
5. How to use acceptance tests to discuss stories and settle arguments
6. The roles of automation on an agile team
7.. Using the simple abilities of Fit (Framework for Integrated Tests)
8. How to improve acceptance tests
9. Developers: How to write fixtures.
Course duration
2 days
Course outline
DAY 1
Introduction
We reveal why traditional software development and testing is so painful, and review the very basics of Agile in order to introduce the “Agilists’ Dilemma”. We will also take a cursory look at how the tester’s role changes on an agile team. The first exercise, selecting a fictional project and writing up a few stories, sets the stage for all further exercises.
Painful Software Debts
We will describe how even an Agile project can generate and accumulate hidden (but very real) debt through manual testing, defect-tracking, and poorly crafted software.
Test-First as Just-In-Time Analysis
We explain “test-first” and how this allows for improved feedback for developers, testers, and stakeholders. It also alters the tester’s roles, responsibilities, and view of the software. We explore how to consider testing in detail before the software exists, and emphasize “acceptance” in the term “acceptance testing.” The next exercise gives us the opportunity to reexamine and split our stories in terms of two questions to be asked and answered by testers: “Can we get it tested during the iteration?” and “How will I test this story?”
Acceptance Test Driven Development
We describe Test-Driven Development, and compare and contrast the two types of TDD. We will briefly explore the types of automation, and their pros and cons. Fit is introduced as an example which provides incomparable simplicity and flexibility, allowing us to expand our concepts of good testing.
Your Testing Tool
We will discuss the chosen tool, the test formats available, the editors available for test-writing, and the underlying technology (at a very conceptual level).
For example, if you select FitLibrary, we start with the three basic forms of Fit tests, and then explore the enhancements made by Rick Mugridge, and his intent behind these enhancements. We examine a demo project with functioning code and tests. This is often the “aha!” moment (seeing is believing).
You will write your own tests on posters, and the team will evaluate the posters and consider options for enhancement.
DAY 2
Implementing Tests
Parallel exercises will give testers a chance to incorporate feedback into their tests, while developers work to set up at least one computer system with the tool installation and programming environment.
Organizing Tests
A brief discussion of how to organize your tests will quickly lead us into the next exercise: Writing at least one of our tests on the demo platform, and seeing what it does.
Translators
We show how to develop a Fit “Fixture” or Cucumber “Scenario” (for example), a small bit of code that connects the test to the system under test. Although this section is technical, it’s important for testers and developers to understand the give-and-take that is necessary to get the written test to “line up” with the translator. These bits of code are very easy to write, expand, and reuse, but the process may require some modifications to the test, itself. The exercise will pair up at least one developer and tester (potentially in a “fishbowl” environment, with the whole class observing), and the developer will use an IDE to build the translator. The classroom team’s goal is to see at least one test “fail successfully.”
How ATDD Works on an Agile Team
We talk about what would come next, if this had been an actual project. We review how an agile team uses ATDD during an iteration, and where and how collaboration takes place. We discuss the dynamic and incremental nature of test maintenance and reusable translator development. We will also discuss ways to adopt ATDD and the tool of choice, and to pay down technical debts in a measured, realistic fashion.
|
