Why we convinced our product owner to write acceptance tests

Introduction

Many of us probably once met a guy who calls himself a product owner. You know, the guy who tells you what to do for the next two or three weeks. If you haven't here's how agile software projects usually work (at least in my experience).

There are many "Frameworks" out there that tell you how agile really works. I'm not gonna mention any of them and i won't go into details how they work or why they are special.

Usually there's a team of developers and some manager type guys that tells the team what needs to be done. One of them is the product owner. He gathers all the required features and divides them into user stories. Here's a simple example of what a user story might look like.

The user should be able to add a todo in our todo-app.

Of course there's more to a user story than that. Usually there's a description, some design mockups etc. Also there are acceptance criteria.

If the user clicks on the plus button a new todo is added

These are usually written by the product owner and help him decide if a story is really completed or not. This is a manual test done by the testers and/or the product owner after the dev team is finished developing the feature.

Wouldn't it be nice...

...if this wasn't a manual process that only happened after the dev team implemented the feature?

Of course the dev team knows about all the acceptance criteria and is able to verify them by just reading the user story. But who likes manual processes, right?

I'm a big fan of test-driven development writing my unit tests before i write the business logic as it gives me just the needed sanity check every now and then, to verify i'm not delivering total crap at the end of the day. So why shouldn't we use the same mindset to verify this on the feature level as well?

We quickly came to the conclusion that these would have to be some kind of end to end tests which we already had written using Selenium.
So how could we transform written acceptance criteria to selenium tests?

We figured we shouldn't.

Wouldn't it be nice to have our product owner or testers write these tests for us?

Meet FitNesse

FitNesse is a tool for specifying and verifying application acceptance criteria (requirements). It acts as a bridge between the different stakeholders (disciplines) in a software delivery process. Its wiki server makes it easy to document the software. Its test-execution capabilities allow you to verify the documentation against the software, ensuring the documentation remains up to date and the software is not facing regression. (Source: http://fitnesse.org/)

In short business representatives write wiki style pages describing requirements, and FitNesse calls fixture code written in Java to assert if the code meets the requirements.

The corresponding Java code for this table looks something like this:

package eg;

import fit.ColumnFixture;

public class Division extends ColumnFixture {
    public double numerator;
    public double denominator;

    public Division() {
    }

    public double quotient() {
        return this.numerator / this.denominator;
    }

    public void setNumerator(double numerator) {
        this.numerator = numerator;
    }

    public void setDenominator(double denominator) {
        this.denominator = denominator;
    }
}

FitNesse delivers an easy and understandable syntax for non-programmers and programmers alike. Tests can either be started via command line (e.g. as part of a CI Pipeline) or manually on the hosted FitNesse wiki. The built in web editor makes it really easy for non technical staff to add tests for new features. It can even convert excel sheets to FitNesse tables. Not kidding.

Of course this is a very simple example but as you can see, FitNesse doesn't care what your fixture does. You are totally free to use all flavors of framework or test framework that fits your use-case the best.

Conclusion

Since we are building a large Angular app, we decided to write our fixtures using Selenium and run our tests against a hosted version of our app. We also integrated our acceptance tests in our CI Pipeline which is executed every time something changes in our application.

Having an automated way of proving your software meets all requirements posed by the product owner while you are developing it really assures you that you are on the right path. It also helps our product owner to better describe the actual requirements because he has to do it in a way that can be executed by an automated test. Lastly these FitNesse tests not only help you while developing software, they also serve as regression tests long after a feature is released to assert that older features still work as they were designed.

All in all FitNesse really helped us automate most of the manual testing with our testers and product owner now writing the tests themselves. It also improved our overall velocity as a team.

If you are interested in this topic and how to set this up using maven just tell me in the comment section. I would be happy to write a complete tutorial as my next article here.

Thank you for reading my first article on dev.to, please excuse the bad english i'm not a native speaker.