This is a question we usually face when starting a new project: how to organize the tests?

The reason why you create and maintain functional/acceptance tests is to make sure that the application works (under certain assumptions) as expected by the business. So these test scripts are related to a business value. That’s a good starting point to organize them. Look at the features or business processes of your application and you’ll start to see a layout.

Within Hiptest community we see mainly two ways to organize the tests: by sprint or by feature.

Organization by sprints

If we look at our favourite example, the coffee machine App, here is how the organization by sprint looks like:

The sprints are just about planning. A feature might be started in sprint 2 and delivered in sprint 4. So basically you would have tests split across multiple folders corresponding to the small increments of your product. And not to say that a feature can be refactored so the behaviour may evolve in future sprints.

Organization by features

Now here is another possible organization for the same coffee machine App. We have organized the tests by features:

In this case, the tree structure represents the different features of the App: Serve coffee, Can be configured, Display errors...

Each folder "feature" contains the different acceptance tests related to the multiple use cases for the feature.

Which organization is the best?

Why we prefer the last option

At Hiptest, we are strong believers in Behavior Driven Development. Our tests are mostly automated and they represent a living documentation. And that’s the reason why we prefer by far organizing tests by features instead of sprints. We want to understand quickly the application just by reading the different features and scenarios (test scripts). When a new person joins our project, he can look at the tests organization to quickly understand the behaviour of the application.

The test organization should tell a story about your application. The sprints just give history about features development, not the actual behavior. What’s the value? What does it tell about your product?

What about other information?

They are many other information like type of test (UAT, UX...), automated/manual, priorities... that could be used to organize the project. Here again we prefer grouping the tests by features and use tags to add an extra layer of information. So the folder will contains all the scenarios related to the feature and tags will enable the team to add extra information and filter based on it. Living documentation is King!

In the example below, you can see that we used the tags to note in which sprint each scenario of the features have been planned. As you can see, not all the scenarios are planned for the same sprint, the idea here will be to develop a first increment of the feature during sprint 2 and then finish it during sprint 3.

This is our vision about testing project organization and that works well in our context. But every context is different.

What about yours? What’s your idea and recommendation?