Welcome to the second topic in my series to help you jump-start your test automation. In the first blog post, we talked about my background and how my experience can help you get started. In this post, I’ll offer some advice for managing your team setup.
First of all, you may be on a team of testers that’s separate from the developers. Or, you may all be in a single group that combines both functions. I’ve got some best practices for each scenario.
When testers are on a separate team than developers
To get started, I advise choosing a programming language such as Ruby or Python that has an easy setup and low barrier to entry. In fact, according to the 2019 Stack Overflow survey, Python has recently proven to be one of the most popular languages. But what’s more important than programming language? One word: communication. You have to communicate regularly with the product owner and with the development team in order to test effectively. Here are some specific action items to facilitate this communication:
Get access to the story/task/feature definitions to create tests.
Get business context from the product owner to prioritize testing activities.
Get as much information as possible about the tech stack, system architecture, etc.
Also, be in sync with the dev team. Go step by step as you’re implementing the first automated tests. Work together to agree on a working pace and define a bug report flow.
When testers and developers are on the same team
This can look one of two ways: either the testers and developers have separate, defined roles (QA/Dev), or each team members serves both functions as part of their role. It really helps when one or more team members are responsible to guide the team in testing.
In this scenario, it also helps when application code and test code use the same programming language, as it really leverages team collaboration. Also, when you’re testing, take advantage of the good practices used in the software development lifecycle. Keep test code in the same repository as the app code. This simplifies the flow required to write tests for features that are not yet in production.
The bottom line is that you should look at test automation as a software project… because it is!
No matter which above category your organization’s testing falls into, I have a few pieces of advice that will help.
Invest time looking for a test framework that helps the team move faster. I will cover this in more detail in my next post, but this can be a huge time saver and make everyone more efficient.
Make test design and implementation a team task. This cannot just be one person’s job: testing and quality need to be a part of the overall team culture.
Document how tests are structured. Keep records of configuration as well as how to run, add and remove tests.
Pair program and do code reviews. When you’re adding new tests, it’s really helpful to pair up with a teammate to check each other’s code and think through each other’s approach.
Continuously evaluate if the existing test cases deliver enough value. We always want to be sure that we are testing the right thing and getting the results we need. Constantly evaluate and make sure this is happening!
How the team setup should evolve over time
No matter what your team setup looks like, there’s always room to evolve over time to get better and better. The goal is constant improvement, moving toward more efficient practices to let automated testing do the heavy lifting for you.
Of course, there will always be room for manual testing. However, the focus on it will change: manual testing will be used strategically for debugging and exploratory testing, instead of dominating your testing landscape.
If you enjoyed this post (part 2 in a series), check out the other installments of Diego’s “5 Steps to Jumpstart Test Automation” series: