About six years ago I was in my corner of a four-person cubicle at Lockheed Martin, showing off automation to my colleagues. "Fantastic. This could save us a lot of time. We have to invest more in this!" one said.
"Let me show you how you do it," I said, turning to bring up the code.
But before I could unlock my screen, they were headed back to their corners. "I don't touch that coding stuff. Sorry," they all agreed.
I've met many test engineers who are excellent coders, but I've also seen the above attitude many times (perhaps more often), and come to understand that modern coding is not for everyone. And that's fine. Everyone has something that doesn't quite click with them.
Albert Einstein. Genius. Not good at everything, though .
It's like Einstein and knowing where he was and where he was going. Apparently, that wasn't his forté .
When organizational pressure to automate as much as possible starts to mount, those who never intended to become programmers will understandably push back.
I've seen three responses: 1. Train all test engineers to program, 2. Hire dedicated automation engineers, or 3. Acquire a framework that makes automation easier.
The most influential quotes I found during my research on this subject.The first option usually doesn't turn out so well. Hans Buwalda, the CTO of LogiGear and test engineering author, says, "forcing a nontechnical tester to become a programmer may cause you to lose a good tester and gain a poor programmer."  My experience agrees.
The second and third options tend to be the most viable. But there's something rather enticing about the third option, isn't there? It's a refusal to give up on peoples' ability to automate their own tests. If we could just remove the right barriers, maybe we could open this power up to everyone. If not, then we have more data going forward to help us solve this problem.
Working at Alteryx has led me to believe that many more people can "program" than I ever thought, just not the traditional way (text-based coding). Designer can make life easier for those who have an aptitude for programming. But those who don't still seem to pick it up and write some really impressive logic. Designer seems to remove a barrier from traditional coding that keeps many people from getting good at it. This makes it an intriguing choice for bridging the gap between nontechnical testers and test automation.
So I ask the question, "With Designer, could we open up programming to a wider community than ever before?"
Check out this video to see a short presentation of what we've done to make this happen in the world of automation, followed by a demo.
- "The Test Automation Design Paradox", Hans Buwalda, June 28, 2016 https://www.techwell.com/techwell-insights/2016/06/test-automation-design-paradox-0
- "Experiences of Test Automation: Case Studies of Software Test Automation", Page 5, https://books.google.com/books?hl=en&lr=&id=62pUzABIZSwC&oi=fnd&pg=PR9&dq=software+test+automation&o...
- "Just Enough Software Test Automation",Page 86, 2nd paragraph, https://books.google.com/books?id=PEBvfWESIt4C&lpg=PR15&ots=xIrXWDsoZJ&dq=software%20test%20automati...
- "Is Test Automation the Same as Programming Tests?" http://www.logigear.com/magazine/test-automation/is-test-automation-the-same-as-programming-tests/
- "Creators of Mathematical and Computational Sciences", Page 350, https://books.google.com/books?id=bENTBQAAQBAJ&pg=PA350&lpg=PA350#v=onepage&q&f=false