From Manual to Automation Testing – Lessons Learned

Test automation has increasingly become a buzzword over the last few years. Although it has its limitations, it has proven to improve the quality of applications and reduce repetitive manual efforts. Over the last two years, I dived into it to be able to understand the realm and how it fits in with my manual testing 🔍

So far, the top 3 lessons I have learned are:

1. Select a specific language/platform to focus on first
2. Developers can be your biggest allies
3. Start your automation suite simple & then build it out

For context, I have worked at digital agencies and consultancies for the last few years, which means we work on different projects across different platforms and languages based on the clients’ needs.

I started dabbling in test automation with some of the projects I have worked on while I was doing mostly manual testing. However, in the last 6 months, I have been able to make it a priority with my current projects and had enough support to drive it.

Lesson 1: Select a specific language/platform to focus on first 

When I first became interested in picking up test automation two years ago, I didn’t even know where to start. At first, I thought taking a course on Swift would be a good approach so that I could get familiar with iOS and write some automated tests for the mobile applications we built 📲

That was not a good idea (not for me at least) because it was a bit overwhelming to learn as a first language. Plus, as a new test automation engineer, you don’t necessarily need to know the entire language to start writing tests.

Then I started learning on the job and implementing test automation on the projects I was working on with a lot of help from developers. In my first year, I learned automation testing for a Reactive Native application, mobile applications, and web.

This sounds great in theory that I got to dabble in so many different frameworks and languages, but, in reality, I was never able to dive into them long enough to be able to feel comfortable and confident that I could implement them myself on another project.

Finally, I came to a company where they had laid out a path for automation engineers – you select to specialize in web or mobile. Selecting the web path meant using primarily JavaScript while selecting the mobile path meant using the native languages for mobile applications like Kotlin for Android and Swift for iOS.

This made so much more sense and finally helped me focus! It’s hard to find engineers that know Kotlin, Swift, and Javascript – so how are automation engineers expected to know so many languages when just starting?

Once you can really deep dive into one and feel comfortable with it, it is a lot easier to learn the next language/framework as they all are pretty similar to one another.

Lesson 2: Developers can be your biggest allies

I owe most of my QA knowledge to the fantastic developers I have worked with within my career, and this is true even more so in my journey into test automation.

A lot of the developers I have worked with were responsible for writing automated UI tests themselves at one point, so they have a lot of knowledge about the best way to do things 💡 Additionally, getting developers on board and across your test automation strategy is important so that both QA and developers own the tests.

Throughout building the first phase of our application, there were lots of changes that impacted the UI tests. The developers were able to add those new dependencies into the UI tests so that the tests would continue working as we built more features.

Choosing to use a native framework can be beneficial because both QA and developers can help maintain the tests. With native frameworks, the automated UI tests are within the same repository as the application itself, so developers are more familiar with the language and have easy access to the UI tests.

Lesson 3: Start your automation suite simple & then build it out

I think this lesson applies to both beginners and QAs who work in an agile environment building a new application with changing requirements and refactoring under tight deadlines.

Starting with just building end-to-end UI flows has helped me become comfortable and familiar with how Android works in general. Once the critical paths are automated, you can then focus on building that suite out and adding regression test cases.

By then, hopefully, the features are more stable and permanent so that we can avoid continuously refactoring or updating tests ✅

Conclusion

There are still many things in test automation that I haven’t even touched and there are some things that I am still trying to work out. These include things like:

• What is the best way to test automation effort in sprints? Should there be a separate card for automating that test or is it part of the user story? Are automating features always a sprint behind?
• How do device farms work when setting up automation tests in CI/CD?
• Do I need to become more involved in setting up the CI/CD?

There is a lot to learn in the test automation realm, which keeps it interesting. I have to give a lot of credit to my mentor, Jaswanth, who has elevated my automation skills by 200% in three months by helping me focus on a path (mobile test automation) and uncovering these lessons for me.

As a QA who struggled to get on the right path towards learning and implementing test automation, these three lessons have been central in helping me achieve that. As I continue to move forward in my test automation journey, I know that lesson #2 (Developers being your biggest allies) will be one of my core principles 🙏