Great Expectations from Test Automation

Applications are evolving at an unprecedented pace. Technical innovations are being showcased almost on a routine basis by application developers that take user interaction with web and mobile applications several notches higher. Users expect smooth and intuitive workflows, consistent experience across the range of devices they use and multiple interface touch points (for e.g. APIs, web services) to allow them to integrate the application features with the rest of their technical ecosystem. Developers are more than eager to bring all of these features to users for their consumption. It’s like a win-win for users and the developers. So far so good. But there is one entity that suffers trying to keep pace with this evolution, namely test automation.

Test automation has come a long way from the initial days of record-capture-playback routine. We have a slew of tools that are hogging the limelight in their respective areas like Selenium, Appium, Calabash, Soap UI; and not to mention countless other fantastic licensed as well as open source tools.

 Coming to the present day scenario, a definite set of requirements is emerging that automation has to strive to keep pace with:

1. Shift Left: In the continuous race to extract more from the efforts being spent on quality, testing is gradually being shifted more and more to the left of the development life cycle. Automation naturally has to shift left. More emphasis now needs to be placed in ensuring automation is able to validate the functionality of the core components and methods at unit level, progressing gradually to integration and system. It’s not adequate that automation focuses only on acceptance level scenarios which typically get developed and run once the majority of the development activities have been completed and units have been integrated. The feedback from automation has to come a lot earlier than that.
2. Agile: It is passé to expect automation to run faster. The new normal is to expect your automation process itself to be faster. The speed at which the test scripts get developed is expected to keep pace with the development efforts. Automation scripts are supposed to be ready for execution the moment the feature has been completed. The delta between the feature being complete for testing and for automation to be ready to test it needs to be as less as possible for automation to be considered as agile.
3. Multi-Layer Integration Testing: In their quest to be agile, many teams swear by the Agile Test Pyramid paradigm. This basically says that you need to have lesser tests at the higher levels (user workflows, UI), and more tests at the lower level (middleware followed by unit). This puts enormous pressure on the value that this minimized set of traditional UI test automation is supposed to generate. They need to be exemplary in giving the confidence of their worth. One way to achieve this objective is to make your test scripts richer. Richer in the sense that each script needs to pack in more validation value. It’s not enough to have scripts that focus only on an individual application layer (like UI, middleware, database). The script needs to straddle the layers to get more features tested in one shot.
4. Multiplatform Support: Integration of applications in varied eco-systems is becoming more of a de-facto norm. Every application worth its salt needs to run on multiple platforms/operating systems, multiple devices not to mention a plethora of resolutions and screen sizes. Test automation is expected to handle all of these challenges without a fuss. Talk about adding one more expectation to the already overflowing list!

These are just some of the expectations which automation is supposed to fulfill. For sure automation is getting more and more complex. No two thoughts about it. But that precisely is the reason why test automation is such a fantastic challenge to solve. There are exciting developments happening in the test automation space. Different pieces of the technical puzzle are being solved to address the new ground realities and expectations. We have innovations like automatic generation of page factories (page class libraries) that cut back on the test scripting time, better code abstraction at scripting level to ensure platform agnostic behavior of scripts at execution time, and richer syntactics of expressing test scripts to achieve unified multi-layer testing.

So to all the application developers who are forever bringing in more and more complex interfaces (to test), to the application stakeholders who are increasing the testing footprint and to the product owners who are forever shortening testing cycles, here is what we say – BRING IT ON. Test automation is evolving and will continue to do so to run toe-to-toe with the development’s pace, and even outrun it in the near foreseeable future. Exciting developments are foreseen in this space.