“Business-Facing Tests that Support the Team”
A look at tests in Quadrant-2 – Business-Facing tests
- On an agile project, the customer team and the development team strike up a conversation based on a user story.
- Business-facing tests address business requirements. They express requirements based on examples and use a language and format that both the customer and development teams can understand. Examples form the basis of learning the desired behavior of each feature and we use those examples as the basis of our story tests in Quadrant-2
- Business-facing tests are also called “customer-facing”,”story”,”customer” and “acceptance” tests. The term ‘acceptance tests’ should not be confused with ‘user acceptance tests’ from Quadrant-3.
- The business-facing tests in Q-2 are written for each story before coding started, because they help the team understand what code to write.
- Quadrant-1 activities ensure internal quality, maximize team productivity, and minimize technical debt.
- Quadrant-2 tests define and verify external quality and help us know when we are done.
The customer tests to drive coding are generally written in executable format, and automated, so that team members can run the tests as often as they like to see if functionality works as desired.
- Tests need to include more than the customer’s stated requirements. We need to test for post-conditions, impact on the system as a whole, and integration with other systems. We identify risks and mitigate those with our tests. All of these factors then guide our coding.
- The tests need to be written in a way that is comprehensible to a business user yet still executable by the technical team.
- Getting requirements right is an area where team members in many different roles can jump in to help.
- We often forget about non-functional requirements. Testing for them may be a part of Quadrants 3 and 4, but we still need to write tests to make sure they get done.
There are conditions of satisfaction for the whole team as well as for each feature or story. They generally come out of conversations with the customer about high-level acceptance criteria for each story. They also help identify risky assumptions and increases team’s confidence in writing & correctly estimating tasks needed to complete the story.
- A smart incremental approach to writing customer tests that guide development is to start with a “thing-slice” that follows a happy path from one end to the other. (also called a “steel-thread” or “tracer-bullet”). This ‘steel-thread’ connects all of the components together and after it’s solid, more functionality can be added.
- After the thin slice is working, we can write customer tests for the next chunk.
- It’s a process of “write tests — write code— run tests — learn”
- Another goal of customer tests is to identify high-risk areas and make sure code is written to solidify those.
- Experiment & find ways your team can balance using up-front detail and keeping focused on the big picture.
Quadrant-2 contains a lot of different types of tests and activities. We need the right tools to facilitate gathering, discussing, and communicating examples and tests.
>>Simple tools such as Paper or Whiteboard work well for gathering examples if the team is co-located.
>>More sophisticated tools help teams write business-facing tests that guide development in an executable, automatable format.
testwithnishi 
[…] Book Review: Read Along- ‘Agile Testing’ Chapter-8 – Nishi Grover Garg – https://testwithnishi.com/2020/07/06/read-along-agile-testing-chapter-8/ […]
LikeLike
[…] Chapter-8 Business Facing Tests that support the team […]
LikeLike