Every once in a while I hear about people splitting teams when it comes to quality assurance and automated tests, thinking the second practice should be done outside of the scrum team “as a service”. But why is that? The most common pattern is the belief that automated tests are some kind of “no man’s land” where no additional value to the business happens.
I admit it’s a bit difficult to find a spot for automation tests development if you don’t know how to approach it. But the idea that there is no additional business value to it needs to change. So, dear reader, what are the downsides of automation tests being crafted outside of the scrum team?
Product knowledge
QA engineers / test developers are not aware of all the information needed to test the feature properly. Remember that automation tests may differ from exploratory tests or manual tests in how they’re executed, but the first thing that needs to be there is the knowledge about the product and the feature developed 🔍
Testers need to be aware of the product they are testing to understand and think about efficient test scenarios needed to cover a feature.
When automated tests are delivered as a service, it is inevitable that there will be less knowledge. For example, imagine making pizza for a pizzeria without knowing the menu 🍕 You know that there will definitely be a “Margherita” – a good old classic, but you don’t know the other pizzas on the menu. The only way to know them is to ask, which is where the next point kicks in.
Information waterfall
It is vital that requirements and information are as clear and accessible as possible. Splitting QA in a specific team doesn’t help. By doing so you are blocking direct contact between the business stakeholder, the developers, and QA engineers, making it difficult to gather them together and discuss doubts about the requirements, identify issues, or understand the features clearly.
On an additional note don’t forget that sometimes bugs are hidden in requirements so it is important to have a clear understanding and brainstorming of any new feature requirement.
Given what we said earlier, how can we improve our team composition and delivery of high quality code without sacrificing story points? 🤔
Estimations should include testing time
During estimations, it is best to directly include testing development time. Business stakeholders and developers, along with QA engineers, should take their time to understand what should be tested and how the total estimation including automated tests development should be. This allows the team to have a clear understanding of many things in advance:
❓ What needs to be tested
❓ How the feature will be tested
❓ How much testing impacts the delivery schedule
Test first
Write your acceptance tests right after or along with your requirements. This helps teams to have a clear understanding of what needs to be done to achieve the feature, and QA engineers with their development. Having acceptance tests in advance can also expand the requirements in covering the edge cases, so be sure to have them!
Automated tests for all, made by all
Automated tests, along with the quality of the product, are a matter of every member of the company. Delivering a high quality product is something everyone should aim to, not a matter their role.
Frontend, backend, and full-stack developers should be able to write acceptance tests, understand them and use them to write automated tests along with QA engineers. This doesn’t only help test maintenance, but also improves the communication between the development team and could possibly be used to work with test driven development where applicable.
Write automated tests for everyone
Automated tests are code, and that’s fine, but that doesn’t mean they need to be unreadable. There are plenty of ways to write business-readable automated tests that everyone in the team can understand. Let’s take Gherkin as an example: with Cucumber, SpecFlow, or any other framework you can write tests like this:
Given I land on login page And I am a registered user When I login to the application Then I successfully see control panel
The above test could be used as a business-readable extension of the requirements in addition to its job to automate the scenario and grant the quality of the login feature.
Conclusion
It is clear that splitting QA outside of the scrum development team doesn’t help in improving quality standards or communication in any way. Be sure to stick together, find a suitable process for your company or development schedules, and communicate as a team to grant a high quality product! 🎯
usefully