*by a human.
The aim of this article is to help educate testers and their colleagues about the reasoning behind why testers (humans) should not and cannot be replaced by machines. We will also look at the difference between automated testing and testing and how automation can be used to aid us. The implementation of automated testing is out of scope of this article but it will cover some practical principles.
I would like to start by crediting a friend and a colleague, Joshua Gladwin, for contributing to this article, as a qualified Psychologist he has a deep insight into how humans think and the complexity involved in building a machine that can mimic human thinking (artificial intelligence).
If we want to avoid a ‘Skynet’ scenario then let’s Keep It Simple (KISS principle). Test frameworks, tools and machines are all resources intended to help us execute regression tests that we (as testers) have designed.
The reason why testers should not and cannot be replaced entirely by machines is because in today’s world complexity and ambiguity are on the rise — adaptability is the answer, real-time, on demand adaptability to changes that may occur, with context, scenarios and parameters. But who can adapt better: a human or a machine — and why?
You can build a machine that can test given parameters but the machine will not be able to incorporate additional factors without human intervention.
A human by nature is a tester — our basic drive as a species is to test ’cause and effect’ to gain control and make resource allocation as efficient as possible. Throughout evolution we have tested, this goes back to the most basic curiosity of ‘what happens if I touch the fire?’ — as a human we learn from the instant feedback of burning our self and we don’t do it twice, that’s for sure! But you may test the fire with other parameters.Take ‘A+B = ?’ test as an example, a human can adapt a test by adding C, D, E variables into the equation as they test. A machine cannot adapt the test, it can only run the test on the parameters it is given.
Humans can also predict change, take a multitude of factors and risks into account and therefore adapt as necessary. A human can postulate the possibility of X happening and so test for Y just in case. A machine cannot identify risks that it has not been programmed to. Yes, we can build predictive learning machines, but can you build an efficient and adaptable machine that can predict outcomes? A machine may predict X may occur and so might trigger another test incorporating those variables, but this would be inbuilt within the instruction by a human.
We shouldn’t be relying on machines and technology to do the thinking for us but instead use them to aid us in discovering, learning and adapting quickly to changes.
In the last decade alone technology has evolved rapidly and has become more affordable and accessible to the public. This has given way to more possibilities but also increased the speed at which we want things (real time on demand services). Software companies must ensure they deliver excellent quality products as quickly as possible on a multitude of platforms and devices. To meet these demands we can harness the power of distributed or cloud computing, and run automated tests on all the supported platforms and devices required.
Technology can aid us in becoming better testers, we can use it in conjunction with automation in different ways. Like Tony Stark uses his Iron man suit to aid him in dealing with badies (obstacles), we can use automation, tools and machines to aid us in testing. For example, if you need to check that X number of redirects are working, as a human it may take you a while to get through all of them. Instead, you can write a small program that retrieves actual URLs from Excel row A, execute them via e.g. Selenium and compare the result against expected URLs from row B. This program can now be added to your arsenal of tools to aid you in the future.
Lastly, I’d like to suggest to my fellow testers and their colleagues that we refer to automated testing as automated checking to draw a clear line of separation between machines executing a test and a human carrying out testing. I see this as once a tester has developed a test case and executed it, it becomes a check for a machine to execute as part of regression.
As we have seen automated testing is very different to testing done by a human. Automation frees up testers to focus on more complex work that a machine cannot do, however, we can use it to build out an arsenal of tools to aid us in testing.