January 25, 2018 // By Paul Grizzaffi
“Darn it Jim, I’m a doctor not a …”
This an internet riff on a refrain Star Trek fans have heard many times in various episodes. “I’m a doctor, not a bricklayer”, “I’m a doctor not an engineer”, etc. Typically, these were Doctor McCoy’s responses to suggestions/orders by Captain Kirk that the good doctor perform some activities that were outside his typical medical purview. This was McCoy’s way of expressing to Kirk that what Kirk was asking him to do was something he believed he was incapable of, or maybe that he just should not be asked to do.
In our testing community, we often hear a similar statement from testers who might relate to McCoy: I’m a tester not a programmer/coder/developer/automator. I usually interpret this as “I don’t know how to program so I can’t do automation”. To that, I tend to play the Kirk-like role and say “so what?” So what if you are not a programmer? It’s my belief that everyone can participate in an automation endeavor.
I wrote previously about the automation audience both here and here. In each of the two audience types, there will be different levels of automation acumen. I like to think of automation acumen in terms of nested circles like the ones below.
The basic automation skill is that of executing automation. By execute, I don’t mean clicking a button and emailing results to someone. I mean running an automation tool that executes logic against a system under test, understanding what the tool is doing, evaluating the results of that tool’s execution, and taking appropriate actions based on the results. In order to do this, some expertise in the system and in the automation tool is necessary; the tool is not doing our jobs, instead, it’s helping us do our jobs. We still have to know our jobs and our product domains.
If we find we are unable to run the tool or take action on its results, we may well have a problem with our tool or how we are using our tool. If only a small group of people are capable of using the tool, we probably have an unacceptable bottleneck. Or perhaps is just a training issue; this is an issues can usually be solved relatively easily.
The ability to maintain our automation is a superset of execution; if we expect to test any of the changes we make to our automation, we need to be able to execute it. Maintenance can be as simple as changing the automation’s configuration to run against a different test environment. It can also be as complex as debugging, modifying, and testing automation code. In general, some amount of programming is required to be able to perform maintenance in an automation system. That said, rarely do you need a computer science degree or be a seasoned software developer to maintain automation. If we need advanced programming skills to maintain our automation, we may have over complicated it.
In order to create automation, we need to develop software because automation is a software development activity. As such, we need sufficient programming acumen to create an automation endeavor that is both audience appropriate and maintainable. There are many ways in which we can acquire this acumen, everything from formal schooling to on the job training; there’s no set, best way to gain this ability. What is key, however, is experience. The more experience you have, the more mistakes you’ve (hopefully) already learned from, and the more appropriate your automation implementation will be. Additionally, in my opinion, the more experience you have the less important your formal training tends to be for most jobs.
We can further break down the aspects of creation. For instance, it generally requires a smaller amount of automation acumen to create and maintain automated scripts than it does to create and maintain an automation tool; think about developing scripts on top of Selenium as opposed to developing Selenium itself. Clearly, a higher level of software development sophistication and experience is required to create a tool like Selenium than to use a tool like Selenium. Some teams will have automation specialists who create tools and frameworks to provide to the team members who have less experience in programming but, perhaps, have a high degree of skill in testing. Those testers an then exploit the provided capabilities.
I’m not that person who says “all testers must learn to code”. I believe in my career-span there will always be some testing challenges that are not automation candidates because they can’t be automated in a valuable way or they can’t be automated at all. We still need talented humans to perform that testing. What I amsaying is that just because someone isn’t a developer or doesn’t have a degree in computer scientist, it doesn’t mean that they can’t participate in an automation endeavor.