Before starting automation, you should change your mindset

Wellington Avelino
Dec 4, 2019 · 7 min read

Change culture not process

I’ve decided to write this post because this topic has surfaced time and again in many projects that I’ve worked on during my time in software development. It is a big misconception that automation is the root cause of issues in the QA process. However, it is my belief that in order to refine a process, the surrounding culture must be a supportive environment for it to grow and thrive.

In this article, I have detailed a few initiatives that can be followed and adapted according to a team’s maturity level and autonomy.

Common complains:

“We just need automation to make things better,” “Automation is the solution for us.”, “Just create more UI tests”.


Necessary QA skills

So let’s start with some self-reflection:

  • Is my team helping when needed?

If the answer to any of these questions is NO, then probably the culture isn’t right

Based on that, I will outline some points that highlight the importance of involving each team member in quality activities.

Culture

If you have previously encountered this conversation, you probably also have heard people say that this “broken process” is caused by the company’s culture; which is fine. But why is there no initiative to change it? Or why have any previous attempts to address any issues failed?

Sometimes, it is easier to keep going without trying to improve.

Considering the questions from the beginning of this article. In those questions I highlighted some common problems that might be causing issues in your company/project:

  • QA as a gatekeeper of quality.

Mindset Change

Changing people’s mindset might be the biggest challenge.
You have to learn how to handle different situations and how to approach people with diverse backgrounds and characteristics. I read this book that I probably already recommended to you if we spoke face-to-face, called “Agile testing” By Lisa Crispin and Janet Gregory. Published in 2008, I would consider this to be a “bible” for the testers of today. It surprises me that there are a lot of professionals that have never heard about this book, or even know what Agile testing means.

This book will open a window of diverse possibilities in the agile process.

Below I have outlined a few small changes that you could build upon.

Start asking yourself, have I shown to my team what quality is?

Sometimes your team or manager don’t understand what is involved in being a QA, and what it is that you actually contribute to each sprint. It’s our responsibility, as QAs, to clearly outline and define what we do. To address this you could organize small sessions to discuss what you have been doing and how you can help the team to achieve the Holy Grail of quality.

Are your tests done at the end of the process?

It is ubiquitous when tests are still a phase in the process: in the traditional mindset, tests only happen at the end of the cycle. You shouldn’t be testing at the end, and you should bring quality checks as early as possible; by doing this your goals will change as well. Instead of playing catch-up with bugs, you will prevent them from even happening.

Some examples could be:

Suggested activities

Shared responsibility

Shared responsibility should be what you’re aiming for since you shouldn’t be the only one that cares for the quality. This can sometimes be a challenge as it may require an initial shift in thinking and mindset from you and your team. Once everyone is on the same page, shared responsibility can start to become a reality. Here’s is a list of suggestions that are based on my previous experiments/experiences:

  • Shared responsibility doesn’t mean that you will lose your job. It means that you’ll have more time to explore things that matter instead of being stuck performing boring test stuff.

You’re no longer trying to find bugs, you’re trying to prevent them from happening.

Yes, it sounds a bit weird… but you get used to it ;)

We’re no longer the last and only person concerned about quality, so why should we still catch bugs instead of preventing them?

Maybe it doesn’t look like our job, but during refining meetings, it is important to try and make sure that everyone is on the same page. From my experience, back-and-forth conversations happen during development when there is a misunderstanding of what the end result of a feature should be.

A few simples questions could help, such as:

  • Is everyone on the same page?

A test engineer asking those questions could sound a bit odd right? But as I said before, shared responsibility is not only tied to quality; it’s everything!

But Wellington, where do I start?

  • Start with one person. You need to get used to this way of working before spreading it to the rest of the team. The benefit of doing it this way is that you’ll develop proficiency, and it will be much more likely that the person will be your ally in selling it to the rest of the team.

You should keep in mind that there’s no silver bullet, and you should adapt yourself to different contexts and make small changes incrementally. You soon will realize the effectiveness of doing things step-by-step rather than doing everything all at once.
To do it right, you should have allies, followers, believers, not only executors.

Automation

At this point, you should be wondering why automation isn’t the first topic of this article. Let me explain the reason.
Automation is the tip of the iceberg; if you don’t have a good culture or even don’t have people to support you, it will be hard to get things done.

You should choose the automation framework carefully and do your research to understand what suits you and your team.

What should you consider?

  • If the framework is continuously maintained and updated

Continuous integration

I might be saying the basics here. Don’t get me wrong, but automation has no value if it is not running on CI under a good strategy. It should run fast and provide feedback in each stage of the integration. Explore parallel execution, consider splitting your suites into smaller ones so you can have more control over each test execution.

Reporting

You should also find a way to give visibility to what you’re doing. The right direction for this is to use your automation framework to provide that for you. Pretty much all of the automation tools have a way to generate reports. Most of them are following the JUnit pattern, which’s easy to parse and render it on a big monitor using a dashboard.

Takeaways

  • People over the automation process.

I hope that this post helps you to make some improvements in your team or at least acts as a catalyst that sparks a change.

Good reference books.

Agile testing & More agile testing
Specification by example
Continuous delivery

assert(QA)

Best practices, quality assurance, software engineering, career and more

Thanks to Szymon Kazmierczak, Leonardo Galani, Naiana Bezerra, Vinicius Moleta, and Deirdre Hegarty

Wellington Avelino

Written by

QA Engineer, Software developer, photography enthusiast, and traveler.

assert(QA)

Best practices, quality assurance, software engineering, career and more

More From Medium

More on Testing from assert(QA)

More on Testing from assert(QA)

More on Testing from assert(QA)

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade