In general I agree and share your thoughts but I am missing a few things here. What I am saying 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. ![]() We still need talented humans to perform that testing. 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. I’m not that person who says “all testers must learn to code”. Those testers an then exploit the provided capabilities. 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. 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. 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. We can further break down the aspects of creation. Additionally, in my opinion, the more experience you have the less important your formal training tends to be for most jobs. 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. |