![]() The more experience you have, the more mistakes you’ve (hopefully) already learned from, and the more appropriate your automation implementation will be. 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. As such, we need sufficient programming acumen to create an automation endeavor that is both audience appropriate and maintainable. ![]() In order to create automation, we need to develop software because automation is a software development activity. If we need advanced programming skills to maintain our automation, we may have over complicated it. That said, rarely do you need a computer science degree or be a seasoned software developer to maintain automation. In general, some amount of programming is required to be able to perform maintenance in an automation system. ![]() It can also be as complex as debugging, modifying, and testing automation code. Maintenance can be as simple as changing the automation’s configuration to run against a different test environment. 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. Or perhaps is just a training issue this is an issues can usually be solved relatively easily. If only a small group of people are capable of using the tool, we probably have an unacceptable bottleneck. 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. We still have to know our jobs and our product domains. 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. 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. By execute, I don’t mean clicking a button and emailing results to someone. The basic automation skill is that of executing automation. I like to think of automation acumen in terms of nested circles like the ones below. In each of the two audience types, there will be different levels of automation acumen. I wrote previously about the automation audience both here and here. 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 usually interpret this as “I don’t know how to program so I can’t do automation”. 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. 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. ![]() “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 an internet riff on a refrain Star Trek fans have heard many times in various episodes.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |