• Services
    • Digital Development
    • Quality Engineering & Assurance
    • Cloud Migration
    • Strategy
    • Experience Design
    • Data
  • Process
  • Thinking
  • Join Us
    • Careers
    • Culture
    • Events
  • Work
    • Success Stories
    • Industries
    • Partnerships
    • Technologies
  • Contact
  • Facebook
  • Twitter
  • LinkedIn
  • Google+
  • RSS Feed

Terms & ConditionsPrivacy PolicySitemap

Magenic
menu
  • Services
  • Process
  • Work
  • Contact

Darn It Jim, I'm a Tester, Not an Automater

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.

Categories // Quality Assurance
Tags // Automation , Programming , Testing
SHARE:
THE LATEST:
  • FEBRUARY 12, 2019 // blog
    Maybe My Mom Wasn’t Right – A Dirty Room for Automation
  • FEBRUARY 8, 2019 // blog
    Security In Five Bi-Weekly Roundup – 2/8/19
  • FEBRUARY 8, 2019 // blog
    Automation Execution – Here There Everywhere
Featured Content:
  • White Paper
    Stay Ahead of the Curve: App Dev Trends Coming In 2019

related Posts

FEBRUARY 12, 2019 // Quality Assurance // Blog

Maybe My Mom Wasn’t Right – A Dirty Room for Automation

FEBRUARY 8, 2019 // Quality Assurance // Blog

Automation Execution – Here There Everywhere

NOVEMBER 6, 2018 // Quality Assurance // Blog

Pop Quiz, Hotshot. Is It Automated?

SEPTEMBER 4, 2018 // Quality Assurance // Blog

Have It Your Way: Hamburger Automation Comes With A Price

Contact Us

For more than 20 years, Magenic has helped some of the world’s best and biggest companies create innovative digital products quickly and seamlessly.

We move fast, look forward and collaborate with clients to get them to market sooner. Find out how we can help you Fast Forward to success.

This field is required
This field is required
This field is required
This field is required

Thanks for Contacting Magenic

One of our experts will be contacting you directly within the next business day.

Return To Home
Magenic

info@magenic.com+1.877.277.1044

  • Facebook
  • Twitter
  • LinkedIn
  • Google+
  • RSS Feed

© Magenic Inc.Privacy PolicyTerms & ConditionsSitemap