Here again we prefer grouping the tests by features and use tags to add an extra layer of information. that could be used to organize the project. They are many other information like type of test (UAT, UX.), automated/manual, priorities. What’s the value? What does it tell about your product?
The sprints just give history about features development, not the actual behavior. The test organization should tell a story about your application. 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.
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. In this case, the tree structure represents the different features of the App: Serve coffee, Can be configured, Display errors.Įach folder "feature" contains the different acceptance tests related to the multiple use cases for the feature.Īt Hiptest, we are strong believers in Behavior Driven Development. Now here is another possible organization for the same coffee machine App. 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. A feature might be started in sprint 2 and delivered in sprint 4. If we look at our favourite example, the coffee machine App, here is how the organization by sprint looks like: Within Hiptest community we see mainly two ways to organize the tests: by sprint or by feature. Look at the features or business processes of your application and you’ll start to see a layout. That’s a good starting point to organize them. So these test scripts are related to a business value. 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.
This is a question we usually face when starting a new project: how to organize the tests?
0 kommentar(er)
