× close Kiandra IT Logo Kiandra IT
Back to blog

Transitioning from manual testing to automated testing

Written by Pooja Hariyani, Automation Test Analyst, Kiandra IT

What is testing in the software world?

Software development is a tricky process. When new features and functionalities are added to a software product, it often does not work as anticipated or causes bugs in other extensions of the product.

To counteract this, most reputable technology companies employ testing engineers/software testers in their Quality Assurance (QA) departments. Some large tech organisations even have entire QA teams devoted to a specific product or even a specific part of the product, whereas small start-ups may have a single tester that manages the entire testing suite of the software.

QA/software testers use a variety of different methods of testing to validate that new features work as per the requirements and there no defects. They not only search for bugs, but are also responsible for testing features and suggesting improvements that will strengthen the end-user experience.

Even though there are many methodologies and best practices for software testing, the industry can typically be drilled down to two distinct areas: manual testing and automated testing.

Manual Testing

Manual testing requires the most effort, as it involves testers manually executing test cases. This is the most basic (but necessary) of all testing types and helps find bugs in the software. All new software must be manually tested before testing can be automated.

The objective of manual testing is to ensure that software is error free and is working in conformance to the specified functional requirements.

Automated Testing

As the name suggests automated testing is, well, automated. Test automation involves writing tests which access a framework that mirrors the actual product being tested. Tools such as Selenium WebDriver, Protractor or Katalon (to name a few) use the elements/functions written in the framework to automate the browser, web based or desktop application being tested.

Becoming an automation engineer requires programming skills, but it also has a lot in common with employing best practices as a manual tester.

Transitioning from manual to automated testing

Say no to repetitive tasks

Everyone would agree that manual testing is haunted by repetitiveness. Doing the same thing over and over again is boring. Some people will overcome this challenge by automating single bits and pieces of their work. The result of fighting repetitiveness will be a collection of small utilities and scripts to make life easy, for example: a script to import test data into a database instead of creating test data manually.

Start small

It’s tempting to begin a project with a view to allocate lots of resources for automation. However, I would argue that even if you have resources, it’s the minimal tangible results that are the most important in test automation. One test providing reproducible results is far better than a huge matrix of tests of green, red and yellow. At this point, the tools don’t matter as much as a single stable automated test. My recommendation is to evaluate pain points (repetitive tasks) and pick scenarios that regularly catch regression bugs. And, what could describe a success story better than your automated tests finding bugs from day one!

Find a place for your scripts

The helper scripts will be used by you and your team, and will also require updating as software changes, so it’s important to store them in a centralised and accessible location. A source control system like GitHub is perfect for this.

Do not isolate the automation team from functional testing

Many organisations have a separate automation team that are dedicated to writing test scripts. In my experience, the quality of automated tests and their development speed is higher when those writing tests are also ones who have done functional testing, or at least have functional knowledge of the software. If the automation team is separate from the testers who performed functional testing, this will lengthen the feedback loop making the whole process less effective.


The test code is just like product/software code, so changes are inevitable because as your software changes so to should your automated tests. The amount of refactoring should be healthy: too much and all you’ll do is refactor instead of writing new tests, too little and you run the risk of building up technical debt.

Integrate your tests with Continuous Integration (CI)

Once the tests are stable, it’s a good idea to connect tests to the build system, so that whole build runs in several clicks triggering tests every time you amend your product/software.

Last but not the least – practice coding!

Coders learn to code by going beyond the classroom and experimenting on their own by writing programs and apps. Automation testers should do the same. To be a good automation tester one must build analytical skills and coding skills. For example every time you visit a website think: How would I test this web page, and what tests would I write?