Is QA for you?
Test automation, no matter the stack, means a mixture of two worlds — the world of testing and the world of development. Most automation testers end up in a grey zone, which can be fun, but can also be lonely at times because, statistically, you are more likely to end up working alone on a project than to be on a team.
Let’s discuss the fun part — when you can exercise your imagination, creating complex tests and also exercise your brain with programming algorithms and other software development goodies.
Test automation is right for you if one of the following points apply:
- You want to do it
- You have technical skills and want to do it
If the first or second one applies, you are 98% there. The rest of the 2% consists of “native” technical skills, which will elevate you from being a great QA automation engineer to an awesome QA automation engineer.
What do people expect from you?
Some time ago, expectations for automation engineers were completely wrong, but now they are a work in progress.
Oftentimes you will hear that “we want every test to be automated. Test automation will help us a lot and save us money and time and we will be more confident in our software.”
Let’s digest the “completely wrong” part: Some time ago people believed that automation will completely vanquish manual testing from the software development process. This expectation made the life of the automation engineers really painful and hard because of two factors: Manual testers were not interested in supporting the automation effort and, of course, the automation engineers never ever managed to get rid of manual testers, because they are part of the same team. Now, if you are lucky, the automation engineer can set proper expectations after a good analysis of the existing product or a future product is performed.
What you really have to do
Let’s think about two main scenarios in which you are the one and only automation engineer.
Scenario 1: New project with nothing but a team in formation and a good idea
Scenario 2: Project was started some time ago, with no or little automation performed. Nobody gave much thought about the QA.
If you land in the first scenario, consider yourself pretty lucky. But there are still some things you need to take into consideration.
The first thing you need to do is get to know the team. Blow the dust off your social skills because you will have to talk to each and every person from the team at any given time in the software development cycle. Don’t forget, test automation will be successful if every member of the team is aware of it and also helps you out in areas where they excel. For instance, manual testers write automation-friendly test cases, BE engineers might help you up with a DB script, FE engineers might help you with automation-friendly UI components, BA might help you by giving a heads up when a feature is about to change, and UI/UX will not propose outstanding UI changes.
The second thing to do is the analysis of the technology stack. Use your expertise, as well as the expertise of the other colleagues from the community and come up with a framework/tool proposal that will be used for test automation. Listen to everybody and try to be as objective as you can be. Even If you have more experience in one programming language/framework, that doesn’t mean that it is the best framework to choose. Don’t worry, if you were able to learn one, you will learn the second one, as well.
The third and final part is to start creating tests and be awesome. 🙂
This scenario is more like being a firefighter at a house where nobody wants to be saved.
Get to know the team, of course, but it will be more difficult because automation didn’t work in the past. Remember the expectations from some time ago? Now you have to lower those expectations. You need to convince the team that test automation will help everybody, but it does not perform miracles. Talk with the developers, the manual testers, the managers and set the expectations correctly. They really depend on the context of the project, but there are two areas which should be part of each and every successful test automation story:
- Test automation will bring more quality to our product
- Test automation translates into more time for manual testers to focus on exploratory testing, as they no longer have to bother with repetitive tasks, like regression testing.
Perform an analysis on the software product and also analyze the tests that the team has. Based on the analysis you have performed, come up with a proposal. Ask what went wrong with the last automation effort, if it existed, and keep that in mind when picking the framework candidate and strategy.
Start creating tests and be awesome!
As you can see, test automation is a lot of things. Don’t forget that you are actually building your own software product, which means you are the product owner, developer and tester. If you don’t see it that way, failure might be just around the corner.
How to keep you and others sane
Think ahead, plan your moves, balance your work and be transparent.
Here is a simple strategy that’s proven to be pretty efficient, but everyone on the team was aware of it.
The automation teamwork is divided into three main parts:
- Maintain the existing tests
- Test coverage
- Add framework capabilities
In order to have positive results, the automation team should maintain a good balance between the three categories. In this case, the prioritization is done based on the future and current needs.
Let’s dive in a little further. In order to get value from the automation tests, we need to look beyond the percentage of automated tests. That value brings false positives because it does not tell us what tests are broken. It just tells us what percentage of tests were automated from the regression tests pool.
Let’s get back to the three categories and put them in a Program Increment (PI):
1. Each sprint from the PI will contain a mandatory maintenance task. This task is usually tackled at the beginning of the sprint. It’s not a pleasant job, but it’s a must, because it requires a health check for the whole automation suite. If defects are found in the framework, or the application changed, the maintenance task is used to tackle everything that involves broken tests that are already added to the regression suite.
2. Test coverage is very simple to understand. We have a task that says add test coverage for feature X. If maintenance is done and the rest of the tests work fine, we are good to add more tests. If the rest of the tests are not in good health, adding more test coverage is usually not a good idea. Please remember that each line of written code needs future maintenance and if we already have problems maintaining the existing code, it will be very hard to maintain more code than we already have.
3. Adding framework capabilities might be the fun part for each automation team member. This task might not be part of each PI, because we add framework capabilities based on the needs we have. Framework caps task will be added if the current framework capabilities limits us in creating automation tests for a feature that is not yet automated and it is prioritized to be done/changed in the application.
How to add value and how to maintain value
You start adding value by changing the mindset regarding test automation. You continue by being able to stick to your plan and meet the expectations you have set. You maintain the value by being transparent.
Carefully plan when to stop
Things come to an end and you should be able to predict it. Long story short, after some time, you might find yourself maintaining tests that you developed maybe two years ago. And the next day you maintain tests written one year ago and altogether you just do maintenance.
Keep an eye on these situations and analyze your maintenance work. Raise it up as a red flag when it’s piling up and hits around 50% of your work time so the team has enough time to come up with a solution.
If the app is still under extensive development, adding new automation engineers should solve the issue, but if the workload starts being lighter on the development side, adding more team members might not be the best solution because there will be no return on investment.
Starting with test automation requires a good and solid mindset. Before you even start coding the first few tests, you need to have the whole team on your side. Be transparent, explain and make them understand the real value that a good test automation framework will provide.
If you manage to do that, success is yours, because the automation effort will become a common goal for the whole team.