“Dammit 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 issue that 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 overcomplicated 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 am saying is that just because someone isn’t a developer or doesn’t have a degree in computer science, it doesn’t mean that they can’t participate in an automation endeavor.
Like this? Catch me at an upcoming event!
My favorite “Look, I’m a doctor, not an escalator!” – Friday’s Child.
But otherwise, yeah… good post.
LikeLiked by 1 person
You can further break down the aspects of creation if you use Gherkin or a similar domain-specific language. Then you can have test designers add tests without any serious programming skills, supported by automation engineers who create the fixtures.
LikeLiked by 1 person
I’d like to ask for clarification by what you mean “without any serious programming skills”. We should make sure the people working on automation have a good & solid foundation in programming. Meaning they need to understand how to structure the logic so that it makes sense, and the constructs of that logic. Given-When-Then is a good start, but they also need to understand the If-block structure and looping constructs along with data/variables and functions. Even with a DSL you can get spaghetti code if you’re not careful. And that leads to maintenance problems that can quickly sink any automation implementation.
LikeLiked by 1 person
I mean that the test case implementors aren’t programmers, though they’ll need to use some rudimentary programming concepts. I’m curious to hear more about situations where non-programmers were not successful in using a DSL. I think it depends a lot on how the DSL is designed. I would not include any conditional logic. Looping might be there as part of table-driven actions, but not in any more generic sense than that. I’d like to avoid user-defined variables, though I don’t know if that’s feasible. If you want a general-purpose programming language, use one that already exists rather than a DSL and have programmers write the test cases.
LikeLike