Is test automation a task for developers or testers?

test automation

With the rise of new software development methodologies, such as agile development and DevOps, we are witnessing a continuous crossover of activities. No longer are functions such as testing carried out in isolation. Software development has become a collaborative process where the tester and the developer have to work in tandem to create products that, can not only be delivered in time but that also function flawlessly. With shortening development cycles, test automation has emerged as the great enabler. Test automation has taken the pain out of testing by implementing self-testing codes and automation suites that ensure that every piece of code is tested thoroughly in the minimum possible time.

Both developers and testers work with the same intention – to create a quality product that behaves as it should, though one works to make the code and the other, works to break the code. When it comes to Manual Testing, a tester has to essentially sit in front of the system and physically run the test cases without using any automation tools. Hence, it has not been essential for manual testers to know programming or code. When it comes to software testing automation, though, the task is to “develop” a test automation suite. Since the goal of test automation is to reduce the number of test cases that have to be run manually and increase the speed of test execution and the scope of test coverage, designing the test suite that accounts for which test cases should be automated assume great importance.

Clearly, developing a test automation suite also requires a certain amount of coding and programming. This means that test automation presents as an inherently programming activity and hence, require testers to have some programming skills. Owing to this need we have witnessed the rise of the Software Design Engineer in Test (SDET) – a role that combines the roles of the programmer and that of the tester. Take a look at some of the job postings for testers and almost 75% of the listings require programming skills. So while writing code and debugging is essentially a developer’s job, a tester will have to know how to code so that he/she can develop the test automation framework to run the test.

Having said this, it is important to note that testing is a specialized job. Typically a tester will know which workflows, fields, and scenarios have to be tested manually and which can be automated. Testers need to have a different mindset in order to find defects before the software is delivered to the customer. Testers also possess deeper functional and domain knowledge, so that they can test the software by keeping end user’s perspective in mind. They have deep analytical and investigative skills and the knowledge of where the bugs tend to hide. They know which testing path to take and will ensure that no test is skipped. Additionally, testers also know the faster way to logging and reporting bugs and errors. They are also unbiased towards the developed code and can break the software in a dispassionate manner as they are not attached to the written code. Many developers might not be able to take an unbiased approach to the code developed by them and might end up overlooking certain issues that a tester would not.

Testing is also a time-consuming task since every aspect of the product has to be tested thoroughly. While startups or small development teams might be able to handle the testing functionalities with the help of developers, larger development projects demand the need of a dedicated testing team. Such testing teams work as an extension of the development team, one that views the work done in a dispassionate manner.

Scriptless test automation can come to the rescue for teams looking for a middle path in choosing between developers and testers. Simply put, Scriptless test automation allows the testers or subject matter experts or business users, to create their own tests for automated testing without having to write code. Scriptless test automation uses code assets to build tests that can be selected and edited for use and do not require the tester to have programming skills. A scriptless test automation tool gives manual testers the flexibility to quickly automate the desired tests but does not need them to code while doing so. Such a test automation platform is an extremely flexible platform that can adapt to the testing needs by scaling up or down and takes care of the heavy lifting in testing. Using such a platform ensures that the test automation framework itself can be maintained as a product- one which just needs periodic maintenance and updating.

Thus scriptless test automation can act as the perfect mediator of the developer v/s tester debate and ensure timely deliveries, reduce testing effort and offer a greater return on investment. It is the most powerful way of bridging the gap between subject matter expertise and speed.

4 thoughts on “Is test automation a task for developers or testers?

  • I have a few issues with this article. Here they are:

    Agile software development exists for decades, it is not new by any stretch of the imagination. Scrum and XP started in mid 90’s and Agile Manifesto was published in 2001. DevOps in not a software development methodology it is rather a cultural approach to software delivery within the organisation.

    Testing has never been carried in isolation. Even in traditional, waterfall-based, approaches testing has always been done in collaboration with BAs and Developers. At least in theory. It was a bad organisational practice to delay the testing until the very last moment and then execute it separately from everything else within very short time.

    Testing is no more time consuming than any other task in software development. With some obvious exceptions, not EVERY aspect of the product has to be tested thoroughly. That is why risk-based approach exists. If you have a feature that only 1% of your customers will ever use you can afford not to test it 100%. Testing “thoroughly” without any thinking can be very costly.

    Speaking from experience, scriptless test automation is not a new concept. I’ve been working on such solutions since late 90’s. It has been known under various names the most common of which is probably “keyword-driven”. Like with everything else, it is only good when implemented properly. This approach has some benefits as well as some drawbacks. The benefits are, as mentioned in the article, that almost anyone with product knowledge can create and execute automated tests. The drawbacks have not been mentioned, however. And there are some important ones to consider. The cost of initial development of such scriptless solution is usually very high without immediate benefits. The adaptability and scalability of the solution will depend greatly on the initial planning and will require substantial maintenance effort. This is especially difficult with products that are immature or change a lot due to they inherent nature.

Leave a Reply

Your email address will not be published.