Know what you’re testing before you build it

Have you ever watched someone else assemble boxed furniture? How about that classic trope of the overconfident type who jumps in without reading the instructions? This is the same person who usually says things like, “It’s simple, just start with the things that look like they go together!” If you know the comedy gag, then you know where this is headed. This story ends with that person looking foolish. They start building things using only their “keen intuition” as the guide.  Eventually, they go back to that discarded instruction manual, after uttering something like, “But wait… is that how it’s supposed to be?” 

The big difference between reality and this amusing farce is the instruction manual. It’s more likely for the instructions to be poorly crafted or incomplete, than for them to be completely ignored. But, what’s missing in either case is serious critical thought and concrete plans.

Let’s go back to the amusing farce. What makes this scenario so humiliating isn’t just the mistakes. That part isn’t embarrassing, because it’s actually hard to build things. Mistakes can happen. Wood leaves splinters, hammers hit thumbs — it all comes with the territory. What really makes the scenario miserable (or funny) is knowing that the project will now take longer than any original timeline, and the fragility of “keen intuition” is at fault. Worse, there is now work that needs to be un-done just to get back to the first step. Asking, “Is that how it’s supposed to be?” is usually a sure sign that the timeline for the whole project just got a whole lot longer. 

This anecdote has a lot in common with building software. What’s true about boxed furniture can also be true about software development. It’s tempting to think that intuition can be a sufficient guide for the decision-making process. And, that means it’s also just as easy to end up asking, “Urmm? Is that how it’s supposed to be?”  In either case, a 20-minute project can become a two-hour headache (with or without the tiny allen wrench). What should have been critical thought has now become critical afterthought.

In the case of software development, the best way to avoid that phrase is to always start with a clear definition of the test criteria — before you even start building anything. When you know what you will be testing, then you know what you will be building. This is where Behavior Driven Development (BDD) really shines.   

Regardless of how you approach end-to-end tests (manually or via automation), the first step is always knowing what you will test. When we create a definition of the test criteria, we’re creating an artifact that will serve more than one purpose: 

1. It is a way for the stakeholders to establish clear expectations for the behavior of the software.
2. It is also a way for everyone involved to learn (and document) the full complexity behind a particular feature or scenario.
3. It then becomes a blueprint showing the developers what to build (i.e., a checklist for what the software should be capable of doing).
4. Later, the criteria is used to guide the testing steps (i.e., imitating the end-users to evaluate if the resulting behavior matches the expectations).

Thinking through all of the complexities is always step one. When all of the nuanced details are uncovered, then the team has a clear acceptance criteria for what to build, and the testers have clear criteria for what to test. Most importantly, the stakeholders are put in the position to dictate exactly the behavior that they expect from the feature before any work begins. Those clear expectations save valuable time, expend less energy, and produce better results.