Automation actions is a tactic. It should not be a ritual.
Trying to prove the importance of unit and integration testing, as I described in the last article, I came across the mind-blowing "context-driven approach" about using automation in testing.
This article is intended to review the paper in my own way. But even after reading it several times I am still learning and really feeling inspired after completing each and every paragraph. So please give yourself the pleasure of a cup of coffee, a calm corner and read it entirely.
?? In fact the main idea is about dealing differently with automation in testing. The right questions to ask are not what to automate in testing, how, using which tools and when?
Instead, and as testing is a problem solving challenge, you should be asking what could possibly make the product fail? and how to discover it before our clients do?
?? Asking the right questions lead to meaningful yet surprising answers. During this intellectual process you may find some tools useful, absolutely you will, as the programmer and the researcher among others do. But make the process lead the use of "tools" not the other way round.
?? "Testing is a part of the creative and critical work that happens in the design studio", it includes "learning about a product, questioning, study, modeling, observation and inference, etc."
It is far more than simply checking. But even during checking an unskilled junior tester may find out, in minutes, more unexpected behaviors than the script designed in hours by a very skilled "technical tester".
?? But here is the deal in making tools servants instead of being difficult masters, if your already do, put it the comments:
- Make sure tools are driven by the context, by the need, not by the trend. Let them serve you to produce test data, configure the product or test environments, parse output logs, determine test coverage...
- Invest in tools that give you more freedom in more situations: that support many purposes, are inexpensive, require more human engagement, supported my a large community, useful to non-specialists...
- Invest in testability to increase the possibility for those tools to control products and observe their states and outputs.
?? Finally, the authors provided 3 scenarios for testing a small editing software:
- Using tools without checking
- Checking supported by tools via patterned data generation
- And fully automated checking
The authors concluded "we found bugs...but not because we automated the check" they even claim "...automating the check had little to do with finding and investigating these bugs ... it didn't save us any time... In this case so far , the automated check is a cost without benefit" ??
My point is this: thinking about automation from a different perspective can save you time, energy, resources, and save you from useless troubles.
It can inspire you to employ brand new tools in creative ways. It was always the case when people ask mind-blowing questions, and have unusual mindset against intellectual challenges.
But guess what? It can make you stand out from the crowd... you the context-driven, value-driven, unusual thinking "tester"...
Put a comment on how you use automation in your testing missions and see you in the next article ??