Not long ago, many experienced developers faced a world in which there was no integration among the phases of software development. In other words, the guy who’s coding is not the guy who’ll test it.

Things have changed, luckily, and so has the reality of the Quality Analyst (QA), the main player of the quality assurance game. Even though spreadsheets and old-fashion/too-long processes still exist and, in very specific situations are still necessary, the QA is now, for many companies, a developer, too. Or, they are at least, an automation creator. Most of the big tech companies have this and other roles, all related to the area of quality.

It’s important to note that those same companies have these entire squads of quality analysts, not only to ensure quality itself, but also speed. Developers (or any IT people) say that this combination is not an easy achievement. See the huge list of agile and RUP methodologies and many other frameworks that had tried hard to do it.

I didn’t even mention tools. There are so many of them, with code and without, for basically every programming language, framework and platform.

With all that in mind, you may ask: why doesn’t every company automate their tests? This is due to a mix of factors, many of them subject to region, company history, old processes and close-minded people in charge, etc. That’s not the focus of this article. Instead, I’ll focus on how to start automating if you’re not doing it or are not doing it enough.

Start by asking a question to yourself and your team: do you have any repetitive task or activity in your daily developer life that could be switched to an automatic routine?

If the answer is yes, then you still have work to do.

The tools are important

As developers, it’s common, especially for those who are polyglots, to say things like “Uh, the language is not important, give me the problem, pick the language and I’ll do it”. Of course, you can get the same result through different paths. The point is to choose the path that is best for you, the project, and your teammates.

Choosing one tool instead of another can make a huge difference. The same is valid for software testing. There are many variables to consider like

• The type of technology you’re working with (programming language, IDE, database, etc.);
• The target audience of that solution;
• Does your solution need to be accessible to people with special needs?
• Is it a system that runs only in the back-end?
• Is it an API? With or without authentication? Two-factor authentication?

It’s easy to underestimate those factors and, believe it or not, they are some of the main reasons why some important things are not automated in companies. For example, when you choose a framework that’ll automate your tests based on the synchronous nature of your system, your hands would be tied when the first asynchronous feature comes up after an urgent meeting.

After scrambling to build the feature, the async test is not going to be created (maybe because it’s more complex and time consuming). Also, more and more features will be added over time, also without proper tests. This will lead to more complexity until many so bad things happen that eat up all the time you think you’ve saved. Everything in this example could and should be automated.

Tools are important. Take some time to discuss them and test them if they’re new to your team.

QA should not be the only team worried about quality

The quality of a system is everybody’s responsibility. Keep that in mind. Quality should not be thought of as just a specific step of the project lifecycle, it doesn’t matter if it’s agile or not.

Forget about those cascade phases you used to have within RUP. Quality must be on your mind for all the stages of the conception, development, testing, delivery and even post-delivery. It’s an endless process.

If you’re a manager, identify who’s involved in the project and let them know the important role each one has in maintaining the quality of their work and the work of the rest of the team.

You can even integrate the creation of the tests among the different roles you have in the team.

There are great tools out there for cooperative work, like Cucumber, for example. It is a well-known Behavior-Driven Development (or BDD) tool that integrates with most programming languages and provides an easy, straightforward and universal interface based in English (or any other language you pick up) in order for people to cooperate when building BDD tests. After that, it then translates the universal language instructions onto code.

Like anything else, you need training

Just like coding and prototyping, none is born knowing how to automate.

If you’re new to this world, find help. There are tons of good training companies that will help you out. Personally, I’d prefer the consultancy option. This way, you can have trained and skilled people analyzing your main problems and concerns and adapting the training to get you where you want. This is even better if you have compliance issues to address or a certificate to get.

Just be careful to not extend the training outside of the company too much that sounds more like a third-party gig. The change must happen inside, not outside.

What about being agile?

Many concerns will come up at this stage. Who should create the tests? The QA or the developers? Or both? Which methodology should be followed?

The answers are very important, since they can lead you to rush in without considering many factors: the experience of your teams, the nature of your projects, the assets and resources available at the company, the category of the work (in-office or remote?) and how comfortable they’re going to be with the selected method (in the end, they are the ones who will follow it up).

Choosing agile must be an act of intelligence, so don’t slow everything down just because you thought it’d be cool or because someone else told you to. Find your own pace.

My daily reports

Remember that spreadsheets I talked about in the beginning? You’d be shocked with the amount of companies that still rely on them today.

The whole process of automating your tests is important. That means the execution, the collecting of the results, the preset rules you may have configured to extract information or take actions based on them, the monitoring systems and their alarms for when important things that shouldn’t break, well, break.

Again, there are many tools to deal with that. If you’re working in a microservices environment, with hundreds of applications working in parallel and accessing/altering the same data, the more your operations are automated, the better. From the identification of a problem, the attempt to fix it and the alarms to the support team, everything should be automated. Your call to action must happen when those mechanisms fail.

Where is your process?

Do you have a process? If so, is it easily accessible to others? How easy is it for a person who just entered the company to find out about it and learn it?

It’s not enough to make changes and try new stuff if you’re not organized. When your company grows and the flow of people coming in or leaving increases, your process is the foundation stone that’ll save the day.

Make sure to create it, document it, discuss it with your employees and evolve it continuously, as the company itself will also do. It’s key to have a tool that’s easy to use, safe and audit-prone (just in case you’re big enough to need that).

Some parts of your documentation can also be automated like the delivery of new features, bug tracking, staff registration, etc. or whatever you feel that should be part of it.

It’s all about culture

Like everything else, if it’s not in the culture of the company, it’s going to be hard to do. The importance of automation must be clear to everyone just like the importance of quality assurance. Change takes time and commitment.

The tools, a strong process, an agile methodology and good training will help you get started, but in order to continue, the cultural aspects must be assessed and remodeled if it’s the case.

It’s even more about value

The gains seen by adopting the automation of tests are enormous, but the value is the most important answer to the question of whether automation is welcome or not. Ask yourself at every step: is it really important? What value can we extract from this action?

Certainly, you’ll have lots of good answers. The value must be assigned to your team, to the process, and mainly to your clients, since they are the ones most interested in the quality of what they’re hiring.

After a while, you’ll notice a decrease in the number of bugs because now you have an automated routine to test if the new changes altered the functioning of the production code in any way. Your team is freer to address what’s important instead of losing dozens of hours looking for mysterious system behaviors or implementing a new “workaround” to temporarily fix a problem. It’s a win-win game: quality, clients, company, money and resources saved.