It's getting to all of us testers. The message that the testers of the future need to be technical. The message that more and more companies set up teams of developers who are also responsible for all the testing is everywhere.
So you find it in yourself, like so many of my close non-programming tester colleagues have, to learn to program. It could be something completely new to you. Or it could be something you stopped doing 15 years ago, because you just found the world of testing from the business and value viewpoint so much more fun. Some of us find the motivation from the negative: feeling the pressure, needing to be 'competitive'. Some of us find the motivation from the positive: curiosity, seeing how that will improve the selection of things I can do with testing.
I find that recently almost every tester I know, including myself, have started taking the steps to become better programmers. On one hand, I'm happy for the turnout. But on other, it might mean that the side of not respecting the value of thinking in testing, at least without self-contained ability to turn that into test automation, has lost the battle.
My curiosity towards the code has lead me to learn that I dislike the stuff I was forced to learn on at school. The algorithms. The mathematical puzzles. The so-called funny little programs that were geeky in the wrong way (like paper-rock-scissors-lizard). I also dislike what automating does to the work of testing that I love so much. I dislike how it transforms my thinking into more procedural, how it forces me to spend time on details when there's so much of the world to see that I have to choose to prioritize out, thinking of long term over short term. I do it, because I believe it's good for our product development. But it makes me want to go work in McDonalds on a regular basis.
Coding from the perspective of solving my own problems is much more fascinating. There's an iPhone app I want to have. I will have it. And I know I need to create it myself. There's the excitement, and I don't mind at all doing great testing (even automated testing) around it.
Could it be that we need to look deeper into our strengths and interests to find what each of us would like to use programming on, instead of thinking that testers are programmers of testing problems? Because with that trend, there will be one tester less - with direct impact on the quality that comes out from our current pipeline.
Another thing on the programming trend that really puzzles me is languages. I'm a strong believer in using the same language for test automation as you use for the rest of your development. If my team works with C# and I bring in python because it's so much better for testing, I will be alone with my code. And I find from experience that bringing in selenium in C#, I get the whole team contributing, and whatever test automation we're doing benefits from the skills of the whole team. The trend still seems to be to look for a language specific to testing, be it a different programming language or vendor-language built into a tool.
For learning, my lesson is this. Pick a language, any language. But pick one that works with problems you find interesting to look into. Pick one where you have people close to you that you can collaborate with. Work with it long enough to get over the starting pains, so that you start to see the structures. Adding more languages when you know one isn't that big a deal. But knowing hello world in 20 languages but nothing deeper isn't that helpful.
So you find it in yourself, like so many of my close non-programming tester colleagues have, to learn to program. It could be something completely new to you. Or it could be something you stopped doing 15 years ago, because you just found the world of testing from the business and value viewpoint so much more fun. Some of us find the motivation from the negative: feeling the pressure, needing to be 'competitive'. Some of us find the motivation from the positive: curiosity, seeing how that will improve the selection of things I can do with testing.
I find that recently almost every tester I know, including myself, have started taking the steps to become better programmers. On one hand, I'm happy for the turnout. But on other, it might mean that the side of not respecting the value of thinking in testing, at least without self-contained ability to turn that into test automation, has lost the battle.
My curiosity towards the code has lead me to learn that I dislike the stuff I was forced to learn on at school. The algorithms. The mathematical puzzles. The so-called funny little programs that were geeky in the wrong way (like paper-rock-scissors-lizard). I also dislike what automating does to the work of testing that I love so much. I dislike how it transforms my thinking into more procedural, how it forces me to spend time on details when there's so much of the world to see that I have to choose to prioritize out, thinking of long term over short term. I do it, because I believe it's good for our product development. But it makes me want to go work in McDonalds on a regular basis.
Coding from the perspective of solving my own problems is much more fascinating. There's an iPhone app I want to have. I will have it. And I know I need to create it myself. There's the excitement, and I don't mind at all doing great testing (even automated testing) around it.
Could it be that we need to look deeper into our strengths and interests to find what each of us would like to use programming on, instead of thinking that testers are programmers of testing problems? Because with that trend, there will be one tester less - with direct impact on the quality that comes out from our current pipeline.
Another thing on the programming trend that really puzzles me is languages. I'm a strong believer in using the same language for test automation as you use for the rest of your development. If my team works with C# and I bring in python because it's so much better for testing, I will be alone with my code. And I find from experience that bringing in selenium in C#, I get the whole team contributing, and whatever test automation we're doing benefits from the skills of the whole team. The trend still seems to be to look for a language specific to testing, be it a different programming language or vendor-language built into a tool.
For learning, my lesson is this. Pick a language, any language. But pick one that works with problems you find interesting to look into. Pick one where you have people close to you that you can collaborate with. Work with it long enough to get over the starting pains, so that you start to see the structures. Adding more languages when you know one isn't that big a deal. But knowing hello world in 20 languages but nothing deeper isn't that helpful.
