Automation is often couched in the terms of tools and test automation. Christin Wiedemann thinks we need to look at this whole automation thing differently.
I've long been a believer that people put themselves into a box when they say they are good or not good at test automation. Part of the problem is that many people don't give themselves credit for the automation they do every day.have you written a script to run a sequence of commands, so you don't have to type them all the time. Guess what? You're automating.at it's core, that's really what automation is, it's a way to get sequential steps to run in the order you want, without you personally having to enter those commands. Everything else is an order of magnitude from that concept.
One of the biggest issues with automation is "waste". Yes, automation efforts can be every bit as wasteful as the manual efforts and waste they are hoping to replace. Too often, we emphasize the coding aspect of the endeavor, without really looking at all of the other elements that contribute to that.
Have we ever stopped to think about how silly the term "Automated Tester" sounds? What is an Automated Tester? is it a cyborg? A machine? When this term is being used, we really mean "a tester who is proficient at writing software test automation", but it also points to a bias and an attitude we need to think about. We want to automate testing... why? We want to get people out of the equation... again, why? I know what I often say is that I want to get the "busywork" out of the way, so that I can save my eyes and my attention for the really interesting stuff, or the areas that have not been explored yet.
We don't build code, we build a product. In that sense, every one of us in the engineering and delivery process is a developer. Yes, testers are developers, even if we may not be programmers (and again, more of you do more programming than you give yourselves credit for). There are many areas that automation will struggle to be of a benefit to, though each year it narrows the current gaps. Automation does offer some tremendous benefits when you need repeatability, or when you want to parallelize work. Running fifty tests on fifty different machines is a real plus for time. Setting up machines and getting them to an interesting state is also very time consuming, and there is a place where I wholeheartedly welcome automation. Time to market can influence a need for automation, but make no mistake, automation takes time and resources. It may set us up for a later time saving, but it will be expensive up front. That's not a criticism, but it is a reality check ;).
When we say "we want to replace manual testing with automation", what are we actually saying? How will we do it? What is the method we will employ? When will we do it? How long will it take? What's the most important areas to cover? If we can't quantify these questions, we will have a really hard time putting together a successful implementation.
There are a lot of myths around automation. It will save us time. It will save us money. It will get us to market faster. Can those ideals come to fruition? Sure, but probably not right away. In fact, at the beginning of an automation effort, you may go in the red on all of these areas before you get any sustainable benefits. Make no mistake, I am not a luddite decrying automation, I use it daily and I love using it. Deploying releases would be murderous without it. Setting up my development environment by hand would take a lot of time. Serially running tests can sap even the most energetic. Still, there's a lot that goes into creating automation, and there's a lot of work that needs to happen up front before any automation can happen. St the moment, systems cannot invent tests automatically (though there are some algorithms that can create dynamic test branches that on the surface look like they are creating tests out of thin air, but even there, it's based on known knowns). When we deal with new development and features, there needs to be thinking and planning and experimentation (exploring) while the programming is happening and, we hope, while unit tests are being written.
One thought I would say before we discuss the obvious (that is, coding) is that anyone involved in automation needs to know how to design repeatable, reliable and informative tests. I have met excellent programmers who struggle with designing good tests, and I've met people who can develop great tests but struggle with the coding part. Solution: get those two people together. Put that chocolate into the peanut butter (you may have to be my age to get that reference ;) ). Test automation requires planning, preparation, creation, execution, analysis, and reporting. All of those need to be considered and developed, and news flash, the automation programmer may not be the person best suited to perform all of those tasks :).
Christin makes the case that automation can be helped by developing personas, not so much for developing tests, but to determine what skills contribute to the process and who might have those skills. Personas go beyond a laundry list of attributes, it humanizes them and helps us see who can be helpful for each part of the journey. Remember, our goal here is to maximize the possibility our efforts will be successful, and to do that, it would help a lot to get as many people involved in it as possible, and leveraging the skills they bring to the table.
No comments:
Post a Comment