Short answer, yes. Long answer:
Firstly, learning programming is not as difficult as expected
Usually people just follow the wrong approach
That’s why I talk about developing the aptitude for algorithm design
Secondly, there are solutions out there recommending automation tools requiring no coding skills
These ‘Scriptless’ automation or keyword automation tools are not ‘sustainable’ and don’t work in the long run
Therefore one needs to learn programming and how to code well
Thirdly, IMHO testers should be ‘Technical’, without knowing what’s going on under the hood, they cannot test well
If you are capable of grasping that much, then learning programming would not be a problem
These topics were discussed in the #PSQC18 conference talk I gave:
#RedefiningSoftwareQuality
I disagree that should be technical to be a tester.
Needing to understand how something works isn’t essential for all testing, otherwise Black Box Testing wouldn’t be a thing. If someone gave me a website to test, with links, input fields, and so on, I could think about how I want to test and then execute those tests, without any understanding of the code that went into building it.
We can test requirements before code is built, challenging decisions that have been made against it, perhaps knowing how something already behaves that the BA might not be aware of.
You don’t have to know the ins and outs of something to decide if something even should be automated. If it will take 5 hours to automate and you only use it for 1 hour per year, will it still be getting ran in 6 years time to break even? Even if its 1 hour per month, will you be using the same thing in 6 months time?
Forcing testers to be technical who don’t want to be turns them into bad developers, not good testers.
I agree with this: “Forcing testers to be technical who don’t want to be turns them into bad developers, not good testers.”
Also that to do ‘any’ testing one should know how the software works, that’s true as well. However without technical knowledge the product cannot be tested ‘completely’. IMHO To do the job well one needs to understand how the technology works and test it from the inside, along with black box testing.
I think the answer is you should understand programming and have the capabilities to do it when needed. In some situations you will need to do a lot of it in order to do your job. Automation in testing is about being able to translate the process (programming) of the test into executable instructions (code) for a machine to run. Automation also means knowing how to get the tool, and language used, to properly connect and interact with the intended target (be it the software directly running on the system, the machine/OS of the system or software/OS of another connected system). Programming is learning how to “speak” in another (sometimes foreign) language aside from your native one. Understanding how to translate and converse in that other language is key.
Regarding “Codeless/Scriptless” tools they are just have an interface that is another extrapolation layer away from the underlying code that does the real work. This can be a commercial tool, or in your own framework using a homegrown Domain Specific Language (DSL) that you train users/tester to use to build a “script”. These tools all utilize a combination of Component and Keyword methods. They provide building blocks to put together to get the job done.
Excellent description about programming for testers Jim, well put. Thank you for adding that.