Journey of a Manual QA into an Automation World
Tips to help you transition from manual quality assurance to quality engineering and test automation
Hi there! My name is Deb, and I’m a Senior Quality Engineer at Slalom Build. If you’ve found your way here you may be experiencing what I was a just a few years back, at a QA crossroads of sorts. See, I had been manually testing web and desktop applications for about three years. The company I worked for was moving from on-premise to a cloud platform, with the goal of continuous delivery. This meant adding test automation to an Azure pipeline.
So, I had two distinct options:
OPTION 1: Take the opportunity and go for it! Learn how to do it all and implement the automation.
OPTION 2: Run scared in the opposite direction because what was coming was overwhelming. I knew zip about automation, programming, cloud, scripting, and oh so much more.
Well guess what, I chose option 1! I stayed and I learned! And I failed. And I learned some more! And I repeated that pattern until I succeeded. Sure, the final result wasn’t perfect, but it worked! And I’ve since grown into succeeding far more than failing. So to help all you manual QAs staring at an automation dilemma, here‘s how I got started in Test Automation.
TIP 1: DECIDE IF YOU WANT TO GET TECHNICAL. Manual testing is not going anywhere and will more than likely be part of your daily routine. But you will have so many more opportunities by adding technical knowledge and skills to your arsenal. Will you have to learn a programming language? Yes, and probably more than one. You will learn scripting, API testing, automation tools and frameworks, so many different technologies. Many Quality Engineers also work in cloud platforms. Honestly, really fun stuff!
Learning from others helped me immensely. I was fortunate enough to have the most supportive manager, director, teammates, and peers to guide me along the way. With their support, I dove into learning automation and all that comes with it. They gave me a base to start from, and a guide to meet my end goals. It has also given me the drive to get to a point where I could pay it forward and share my knowledge with others.
Tip 2: FIND SUPPORTIVE MENTORS OR GROUPS. If you don’t have any near you, reach out to people via LinkedIn or through local meetups. (I joined this one a while back: https://www.meetup.com/Houston-Software-Quality-Assurance-User-Group.) Since things are still mostly virtual, you could conceivably join tons of groups and meetups
I accepted the automation challenge and had my first goal laid out. Automate the smoke and regression tests and include it in the Azure pipeline. What next? The application I was testing was a .Net application built with C#, SQL and JavaScript. It’s best practice to write automation that can be included in the application repository, match the app. So, I started by taking classes in C# and SQL courses.
Tip 3: LEARN A LANGUAGE. There are many free and inexpensive courses to learning everything you need to be successful. For those who do not have an app to start with, do your research on top languages for QE Automation. IMO, Java or Python would be a good place to start. And you don’t have to be a badass programmer to succeed, getting to an intermediate level will do the trick. You will learn more as you automate, I promise! Here are a few sites that I have used in the past.
Mini-tip, for sites like Udemy, always search online for a promo-code.
After taking C# courses, it was time for me to attempt to write some tests. The first part of that was to put together a testing framework. A test automation framework is made up of the tools and practices used to design and create test cases. The framework may include re-usable code, test methods, object repositories, libraries, reporting and more. The tools also used in the framework should be chosen in conjunction with the programming language. Since my first tests were going to be a quick UI Smoke, I went with Selenium WebDriver, NUnit, and used Visual Studio to create my first project. You may have heard of Selenium WebDriver, it’s an automation tool that mimics user actions in the UI, allows for cross-browser testing and can be used with different programming languages. NUnit is a .Net testing framework that executes tests and uses Assertions to determine if tests pass or fail. Visual Studio is a popular code editor. Your framework will depend on a number of things such as the type of application being tested (web, desktop, mobile, etc), programming language, requirements and cost.
Tip 4: BUILD A TESTING FRAMEWORK. There are tons of courses and learning paths based on programming language, application types, and automation frameworks. I wish I had known about this site when I first started, https://testautomationu.applitools.com/. It’s free and is everything automation. If you are not in a position where you are able to write against an existing app, use a dummy app. This site provides just that, https://ultimateqa.com/dummy-automation-websites/.
After putting together the framework and writing the tests, I was successfully running them locally on my laptop. Then, in a fit of panic, I started wondering what would happen if I was on PTO or won the lottery or, worse, lost my laptop! We’d have to take extra time to test manually, which in turn would delay the release. So I saved my project to our repository, so others would have access to the test automation project. There’s still manual work there though. Someone would have to pull my project down, run the tests locally and then get those results to the rest of the team. We had an awesome DevOps guy (shout-out to CB) that walked me through getting the test project included in our Azure pipeline and up and running after every build to Beta and Prod. The smoke and regression test results were even displayed on an Azure dashboard for anyone in engineering to view.
Tip 5: INVEST TIME INTO LEARNING THE ENVIRONMENTS. Reach out to your engineering team members. Ask them where the application repository is saved, what the environment architectures look like, and how automation can be included. This is definitely a time that asking for guidance is necessary. If a cloud platform is in play or upcoming, I highly recommend learning the basics of that platform and working towards earning at least a base certification. The most popular being AWS, Azure, and Google. In addition to the sites in Tip 3, there are other great sites for leaning cloud.
One of the bigger mistakes of my first project was that I was completely focused on UI tests, not bothering to look into any other type of testing. Mini tip: research the Test Automation Pyramid! In a nutshell, it has the different types of automation testing split into 3 layers: Unit, Integration/API, and UI. The top layer of the pyramid is UI. Familiarize yourself with the API layer of applications, because this will be a big part of your testing. Although Unit testing is typically completed by Developers, there may be times where you are reviewing or even writing Unit tests. Also, there are different types of application that can be tested, Web, Desktop, Database, Mobile, etc. Right now I’m learning to test mobile, so the education continues!
Tip 6. NOT ALL TESTING IS UI TESTING. You will continue to learn as you go. Whether it’s including SQL queries in your project, writing tests for an API, or even adding scripts to kick off tests in the pipeline, you can always learn more. Don’t forget about that Test Automation Pyramid.
I was comfortable for 10 years with the same company but, I needed a change. I accepted a couple of positions before I landed at Slalom Build. Although I learned a bit with each of those roles, neither was the right place for me. Slalom Build is a company based on inclusion, diversity, and a wonderful set of core values. It’s the perfect fit for me. Be open and find the best fit for you!
Tip 7: BE OPEN TO NEW OPPORTUNITIES. If you decide to get into automation but are in a position where there is nothing but push-back on implementing automation, update that LinkedIn profile! Get busy looking and applying to something more in line with your goals and values.
My first couple of interviews were fairly easy. But, the more I interviewed, the more I realized I wouldn’t get by on chit-chat about my previous positions. Be prepared for technical interviews.
Tip 8: PREPARE FOR THE INTERVIEW. Once you get into automation, be prepared for technical interviews. Create a GitLab or GitHub account and add examples of your work that can be shared with potential employers. Research how to do well in technical interviews. Go on interviews, even when you are not looking for a new role. Become a boss interviewee!
I asked a few of my teammates “What advice would you give to a Manual QA wanting to dive into automation?” Here are some BONUS TIPS!
“Don’t be afraid to ask questions.”
“Use a good IDE with IntelliSense.”
“Continue your journey with attending user groups, maybe become a mentor yourself.”
“Choose a tool which has a lot of articles/tutorials and support group. Having a mentor would also be great.”
“Write code. Do not use the record/playback option.”
“Set a goal to write 5 tests for a public website, pick a modern automation framework with an active community, then find a newer tutorial follow. Having a friend to go to for questions when you’re stumped is very valuable”
“Realize that path from manual to automatic engineering better not begin with a programming language, or not with automation tools, but with motivation”
“Understand the business value of automation and the feasibility of implementing it on a project, where to start automating and what cases to cover, and so on.”
Thanks for reading! And happy testing!
