Hello Andy!
Great topic! I think asking yourself this puts you on a great path to have your testing side and your technical side collaborate so that you provide the maximum assistance to testers as possible. I apologize and thank you for reading my lengthy reply in advance.
When our organization established a job family (known as a System Test Engineer) for this kind of work, there were some developers already creating and maintaining automation, and some who wanted to try it. At the time, creating automation did not have many constraints so, in my opinion, many developers took advantage of this.
They created lots of automation and a few frameworks. Not all of it was useful to testing teams. Further, those same developers spend way too much time maintaining automation that should have been, in my opinion, more simply implemented. In some cases, the maintenance is all they do just to keep pace with changes to the products that are evaluated with automation. This does not serve testing teams well.
Lastly, some of the developers have little or no background in testing. Without a testing foundation (and some time spent just testing), automation becomes, in my opinion, little more than a technical pursuit to demonstrate technical prowess. Iām usually underwhelmed and decidedly unimpressed with these kinds of efforts.
There are also people who are testers and want to move into the System Test Engineer job family. They must learn, as you have mentioned, some programming in order to work with various tools. They are, in my opinion, more successful because of the testing foundation. They bring a certain economical view to the problem: What is the right number of tests? Is automation the right solution for the problem? This is how they are taught, this is how they have worked, and these questions are profoundly appropriate when considering automation solutions.
Today, this job family is more than automation because testing is more than running tests. System Test Engineers assess product testability and assist Project Test Leads in advocating for testability improvements. System Test Engineers participate early in projects to assess testability, review test environments, and review opportunities for utilities and automation. This assessment also aids the Test Lead in planning the test strategy so the testing team can support the pace of development and maintain high quality.
It required some time to reach this level of participation and collaboration. I invite you to pursue your technical interests and assist testing teams with great automation (APIs are a great place to start!). I challenge you to keep an eye out for test engineering opportunities mentioned above.
You mentioned that you might remediate a little. Cool! I do that also if Iāve been away from a tool or technology. Embrace it! At some point, youāll have examples that you can use and build on.
More importantly, treat every opportunity as an experiment. It doesnāt have to be perfect the first time or even the second time. In the end, your solution has to provide valid results in a timely manner. That might occur somewhere between āgot it workingā and āperfectionā. Perfection, in my experience, costs too much; there is a satisfactory middle ground. If you didnāt like the outcome, make a list of what you would do better and try it on the next project (or next experiment).
How much technical programming knowledge is needed to write automation? You need to understand how to use the basics of programming (e.g., assignment, iteration, decision, input/output, math) to construct solutions. I think it will be important to understand methods of program and data organization (e.g., object oriented design).
Languages will provide their benefits in various flavors of syntax. For example, the introduction of generics in C# is a wild application of the basics and we are all the better for it.
I think you are discovering how much you need for your position or pursuit. When you needed help, MoT and many other resources are available to assist. The lure of having a working program or automation suite pales in comparison to the preparation required to make it useful and maintainable. Research and experimentation has helped me. If the concept is new, I create a sandbox project in Visual Studio and use it help me learn. Things that donāt compile, or that donāt execute correctly are teachers not errors!
Lastly, I encourage you to seek opinions of others. One notable person is Angie Jones (@techgirl1908 on Twitter and MoT) writes and speaks on automation. I especially enjoyed her recent article on automation.
Thanks again!
Joe