In many situations, there are a lot of business rules that need to be tested. Say we want to test that the correct discounts get applied based on a certain number of items that are in a shopping cart. To test these rules, most testers will go through the UI and hop through several steps to get to the core of what they need to test. Things like login, searching for an item, adding it to the cart, checking the total, searching for another item, adding it to the cart, checking for the total, searching for yet another item, adding it to the cart, checking the total, removing an item, checking the total and so forth.
These tests are exercising a lot of the code base that has nothing to do with the discount calculation functionality and is wasteful and time consuming. We can instead create the scenarios that we want to test and hook them up directly to the discount logic module (highlighted in yellow above), skipping all the extra steps to get there like login, navigating, searching, and adding.
A great way of doing this is using a technique known as Specification by Example and creating executable specifications.
Also check out the entire Agile Testing series:
- 4 Typical Transitions Teams Go Through When They First Start Adopting Scrum
- The Most Common Misunderstanding of Agile Software Development
- What are the Different Types of Tests?
- What is The Agile Testing Quadrant?
- Which Tests Should We Automate?
- How Many Tests Are Enough?
- What is The Testing Pyramid?
- When Do We Start Testing in Scrum?
- Who Is Responsible for Testing in Scrum?
- What is Test Driven Development (TDD)?
- Why You Shouldn’t Do Functional Testing From the UI?
- What are Executable Specifications or Specifications by Example?
- What is Acceptance Test Driven Development (ATTD)?
- Testing Green Field Applications vs. Legacy Applications
- What is Exploratory Testing?
- Top 8 Things to Consider for Your Agile Testing Strategy
- Agile Testing – Testing from Day 1 Presentation