When I started working in Quality Assurance, automation was not the driving force that it is today. It was becoming common, but Test Driven Development was the goal of software companies. Unit testing was king. QA tested applications manually and focused on the user interface and experience. It wasn’t until my boss told me to look at WATIR that I began thinking about automation.
My first scripts were basic. Very basic. They were designed line by line to cover my build verification test. They were far from reusable. I look at them as if they were done by my first grade self and not an adult, but they worked and I was able to reduce my manual testing time. Eventually I began to create cleaner code and develop more functionality for my scripts. I learned about PhantomJS and CasperJS and began using them and learning more. After leaving lynda.com, I moved on to my first position as QA Manager. I was in charge of automation, regression and load testing. I learned a great deal there, but really didn’t level up until towards the end of my time there.
When I moved to my current position, I had to restart the automation effort. Because the scripts were dated, I decided that starting from scratch would be the best approach. I decided to go with Ruby as the language, because it’s easy to read, learn and teach to individuals with little development experience. I selected Page Object Model as my framework, because it would work for the majority of the products I needed to test. With my POM testing in place, I added PhantomJS and CasperJS for light touch testing post releases and throughout the day. All of these scripts are executed and reported in Jenkins, so they run after each release.
I had never thought of myself as a developer while doing any of this. I still saw myself as a QA Engineer and then a QA Manager. But somewhere along the line, I realized I was thinking like a developer, and that made me a better tester! Knowing how a developer thought improved my questions and knowledge of how the code worked. I had always been a good technical tester and knew how the systems interacted, but now I understood how the code worked and where there were potential breaks. My conversations during grooming and planning meetings were more focused. All of these things happened without my realizing it.
I started creating automation to reduce the time I spent doing routine and predictable, regression testing. This allowed me to focus my testing efforts on higher value projects. I continue to create automation so that I can improve my skills, think like a developer, teach other QA Engineers, and for so many other reasons. But now, I enjoy it and can’t think of testing without thinking about how to automate it. There will always be a place for manual testing, because you can find things that you wouldn’t think to automate on your own with it. At least now, we can offload some of the more predictable testing to the machines.
Why do you create automation?
(Image credit to https://unsplash.com/@farisfawaaz)
One Reply to “Why I Create Test Automation”