Automating processes doesn't happen overnight. It's a journey, but it doesn't have to be complicated. Discover our story...
Innerworks is coming soon...
This blog was originally published on our previous Cogworks blog page. The Cogworks Blog is in the process of evolving into Innerworks, our new community-driven tech blog. With Innerworks, we aim to provide a space for collaboration, knowledge-sharing, and connection within the wider tech community. Watch this space for Innerworks updates, but don't worry - you'll still be able to access content from the original Cogworks Blog if you want.
It takes courage to question the status quo.
The thought of change can be daunting when you've done something a certain way for so long.
Here's the thing; there is no need to dread a major process change. Working in short sprints, step-by-step, can help you reach your goal.
Here's how we adjusted one of the most crucial processes at Cogworks, the QA process.
Why change the QA process?
We've always known that automation is the way to go.
Of course, automation only solves some things.
In the QA world, we think it's best to have the best of both worlds; manual and automated processes together (read more about why we think manual testing is here to stay in a previous post)
At Cogworks, we use various solutions to test our products and consistently follow a modern approach that works.
The challenge.
We didn't have an automated process at all.
"The challenge was combining lengthy learning and creative processes with our everyday tasks. That meant lots of switching for tasks within our daily routine" -QA Tester Agnieszka Burczyk.
We're pleased to say our automated process is in place.
We use automated software tests for regression and smoke testing during deployments. (If visual regression testing is your thing, we've put together a Quick Guide to Visual Regression Testing With Cypress).
Here's how we went from manual to automated testing:
1. 2020 - Investing in people!
No one needed to convince us that test automation was an advantageous element of the testing process.
However, we knew automation processes don't grow on trees and that it would take months to hire an expert, train the team, establish the infrastructure, write scripts, and document the process.
In 2020, we opened a new role for QA, hiring a specialist with self-acquired but well-established skills in writing automated scripts in Selenium and Cypress, plus knowledge of automated software testing tools.
It was an exciting day in our remote offices!
Our new QA, Aga, joined us intending to propose an automation tool and implement the first tests...
2. Selecting the right automated testing tool.
We started with an in-depth analysis of the available automated testing tools in the market, considering our current technologies, budget, know-how, and the tool's difficulty.
We landed on Cypress as our official software automation tool.
Our team already knew how to use this framework. Plus, we've been watching the Cypress "hype" for a while; it has a growing community, offering great support, instructions, conference speeches and courses.
Adopting Cypress was a no-brainer; all of our projects were on Umbraco at the time, and Cypress was a Umbraco official testing framework (at that time)! It was meant to be.
3. The pilot project.
In the beginning, we used automated tests for a small project which was at a late development stage at that time.
We found it the safest to start with small and easy things and gradually increase complexity. We had yet to experience creating the whole test architecture for all our projects, hence the pilot project.
The first automated tests we ran were not connected to any CI/CD pipelines. When you're learning, it's better to run them locally experiment on your local machine than make an extra effort to establish tests on a DevOps platform.
The pilot project presented surprises!
It quickly became evident that bugs popped up earlier than you think; we found a bunch when doing the first test preparations & drawing acceptance criteria.
From the very first automated test, the benefits were clear. Detecting issues earlier on in projects was a big green tick!
So far, so good.
4. Developing a strategy for multiple projects.
Next, we decided to write tests for a complex QA phase of a design and build project, Canada Life.
Source: Canadalife
It's a fairly big site, with many different components used on the front end. We used these tests as a starting point for future projects!
Writing the initial automated tests was the first time we introduced a CI approach and pushed the tests set to our DevOps for external usage. At this stage, we noticed a need for creating a library of common tests so automated tests can quickly adapt to other projects.
We documented every decision regarding environments, browsers, and other configurations in our company handbook, ensuring the new process works seamlessly with existing company processes.
Since developing an automated testing strategy, we've saved time on multiple projects, cutting our time spent preparing tests by nearly 200 hours in some cases!
5. The importance of ongoing QA test maintenance.
Once our projects "go live", we often maintain, support and make iterative improvements on our clients' websites.
Of course, new designs, features and components mean more tests! We've built ongoing QA testing maintenance into our process to ensure that our test library is always up-to-date with the latest acceptance criteria, test cases, and test templates.
6. Building continuous improvement in the QA process.
During the implementation of automated tests, there were challenges; flaky tests, working with dynamic element classes and attributes, testing backend applications and adapting tests for multiple environments, not to mention the everyday challenges of how to run tests regularly or how to return test reports which are understandable and easy-to-read!
Luckily, building continuous improvement into the process helps us tackle these challenges week-on-week.
Where we are now.
Implementation of automated tests in our company took a lot of work. It required hours of discussions and total immersion in the technical details, but after two years of starting this process, it was worth it!
We learned so much as a company, developed many skills individually and assured quality for our customers.
Creating an automated software development strategy process has given us more time.
Our clients are happier, and our internal teams are more efficient, freeing the team to focus on the creative stuff.
It's built into our process to keep an eye on the other modern testing tools, so, as always, we remain open to new opportunities.
If you're in the mood for more QA testing more on QA testing, head to our blog for loads more insights.
-How to Test Accessibility With Axe in Cypress
-The Quick Guide to Visual Regression Testing With Cypress
-Getting started with visual regression testing and WebdriverIO