QAs! Work smarter, not harder!
In an ever-changing technical landscape, where more and more companies are trying to move into a continuous delivery approach, the demand for Automation QA Analysts is always increasing. The time for long manual checks of products just isn’t part of the new world order.
Now is the time for manual QAs to adapt and start to consider the world of automation and how they can get involved. This article will be about my personal journey moving from a manual to an automation tester.
My background
One of the first reasons I wanted to pick up skills in automation is that I really enjoy finding bugs in new features and trying out things with the software. Then came the regression packs — the task of running through everything and ensuring it still works.
This tends to be the part most testers find the most tedious, but we all understand why we need to do it. It’s so important that we don’t throw things out unexpectedly. So here at Crunch, on the legacy software, we run manual regression packs just before go-live. I was always worried I might forget something or feel the pressure of the impending release and the balance of the next new feature. With that in mind, I started looking at some test automation.
Lift-off!
I first started investigating Selenium and JUnit. I was hooked, and although there were a lot of pain points in making tests run correctly — it was something I could add to and use during quieter periods.
This was making me so much more confident with releases. I would run my automated scripts then check the new functionality once we were happy to push the changes live. After the functionality was live, I would add it to my regression pack and continue to grow my suite of tests. I will note here this was something only I used.
Move on a few months and I am now getting involved with the public-facing website and the world of Continuous Delivery. Now, this brought new challenges and required a lot of research into frameworks and testing tools. Here at Crunch, when a developer pushes to master, we can expect their changes to hit production in around 15 minutes or so. It reaches our pre-live environment and sits in there for around three to four minutes. So, there is no chance of a manual tester checking the new feature works correctly in that timeframe. Hence the need for automation.
The devs here do an excellent job on unit tests and integration tests. What we lacked, though, was the automated end-to-end testing. For my first attempt at this, I decided to stick with what I know, so out I roll with Selenium and JUnit.
I wrote some tests but the speed isn’t really there, and I ran into issues like the dreaded stale element (anyone who is familiar with this will understand my pain). I then ran into issues with trying to have the tests run in parallel. After some discussions with the other developers, I decided to scrap this and begin anew with TestNG.
With TestNG, we managed to get the tests to run in parallel using the Selenium grid and get them as part of the CD process. Everything is now working and we have successfully automated some key user journeys on the website.
Now comes probably the hardest challenge of being a Test Automation Engineer — keeping the tests running successfully and ensuring the feedback can be trusted. One problem we had with Selenium was the grid: we found we could lock up the browsers easily and the only way to free them was to restart the whole grid again.
This created inconsistency and lowered confidence in the tests, which was an obvious down point and frustrating for everyone involved. Roll-on trying to move away from the Selenium Grid.
New horizons…
Enter ‘Google Puppeteer’, and the host of brand new challenges brought on by using a new automation testing tool, and a new language in the form of JavaScript, which we have now successfully implemented. Puppeteer is faster, but challenging, as it’s still a young framework. The tests are more consistent now and the confidence is up from removing the dependency of the grid.
We now have to align our tests to be ready as part of the stories that are worked on during a sprint. We’re now looking to set up a new test-push, so that when a developer pushes their work to master, the functionality that has been pushed is automatically covered by the tests in pre-production, to ensure that no manual intervention by the tester is required. Once the tests in that environment all pass, then we go to production. We then have a regression test in place for all future deployments for that functionality. Perfect!
In conclusion
To round this article off, I would say any manual tester should take a look at automation testing — it’s interesting to get involved with and you’ll pick up some great skills along the way. It might take some time to understand it all but there is some great content out there.
Once you’ve got the hang of it, you’ll be feeling much more confident about the testing you are signing off, especially if you’re a tester who’s still doing some manual exploratory testing. You can happily go find those edge cases which are caused by some strange user behaviour, and then leave the planned journey users should take for the automated cases to run through.
The key parts I have learnt from the transition is to be happy to try new things out and embrace the challenge. The tests I’m writing only improve the more I get to grips with working on the new framework. Added to the experience I’m building by implementing and improving means the tests are in a better place than a year ago. I think this shows this Agile thing kind’a works, right? I implement a test I’m happy with, something changes, and we need to adapt to change.
Written by Dave Minns, Developer in Test based in Brighton.
If you’ve enjoyed this read please take a look at our other Crunch Developer Medium articles, and if you’re looking for a role in the Brighton area, take a look at our current vacancies.
