logo logo

Automation Testing in Agile Teams

Automation Testing in agile teams

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! 🎯

Avatar

About the author

Andrea Gubellini

I love learning new things and share what I find. I’m a passionate nerd with focus on music, development and virtual reality. I work as a Test Automation Engineer and I’m one of those people who’s job happens to also be their passion!

Join TestProject Community

Get full access to the world's first cloud-based, open source friendly testing community. Enjoy TestProject's end-to-end test automation Platform, Forum, Blog and Docs - All for FREE.

Join Us Now  

Comments

5 1 comment

Leave a Reply

popup image

A new world for test automation

Join 150,000 testing & dev teams taking their web & mobile testing to new heights, using #1 FREE test automation platform, designed to help deliver quality at speed.
Get Started
FacebookLinkedInTwitterEmail