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?

• Is quality a shared responsibility?

• Is testing an activity?

• If the QA is out sick, does the team know what to do?

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.

• The team doesn't understand what the QA is doing in the sprint (I know, it's almost 2020!).

• The team recognizes the QA as a problem-maker and does not see them as someone who is part of the process that provides solutions too.

• A lack of understanding that quality assurance is a phase within the development cycle.

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 doesn'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.

• Your team has to see you as a critical part of the process, in other words, you should be the one that they will seek for testing knowledge.

• Organize exploratory sessions with the team to help them create empathy and learn more about how the product works and what it looks like.

• In general, we tend to work on small pieces of the product, and we don't have a vision of the big picture, which isn't a good thing if we want to put quality first.

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?

• Do we have any concerns regarding how the feature should work?

• Are we comfortable with the acceptance criteria?

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.

• Be proactive and test early in the process. Check out the branches that your team-mates are working on and perform some validations.

• Don't wait until the developers put the story in "Ready for QA" lane (or whatever kind of the process you're using).

• Perform exploratory testing instead of tedious manual scripting testing.

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

• If it suits your needs

• If you're working with backend, it doesn't make sense to create a separate test project, it will only create a wall between you and the engineers.

• Consider using the same programming language that the team is using to create the tests; it will remove the knowledge gap and reduce maintenance cost.

• On mobile, you have different options using BlackBox frameworks such as Appium, Robot, or even Whitebox frameworks such as Espresso, EarlGrey, XCTest. Choose carefully, and don't get too excited or you will overload the UI layer with tons of tests; you should split those validations. There could be an entire post dedicated to this topic.

• If you're thinking of using any BDD framework to write your specifications, validate it first with your team. It has a HUGE benefit, but only if the entire team is sold with the idea and helps to get this done collaboratively.

• You should be able to write useful unit tests and help the team to develop it if necessary. Remember quality over coverage, learn about mutation tests, and explore it with your team; you might be surprised in how many "assert true" you can find.

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.

• Start small, get support, and go bigger.

• Quality isn't only automation.

• Instead of choosing tools that make you work, choose tools that work for you.

• It's your job to make sure that everyone knows how important you are; quality assurance has always been a role that people don't fully understand.

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