From the Blogosphere
Manual vs. Testing: Getting the Balance Right By @JustinRohrman | @DevOpsSummit #DevOps
Some companies are eliminating the tester role in favor of tools smiths with programming experience
By: SmartBear Blog
Sep. 19, 2015 10:00 AM
Manual vs. Testing: Getting the Balance Right
The world of software is completely crazy about automation. Thanks perhaps to DevOps, if anything, the mania is increasing. Some companies are eliminating the tester role in favor of tools smiths with programming experience who can build frameworks; sometimes this is called "developer productivity." The language these companies use is one of replacement; of dropping humans in favor of the machine.
I'd like to suggest a different language: The language of compliment, where we recognize that testing and programming are different, that Automation solves certain types of problems and creates others. For the best outcome, we need both.
Let's start by covering how testing and automation are different.
In science and in software, testing is a different beast. When I am testing software, I'm performing experiments in a piece of software and carefully observing. Testing, then, is a performance, something done with skill - that includes not only the design of these experiments, but learning and altering our plan based on the results of the last test. Domain testing, for example, is a good way to discover information about the types of data that might or might not work for a variable. Often though, the most important information is discovered somehow with luck.
Often, I'll find myself exploring some aspect of a feature and notice something interesting. That ‘something interesting' helps me form ideas about what is happening under a set of conditions and guides my decisions about what to do next.
Testing is all about exploration, observation, learning about your surroundings, and making decisions and judgment about your experience.
Here is an example that you might see when automating a user interface:
Navigate to ebay.com
Log in with $user and $password
Assert you are returned to ebay.com
Assert text ("Hello " + $firstname + " !") is displayed
Every time you see the word Assert in that example means that a check will be performed. The tool must compare and decide with a yes, or no to the questions "Was I returned to ebay.com" and "Am I being greeted on the home page after logging in". Checks look precisely at the things you identify and they completely ignore everything else. A check doesn't observe, explore, learn, or judge. It just returns a confirmation that the condition you expected was met, or not.
Sometimes, we try to recreate this checking action by using check lists and very detailed test cases.
Repeatability usually also makes it unlikely to find new information about the product.
Brian Marick describes this through the idea of a mine field. Imagine there is a mine field laid out before you, the kind that blows up when you step on a certain spot. You don't know where the mines are right now, and there are only a couple of very specific paths you can take. When you take these paths, you find a couple of the mines and remove them (hopefully without getting blown up). Each time you take that path after the first, you aren't very likely to find a mine in the same spots again.
People are pretty bad at repeating steps precisely. When I was working for a company that relied heavily on detailed test scripts, I had a constantly wondering eye and mind even though the mission was to follow the script and try to be robot-like. This need to deviate is a good thing. Going off the script when appropriate means exposing yourself to new information.
The minefield idea supports the idea that people should be exploring and testing to discover new information in addition to repeatable checks being run to confirm what we think we know.
There are also plenty of techniques beyond quick attacks that take a more detailed analysis of the requirements, platform, and sometimes code. These "other end of the spectrum" techniques require time to design, special data conditions, and often setup conditions before we can run the test and get results.
Automated Checks require a great deal of set-up time by themselves; someone has to write code or at least record and inspect with a tool. I'd dare say that the absolute fastest you can go from idea to information with a check is close to the slowest you get with a human test. After the checks are created, assuming you want to run them more than one time, you will have to worry about keeping them in sync with and running against your product. Using tools to create checks is often like creating a software project in parallel to the one you are selling.
Occasionally, I see tool-aided testing used as a reason to reduce or get rid of all together the test department. If you aren't spending a lot of time refactoring into a component architecture where you can turn features on and off quickly, and creating elaborate monitoring systems to notice when something is going wrong, a check heavy strategy probably isn't for you. Even if you are, context matters and there are plenty, life critical systems for example, where I wouldn't take the risk.
You'll notice the subtle idea of substitution wormed its way into the conversation again here. It's powerful. But I think we can do better. If a test requires a great deal of setup that can be scripted, and we want to run it many times, then we can do that in code, or with a tool - making the re-run cheap. We can also use the check to drive us to an interesting place - two users that have identical names, for example, or to edit a page while we are trying to edit it ourselves, testing for concurrency issues. Michael Larsen calls this "Taxi Cab Testing"; that the script drives us to an interesting place faster than a human can, then we jump out and test.
Black swans events surprise us. They seem obvious in hindsight but are hard to predict up front. Things that we could not have imagined, like a storm knocking out the power to Amazon's main data center or worse, a tsunami wave following a major earthquake creating a nuclear disaster, can have a massive impact.
Checks that run repeatedly ask the same questions over and over. They'll be unable to find black swans almost by definition. Testing is a strategy for putting people in a position to discover black swans, sometimes on purpose. Things get a little complicated here. Checks can be embedded inside of a test. What that means, is that a check can be run and then a person can use the results of that check to learn something interesting and go off and investigate - like our Taxi Cab example. So, even though the check can't discover a big important problem, a person reviewing the results of that check might get the information they need to discover the problem.
How to Talk About This
Checks might help these people to some degree, but on their own are only answering yes or no to simple questions.
Choose your strategy carefully.
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week