At the end of the day, are your product’s stakeholders interested in how complex your automation code is, how much automation you built, how native or high end your automation setup is or how it has helped in determining the quality and readiness of the product for release. In all likelihood, it is the last one that they would be most interested in. However, what is changing today is the rise in the number of people using the test automation. Right from developers, to build engineers, to operations and support teams a lot of entities in the product team are using the automation. A lot more, including non-technical people such as business and marketing groups are looking at the automation results to interpret the status of quality. Within the testing team itself, people who lack expertise with programming languages are executing the automation code, trying to make fixes, build new automation on top of the scalable automation framework etc. Teams are increasingly dynamic in their size and structure that the same person who worked on the automation of a certain piece of the product may not be responsible for a subsequent release.
All of these diverse users and uses are increasingly requiring automation engineers to simplify the core automation solution. Automation is also growing to be not just a testing technique but also a test empowering technique – we may also soon reach a point where manual testing is restricted to just the bare minimum and the tester’s human element is inevitable – for example, specific areas of non-functional testing such as accessibility, usability and the like. If we were to ensure scalability and maintainability of test automation keeping in mind the varied uses of test automation, simplicity is that one key that cannot be ignored anymore. Frameworks that support simple test cases design, English like readable scripts, scripts that can double up to take on more than just the core functional testing are all becoming the need of the day.
The test automation engineer who is able to accommodate these in his framework design will certainly stand out as an engineer with a cut above the rest, as he is one who thinks not just about completing a certain % of test automation, but is truly looking at building automation that is usable by one and all, and that which helps truly gauge the quality of the product under test.