Automated testing: choosing a team

by TestFort News Editor on 12/6/2018

How do you determine whether an automated testing team is a good one? If you want to switch to automated testing, is it more reasonable to find an automated testing team or invite an automation expert to work with your manual testers? We describe our experience in both cases, and also talk about our journey to automated testing.

A team is what makes difference between a great test automation and a poor one. No matter how you build a right strategy or set the objectives, it’s them who will do the work.

When choosing automated testers, you have two routes to go.

Route #1 — Educating your manual testers

We always like to work with people we know and trust. People who already know the project and have worked on the code are faster, don’t ask redundant questions, and already believe in the product. There is only one issue: what if they have no experience in automation?

When to go this way?

As far as education usually goes, we all know it requires time and/or. Therefore, before making any decisions, think whether the investment won’t be wasted. As we’ve seen from our own experience, going this way is reasonable if we talk about an in-house team. In this case, you are likely to benefit from their skills a lot more often than just this once.

If it’s a remote team, making this investment is a huge risk. It might be best to find another team of experienced automated testers (we’ll get to this later in the chapter).

Also, Route #1 is a long-run solution. If you need automated testing right here and right now—opt for hiring another team, dedicated specifically to automation. However, as a long-term investment, educating is truly reasonable.

The problem

You have a good team of manual testers. Maybe, these are in-house testers or an outsourcing team you’ve been working with for a long time. They know the project and the product, you have good communication and a well-designed management process. However, they have no automated testing background whatsoever. What to do?

Set a goal

You don’t need all your manual testers to receive automation skills. Choose a few testers of the team and focus on giving them all the necessary knowledge.

How to start?

Before making investments, prepare the team. After all, it’s them who will master a new skill and it’s also their careers we are talking about. Therefore, take into account the following aspects:

Whole team commitment

Make sure you are not the only person interested in the process. You are about to give your testers new skills and knowledge, and they should be as excited about it, as you are. Talk to the team, explain that learning process is a huge investment from both sides, and while you are going to provide all the resources, they have to put up extra hours and work longer days.

Assessing possibilities

Don’t aim to give each of your manual testers the extensive automation background. You can form a team of volunteers who are willing to stay up late writing unit tests and experimenting with frameworks. You don’t need every tester to be on board.

Interest in automation

Don’t confuse this with commitment. Testers can be very committed to the team and its goals but that doesn’t mean a good relationship with automation. Some people just don’t have it in them — and it’s okay. Talk to project manager and testers themselves. Maybe you’ll find out some of them are happy working only manually.

You’ll need a supervisor

The easiest and best-proven way to switch from manual to automated testing is to invite an automation expert and have them oversee the process. Invite an experienced automated tester and discuss the following issues:

Goals and strategy. Most likely, you already have a project where you need automated testing skills. Invite your ‘supervisor’ to take a look at it and define most pressing issues.
Necessary instruments. To switch to automation, you need tools and frameworks. Instead of experimenting with it on your own, better use the advice of an experienced automated tester.
Cost. Switching to automation will take time and resources (you’ll need a bunch of software and hardware to set up the environment as well as frameworks and drivers to automate the tests) so discuss it beforehand.
Management details. Most likely, you can’t freeze all your projects and tasks just so testers can learn. You still have to take care of many pressing issues and waiting is not an option. That’s why we recommend to start the switching process with a few testers, then gradually increasing their number.

Develop the right metrics

How do you know the team is going the right way? How to determine whether all these efforts and investments really improve the process? There is only one way to know for sure and that is building metrics.

Metric #1 — Test count

As we previously discussed, one of the main benefits of automation is that you can write more tests in less time. The simplest way to make sure this is really the case is to count the number of written tests on each level: Regression, GUI, Smoke testing etc.

Metric #2 — Test efficiency

Quantity is important but it doesn’t stand for quality. Control the interaction of every test. By the end of every week, you should get a report with color-tagged test results (green tag if everything went well, red — if a test failed).

Metric #3 — Time and resource management

Evaluating the results is great but don’t forget to compare them to expenses. How much you gained compared to what was spent? Is this number higher? Is there a chance it’ll increase over time? If the answer to these question is yes, you are going the right way.

Case in point: Microsoft Azure Automated Testing Strategy

Article “Software testing at scale to increase velocity” on Microsoft official blog describes the algorithms company used to minimize software testing expenses, including beforehand planning, measuring results and comparing outcomes. To minimize risks, the team maintained the comprehensive comparative report, using the criteria we described above.

Route #2 — Find an automated testing team

Turning manual testers to automated ones is not always reasonable. If you have one project that you’d like to automate, it’s much easier to choose a ‘ready-to-use’ team.

However, if in the previous case you cooperate with testers you already know and trust, here you have the entire getting-to-know-each-other journey ahead. That’s why it’s crucial to put a lot of consideration before opting to an automated testing team.

These are 5 takeaways for picking an automated testing team. All of these insights were proven by our cases and experience, some of them — by mistakes and failures. To avoid those, learn our lessons.

Takeaway #1 — Hire a team with Automation Architect

A dedicated team needs guidance and control. For that, hire a team with 1-2 architects. They will be responsible for managing the process, building the strategy and evaluating the results. Even if you plan on hiring a small team of 5 testers, having an experienced automation architect makes a real difference.

Takeaway #2 — Look for a team with software development expertise

The core difference between manual and automated testing is that automation is almost software development. To design tools and frameworks, you need to follow best development practices, including regular code reviews, pattern design, constant support, and maintenance. Make sure your team knows and uses best development practices and applies them in automation.

Takeaway #3 — Team matters more than tools

Talking about software automation, we discuss the importance of the right instruments. The truth is, no tool is perfect. It glitch and miss bugs, and it might not know an important for your project scenario. Every tool should be adapted specifically to your project and that is something your team will take care of. That’s just another reason of why investing in testers matters more than frameworks and instruments.

Takeaway #4 — Select a tool considering testers’ capacities and your project’s needs

If your team knows Java, they’ll be more comfortable working with a tool that offers Java to write scripts. However, if your project is powered by C++, better pick a team that knows C++.

Takeaway #5 — Product comes first

The priorities in automated testing are: project — team — tools. You start by analyzing your product, choose a team that can solve problems, and pick tools these testers will be comfortable with. We always share our experience of working with tools with our clients, it makes the tool selection easier.

However, it all starts with a product. Only knowing it well, you can set the right goal, find capable testers, and choose tools. If it’s a web page or an app, know what browsers you want it to support. If that’s an application, think about functions and OSs. The more you know about technologies used in development, the easier it gets to build the testing strategy.

If you want your software to be polished to perfection, contact our team of expert QA engineers.

We Work With

Having one outside team deal with every aspect of quality assurance on your software project saves you time and money on creating an in-house QA department. We have dedicated testing engineers with years of experience, and here is what they can help you with.

Software is everywhere around us, and it’s essential for your testing team to be familiar with all the various types and platforms software can come with. In 21+ years, our QA team has tested every type of software there is, and here are some of their specialties.

There are dozens of different types of testing, but it takes a team of experts to know which ones are relevant to your software project and how to include them in the testing strategy the right way. These are just some of the testing types our QA engineers excel in.

The success of a software project depends, among other things, on whether it’s the right fit for the industry it’s in. And that is true not just for the development stage, but also for QA. Different industry have different software requirements, and our team knows all about them.

Full-Cycle Services

By Platform

By Type

Industries