- •Contents
- •Preface
- •Acknowledgments
- •About the author
- •About the cover illustration
- •Higher product quality
- •Less rework
- •Better work alignment
- •Remember
- •Deriving scope from goals
- •Specifying collaboratively
- •Illustrating using examples
- •Validating frequently
- •Evolving a documentation system
- •A practical example
- •Business goal
- •An example of a good business goal
- •Scope
- •User stories for a basic loyalty system
- •Key Examples
- •Key examples: Free delivery
- •Free delivery
- •Examples
- •Living documentation
- •Remember
- •Tests can be good documentation
- •Remember
- •How to begin changing the process
- •Focus on improving quality
- •Start with functional test automation
- •When: Testers own test automation
- •Use test-driven development as a stepping stone
- •When: Developers have a good understanding of TDD
- •How to begin changing the team culture
- •Avoid “agile” terminology
- •When: Working in an environment that’s resistant to change
- •Ensure you have management support
- •Don’t make test automation the end goal
- •Don’t focus on a tool
- •Keep one person on legacy scripts during migration
- •When: Introducing functional automation to legacy systems
- •Track who is running—and not running—automated checks
- •When: Developers are reluctant to participate
- •Global talent management team at ultimate software
- •Sky Network services
- •Dealing with sign-off and traceability
- •Get sign-off on exported living documentation
- •When: Signing off iteration by iteration
- •When: Signing off longer milestones
- •Get sign-off on “slimmed down use cases”
- •When: Regulatory sign-off requires details
- •Introduce use case realizations
- •When: All details are required for sign-off
- •Warning signs
- •Watch out for tests that change frequently
- •Watch out for boomerangs
- •Watch out for organizational misalignment
- •Watch out for just-in-case code
- •Watch out for shotgun surgery
- •Remember
- •Building the right scope
- •Understand the “why” and “who”
- •Understand where the value is coming from
- •Understand what outputs the business users expect
- •Have developers provide the “I want” part of user stories
- •When: Business users trust the development team
- •Collaborating on scope without high-level control
- •Ask how something would be useful
- •Ask for an alternative solution
- •Make sure teams deliver complete features
- •When: Large multisite projects
- •Further information
- •Remember
- •Why do we need to collaborate on specifications?
- •The most popular collaborative models
- •Try big, all-team workshops
- •Try smaller workshops (“Three Amigos”)
- •Pair-writing
- •When: Mature products
- •Have developers frequently review tests before an iteration
- •When: Analysts writing tests
- •Try informal conversations
- •When: Business stakeholders are readily available
- •Preparing for collaboration
- •Hold introductory meetings
- •When: Project has many stakeholders
- •Involve stakeholders
- •Undertake detailed preparation and review up front
- •When: Remote Stakeholders
- •Prepare only initial examples
- •Don’t hinder discussion by overpreparing
- •Choosing a collaboration model
- •Remember
- •Illustrating using examples: an example
- •Examples should be precise
- •Don’t have yes/no answers in your examples
- •Avoid using abstract classes of equivalence
- •Ask for an alternative way to check the functionality
- •When: Complex/legacy infrastructures
- •Examples should be realistic
- •Avoid making up your own data
- •When: Data-driven projects
- •Get basic examples directly from customers
- •When: Working with enterprise customers
- •Examples should be easy to understand
- •Avoid the temptation to explore every combinatorial possibility
- •Look for implied concepts
- •Illustrating nonfunctional requirements
- •Get precise performance requirements
- •When: Performance is a key feature
- •Try the QUPER model
- •When: Sliding scale requirements
- •Use a checklist for discussions
- •When: Cross-cutting concerns
- •Build a reference example
- •When: Requirements are impossible to quantify
- •Remember
- •Free delivery
- •Examples should be precise and testable
- •When: Working on a legacy system
- •Don’t get trapped in user interface details
- •When: Web projects
- •Use a descriptive title and explain the goal using a short paragraph
- •Show and keep quiet
- •Don’t overspecify examples
- •Start with basic examples; then expand through exploring
- •When: Describing rules with many parameter combinations
- •In order to: Make the test easier to understand
- •When: Dealing with complex dependencies/referential integrity
- •Apply defaults in the automation layer
- •Don’t always rely on defaults
- •When: Working with objects with many attributes
- •Remember
- •Is automation required at all?
- •Starting with automation
- •When: Working on a legacy system
- •Plan for automation upfront
- •Don’t postpone or delegate automation
- •Avoid automating existing manual test scripts
- •Gain trust with user interface tests
- •Don’t treat automation code as second-grade code
- •Describe validation processes in the automation layer
- •Don’t replicate business logic in the test automation layer
- •Automate along system boundaries
- •When: Complex integrations
- •Don’t check business logic through the user interface
- •Automate below the skin of the application
- •Automating user interfaces
- •Specify user interface functionality at a higher level of abstraction
- •When: User interface contains complex logic
- •Avoid recorded UI tests
- •Set up context in a database
- •Test data management
- •Avoid using prepopulated data
- •When: Specifying logic that’s not data driven
- •Try using prepopulated reference data
- •When: Data-driven systems
- •Pull prototypes from the database
- •When: Legacy data-driven systems
- •Remember
- •Reducing unreliability
- •When: Working on a system with bad automated test support
- •Identify unstable tests using CI test history
- •Set up a dedicated continuous validation environment
- •Employ fully automated deployment
- •Create simpler test doubles for external systems
- •When: Working with external reference data sources
- •Selectively isolate external systems
- •When: External systems participate in work
- •Try multistage validation
- •When: Large/multisite groups
- •Execute tests in transactions
- •Run quick checks for reference data
- •When: Data-driven systems
- •Wait for events, not for elapsed time
- •Make asynchronous processing optional
- •Getting feedback faster
- •Introduce business time
- •When: Working with temporal constraints
- •Break long test packs into smaller modules
- •Avoid using in-memory databases for testing
- •When: Data-driven systems
- •Separate quick and slow tests
- •When: A small number of tests take most of the time to execute
- •Keep overnight packs stable
- •When: Slow tests run only overnight
- •Create a current iteration pack
- •Parallelize test runs
- •When: You can get more than one test Environment
- •Try disabling less risky tests
- •When: Test feedback is very slow
- •Managing failing tests
- •Create a known regression failures pack
- •Automatically check which tests are turned off
- •When: Failing tests are disabled, not moved to a separate pack
- •Remember
- •Living documentation should be easy to understand
- •Look for higher-level concepts
- •Avoid using technical automation concepts in tests
- •When: Stakeholders aren’t technical
- •Living documentation should be consistent
- •When: Web projects
- •Document your building blocks
- •Living documentation should be organized for easy access
- •Organize current work by stories
- •Reorganize stories by functional areas
- •Organize along UI navigation routes
- •When: Documenting user interfaces
- •Organize along business processes
- •When: End-to-end use case traceability required
- •Listen to your living documentation
- •Remember
- •Starting to change the process
- •Optimizing the process
- •The current process
- •The result
- •Key lessons
- •Changing the process
- •The current process
- •Key lessons
- •Changing the process
- •Optimizing the process
- •Living documentation as competitive advantage
- •Key lessons
- •Changing the process
- •Improving collaboration
- •The result
- •Key lessons
- •Changing the process
- •Living documentation
- •Current process
- •Key lessons
- •Changing the process
- •Current process
- •Key lessons
- •Collaboration requires preparation
- •There are many different ways to collaborate
- •Looking at the end goal as business process documentation is a useful model
- •Long-term value comes from living documentation
- •Index
Chapter 2 Key process patterns |
25 |
Scope
By applying the practices that I’ll describe in chapter 5, we derive the implementation scope from the business goals. The implementation team and the business sponsors come up with ideas that can be broken down into deliverable software chunks.
Let’s say we identify a theme for a customer loyalty program that can be broken down into basic loyalty system features and more advanced bonus schemes. We decide to focus on building a basic loyalty system irst: customers will register for a VIP program, and VIP customers will be eligible for free delivery on certain items. We’ll postpone any discussion on advanced bonus schemes for later. Here’s the scope for this example:
User stories for a basic loyalty system
•In order to be able to do direct marketing of products to existing customers, as a marketing manager I want customers to register personal details by joining a VIP program.
•In order to entice existing customers to register for the VIP program, as a marketing manager I want the system to offer free delivery on certain items to VIP customers.
•In order to save money, as an existing customer I want to receive information on available special offers.
Key examples
By applying the practices described in chapters 6 and 7, we produce detailed speciications for the appropriate scope once our team starts implementing a particular function. For example, when we start working on the second item of the scope—free delivery— free delivery must be deined. During collaboration, we decide that the system will offer free delivery on books only, to avoid logistical problems related to shipping electronics and large items. Because the business goal is to promote repeat sales, we try to get customers to buy several items; “free delivery” becomes “free delivery for ive or more books.” We identify key examples, such as a VIP customer buying ive books, a VIP customer buying fewer than ive books, or a non-VIP customer buying books.
This leads to a discussion about what to do with customers who purchase both books and electronics. Some suggestions relate to expanding the scope: for example, splitting the order in two and offering free delivery for the books only. We decide to postpone this option and implement the simplest thing irst. We won’t offer free delivery if there is anything other than books in the order. We add another key example to the current set, to be revisited later:
26 Speciication by Example
Key Examples: Free delivery
•VIP customer with ive books in the cart gets free delivery.
•VIP customer with four books in the cart doesn’t get free delivery.
•Regular customer with ive books in the cart doesn’t get free delivery.
•VIP customer with a ive washing machines in the cart doesn’t get free delivery.
•VIP customer with ive books and a washing machine in the cart doesn’t get free delivery.
Speciication with examples
By applying the practices from chapter 8, we reine the speciication from the key examples and create a document that’s self-explanatory and formatted in a way that will make it easy to automate the validation later (as shown below):
Free delivery
•Free delivery is offered to VIP customers once they purchase a certain number of books. Free delivery is not offered to regular customers or VIP customers buying anything other than books.
•Given that the minimum number of books to get free delivery is ive, then we expect the following:
Examples
Customer type |
Cart contents |
Delivery |
|
VIP |
5 |
books |
Free, Standard |
|
|
|
|
VIP |
4 |
books |
Standard |
|
|
|
|
Regular |
10 |
books |
Standard |
|
|
|
|
VIP |
5 washing machines |
Standard |
|
|
|
|
|
VIP |
5 books, 1 washing machine |
Standard |
|
|
|
|
|
This speciication—a self-explanatory document—can be used as a target for implementation and as a driver for an automated test so we can objectively measure when the implementation is done. It’s stored in a repository of speciications, to become part of the living documentation. An example would be a FitNesse wiki system or a directory structure of Cucumber feature iles.
Chapter 2 Key process patterns |
27 |
Executable speciication
When our developers start working on the feature described in the speciication, the test based on this speciication will initially fail because it’s not yet automated and the feature isn’t yet implemented.
The developers will implement the relevant feature and connect it to the automation framework. They’ll use an automation framework which pulls the inputs from the speciication and validates the expected outputs without requiring them to actually change the speciication document. The ideas and practices in chapter 9 will help automate the speciication eficiently. Once the validation is automated, the speciication becomes executable.
Living documentation
All the speciications for all implemented features will be validated frequently, most likely by an automated build process. This helps to prevent functional regression issues while ensuring that speciications stay current. The team will use the practices from chapter 10 so that frequent validation goes smoothly.
When the entire user story is implemented, someone will irst validate that it’s done and then restructure the speciications so that they it in with the speciications for features that were already implemented. They’ll use the practices from chapter 11 to evolve a documentation system from the speciications in increments. For example, they might move the speciication for free delivery into the hierarchy of features related to delivery, potentially merging them with other free-delivery examples triggered by different factors. In order to make the documentation easier to access, they might set up links between the speciication for free delivery and the speciications for other delivery types.
Then the cycle starts again. Once we need to revisit the rules for free delivery—for example, when working on the advanced bonus schemes or in order to extend the functionality to split orders with books from orders with other items—we’ll be able to use the living documentation to understand the existing functionality and specify changes. We can use the existing examples to make specifying collaboratively and illustrating using examples more effective. We’ll then produce another set of key examples, which will lead to an increment of the speciication for free delivery that will ultimately be merged with the rest of the speciications. And the cycle will repeat.
Now that we have had a quick overview of key process patterns, we’ll take a closer look at living documentation in chapter 3. In chapter 4, I present ideas on how to start adopting Speciication by Example, followed by ideas on implementing individual process patterns in part 2.