I'm reading Cem Kaner's book on Domain testing. Having skimmed though a lot of it, I started again and got stuck with ideas from start of intro.
"Testing is a cognitively complex activity. Developing competence with cognitively complex skills requires mastery of routine tasks and formation of schemas (cognitive maps) that can guide you as you do tasks that require more conscious effort (van Merrienboer, 1997)"
I've dedicated much of my adult life to building these skills and building networks that help me develop these skills. Right now, on my summer vacation I'm putting 20 hours a week for four weeks to a course that teaches one out of hundreds testing techniques - thinking tools. I absolutely love the BBST Domain testing course so far.
Testing is cognitively complex activity. So is coding. But they are different cognitive activities. When I do things, I want to be good - excellent even. With all the effort that learning testing takes, where to find time that coding takes?
The question on my part is really rhetorical. I was forced to take coding classes as part of my MSc studies for computer science. I could do them, but I never felt the urge to do it again or do more of it. Looking back, I wasn't into the things we were supposed to implement and I never felt the same overwhelming feeling of success in a brain-engaged activity that I get with testing, again and again. Recently, I've been giving coding a second chance and with the control of choices learned in testing, it's definitely more fun. But I still don't get the feeling of success that would drive me to depths that testing has.
Creating an algorithm that handles things smartly is somewhat of a boost. But I do that for testing too, to build ideas of what's possible and expectable. I just skip implementing and debugging the idea if I test. I love thinking about the problem and solution, but I lose interest snd have to force myself to complete the details on different layers of logic - the routine tasks of coding. It comforts me a little that I learn while doing, that I see ugly code that just cries to be refactored. That I get reminded that coding is just as much exploration as testing. But it still doesn't give me the feeling that THIS I want, this feeling is totally worth all the effort. It does for some, and I respect their love of code highly. I just feel different.
A lot of the cognitive load on learning coding is like the stuff we now do on the domain testing course. Learning routine ways of doing things that repeat, to free our minds to the non-routine aspects of our work. I notice my routine with coding is off, I need to rely on guides (intellisense) to come up with syntax and I google like crazy to decide what library would already have something useful for my purpose. I don't remember since with choices of time, my practice of coding just isn't on the level I'd like it to be.
With all this, I find the 'testers should code' 'why would a tester not learn to code' a generally upsetting theme. Why should I want to be a mediocre coder when I can be a brilliant tester? Or why should I give up my aims of excellence in testing to learn coding to a level I consider professional?
On my team, most developers suck at testing. I know from a personal experience that the 'can't break own stuff' is mostly just an excuse to avoid work they don't love. As I ask developers to test more, I offer to implement more. Neither gets the things that would make us fully happy, for supposingly greater good.
I just keep wondering if this trend is really smart at all. Let testers learn coding but let them also be non-coders. This direction of emphasis would lead to driving away more good testers. You don't know what you're missing since those who think this is a smart move never paid attention to what the 'business people' do. It's not coding, so it's probably 'less valuable' - as one of my developers put it.
Coding is great. Testing is great. Finding idea-solution-product-market fit and buy-in is great. We need respect for diversity and collaboration more than super-individuals that have these all.
Let my colleagues in test not learn code in peace. Like James Bach said in twitter: not everyone wants kids. Choices and preferences should ne respected, not continuously feeling attacked. If coding is in demand, who should learn and change: those filling the demand (testers who code) or those (mis)identifying the demand (recruiting managers)?
Surely recruiting managers can go ahead and recruit for skills they need. But it just might be that emphasizing one they lose out on what they really need. But since they don't have it, they might not realize to miss it.
"Testing is a cognitively complex activity. Developing competence with cognitively complex skills requires mastery of routine tasks and formation of schemas (cognitive maps) that can guide you as you do tasks that require more conscious effort (van Merrienboer, 1997)"
I've dedicated much of my adult life to building these skills and building networks that help me develop these skills. Right now, on my summer vacation I'm putting 20 hours a week for four weeks to a course that teaches one out of hundreds testing techniques - thinking tools. I absolutely love the BBST Domain testing course so far.
Testing is cognitively complex activity. So is coding. But they are different cognitive activities. When I do things, I want to be good - excellent even. With all the effort that learning testing takes, where to find time that coding takes?
The question on my part is really rhetorical. I was forced to take coding classes as part of my MSc studies for computer science. I could do them, but I never felt the urge to do it again or do more of it. Looking back, I wasn't into the things we were supposed to implement and I never felt the same overwhelming feeling of success in a brain-engaged activity that I get with testing, again and again. Recently, I've been giving coding a second chance and with the control of choices learned in testing, it's definitely more fun. But I still don't get the feeling of success that would drive me to depths that testing has.
Creating an algorithm that handles things smartly is somewhat of a boost. But I do that for testing too, to build ideas of what's possible and expectable. I just skip implementing and debugging the idea if I test. I love thinking about the problem and solution, but I lose interest snd have to force myself to complete the details on different layers of logic - the routine tasks of coding. It comforts me a little that I learn while doing, that I see ugly code that just cries to be refactored. That I get reminded that coding is just as much exploration as testing. But it still doesn't give me the feeling that THIS I want, this feeling is totally worth all the effort. It does for some, and I respect their love of code highly. I just feel different.
A lot of the cognitive load on learning coding is like the stuff we now do on the domain testing course. Learning routine ways of doing things that repeat, to free our minds to the non-routine aspects of our work. I notice my routine with coding is off, I need to rely on guides (intellisense) to come up with syntax and I google like crazy to decide what library would already have something useful for my purpose. I don't remember since with choices of time, my practice of coding just isn't on the level I'd like it to be.
With all this, I find the 'testers should code' 'why would a tester not learn to code' a generally upsetting theme. Why should I want to be a mediocre coder when I can be a brilliant tester? Or why should I give up my aims of excellence in testing to learn coding to a level I consider professional?
On my team, most developers suck at testing. I know from a personal experience that the 'can't break own stuff' is mostly just an excuse to avoid work they don't love. As I ask developers to test more, I offer to implement more. Neither gets the things that would make us fully happy, for supposingly greater good.
I just keep wondering if this trend is really smart at all. Let testers learn coding but let them also be non-coders. This direction of emphasis would lead to driving away more good testers. You don't know what you're missing since those who think this is a smart move never paid attention to what the 'business people' do. It's not coding, so it's probably 'less valuable' - as one of my developers put it.
Coding is great. Testing is great. Finding idea-solution-product-market fit and buy-in is great. We need respect for diversity and collaboration more than super-individuals that have these all.
Let my colleagues in test not learn code in peace. Like James Bach said in twitter: not everyone wants kids. Choices and preferences should ne respected, not continuously feeling attacked. If coding is in demand, who should learn and change: those filling the demand (testers who code) or those (mis)identifying the demand (recruiting managers)?
Surely recruiting managers can go ahead and recruit for skills they need. But it just might be that emphasizing one they lose out on what they really need. But since they don't have it, they might not realize to miss it.
