automation | QA InfoTech

QA Info Tech - A Brand Built on Results

Testing Chronicles - QA InfoTech Corporate Blog

The Bugs Stop at Our Bay

24Aug, 2016

The Encouraging Atmosphere in the Selenium Test Automation Conference

Open source has revolutionized the way software is developed, tested and used amongst the user base and has built a positively re-assuring community in how we collaborate and deliver. While all of this has been a remote working culture for me, it was very encouraging to have recently been a part of the Selenium Test Automation conference in Bangalore. I have been to several conferences thus far, and while some continue to be very well thought through and professionally run, the Selenium Test Automation conference in itself was a differently welcoming experience for me. The overall proposal submission and selection process was very transparent and collaborative. I was there to speak on a non-technical but important topic for software testers on test prioritization – my recording from the session is available at https://www.youtube.com/watch?v=QZpE-W6yNK4

09Jun, 2015

Should Manual Testing always precede Test Automation?

In the traditional forms of software testing, it has always been considered a good practice to test and sign off on a product manually and automation to start post the sign off. In such a setup, software test automation has always been one cycle slower than the manual test efforts. However, the testing lifecycle has undergone significant changes in recent times. The entire cycle itself lasts only for a few weeks, sometimes even just a few days, which makes it very difficult to get the required test coverage manually. Over the last few years, test automation has definitely moved up the cycle with the move to Agile style of development. Test driven development has brought in test automation even before development can take place. While there are advantages in such an upfront test automation investment, there are still some core benefits of manual testing preceding test automation. What are they? Primarily, it strengthens the tester’s understanding of the product functionality. Such an understanding given an overall view of product workflows, critical scenarios, kinds of errors, enabling the tester bring in stronger validations in the automated suite. Given that product documentation is also not as detailed as it used to be (for the right reasons) and the overall product landscape itself is very dynamic today, the best way for a tester to gain product knowledge is to test it manually. When this is practiced amongst all testers, at least in the initial few releases of the product, the core product understanding is very strong that the bond between functional testing and test automation is very tight. This will help reap the maximum ROI from the test automation effort, making it very reliable and maintainable.

Today, a lot of new frameworks are coming in to help functional testers (manual) take on test automation, although they may not know programming. This connect between manual functional testers and test automation is a very good bond where test automation suites are now stronger in test coverage and validations, as opposed to a set of mere lines of code, that are weak on their asserts, lacking a thorough understanding of the product. Test automation, at the end of the day has to seamlessly integrate with the core functional test effort, were automation engineers will also have to get involved in the manual effort to understand the product’s intricacies. The current day test environment is encouraging this, with a good handshake between automation engineers and manual testers, empowering both to step into the other’s shoes, which is a great move to pushing quality upstream. So, rather than being a question of whether manual testing should precede test automation, it should be one, where manual testing and test automation should be tightly integrated, almost liked a paired effort, to maximize coverage, the quality of the automation effort, and the bonding between the testers.