Testing should not be a roadblock

Consider Uber. Its service is challenging traditional markets for taxis all over the world. Love it or hate it, it is disruptive. And similar things are happening across industry sectors. In particular, customer facing applications are rapidly evolving, with companies adopting cloud-first (or, more broadly, continuous delivery) development cycles whereby new releases come out every quarter. They don’t have lots of new features in each release – they are incremental – but they rapidly accumulate new features and functionality. This is the world you live in and the old “we’ll outsource development because it is cheap” model no longer works except perhaps for some back-office applications. Thus, for many applications, time to market and speed of delivery is crucial. However, that can’t be at the expense of bugs and functions that don’t work, so proper testing still needs to be done, but it needs to be done in such a way that does not slow down release cycles.

How do you achieve this? One answer would be to hire more testers. A lot more. An alternative would be to make existing testers more productive. We recommend the latter, but how is it to be accomplished? This isn’t a complex question – the answer to making workers more productive has been the same for more than 200 years – you make workers more productive by giving them tools that help them work more efficiently. Specifically, it is tools that help to automate some or all manual processes – whether it’s the Spinning Jenny or the production line – that enable improved productivity. In the case of testing: test automation frameworks.

In effect, testers should be the operators of test automation tools: leaving the routine tasks of identifying what test cases need to be run, the generation of the relevant test scripts and so forth, to be handled by the automation software. Testers then become like DBAs: they are managing the testing environment, resolving any issues that arise, focusing on high level problems where genuine expertise is required, liaising with developers and users, and so on. This is how we envision the future, but we are not there yet. While test automation framework vendors are now truly attempting to grasp the automation nettle in a holistic way, fully functional, fully integrated product solutions are not available yet, so there will be a gradual evolution for testers which will give them time to adapt and to learn new skills. We do, however, believe that the day of the traditional tester is numbered: not just because the technology is emerging to automate many testing tasks, but because the market requires application delivery in timescales that simply can’t be met through traditional manual testing.