I had a SpeakEasy coaching session with my latest aspiring speaker. He is inspiring me in the process.
He used to be a teacher before he started his work on software and testing. So it feels kind of natural he wants to talk about learning.
Our little chat on his talk idea lead me to think more about learning, and in particular, learning to learn. Surely there's techniques that bring structure to learning and make it easier. But there was a particular aspect he did not really directly mention that I think is really relevant: the speed of learning.
We need to build the skill to learn in small batches.
He mentioned a few examples of things he has needed to learn as he became a tester. They're big things like performance testing and BDD - in the sense of including also better communication with a difficult customer. But all this learning really is built up a day at a time.
This made me think of an old job of mine, where I was making of a case of how stupid it felt that they were forcing (encouraging, some might say - with an option of layoffs) some non-programmer testers to move into automation. I remember pointing out numerous times that we actually ended up with previously productive people (they were good exploratory testers, who found relevant bugs we were fixing) turned into students and working in a box that did not enable the same results. I still feel what we did in that organization was a wasted time. But I missed a reframe of the problem that could have made a difference, that I only thought today.
If the learning and retraining could have been done in small batches instead of this all-consuming learning effort with poor results in many ways, things could have been completely different.
A main skill I feel I've been developing as a tester by profession is ability to work and be productive without knowing all. I don't need to do full research to start testing - I learn in layers. Instead of using all allocated time before deadline into research and learning, I research a little, try it out and research some more.
Whenever I hear that it takes months for a new employee to provide any value to the new company, I wonder why my experience is so different. I usually find bugs with the new company's software within the first week - or even the first day. And my learning of the product never ends - there's so many layers I did not know of when I started at Granlund 4 years ago, and I just keep learning more about our product.
Testing is learning about the product and sharing the information effectively. And there's a lot of other skills/knowledge that is useful in that, including performance testing and BDD.
He used to be a teacher before he started his work on software and testing. So it feels kind of natural he wants to talk about learning.
Our little chat on his talk idea lead me to think more about learning, and in particular, learning to learn. Surely there's techniques that bring structure to learning and make it easier. But there was a particular aspect he did not really directly mention that I think is really relevant: the speed of learning.
We need to build the skill to learn in small batches.
He mentioned a few examples of things he has needed to learn as he became a tester. They're big things like performance testing and BDD - in the sense of including also better communication with a difficult customer. But all this learning really is built up a day at a time.
This made me think of an old job of mine, where I was making of a case of how stupid it felt that they were forcing (encouraging, some might say - with an option of layoffs) some non-programmer testers to move into automation. I remember pointing out numerous times that we actually ended up with previously productive people (they were good exploratory testers, who found relevant bugs we were fixing) turned into students and working in a box that did not enable the same results. I still feel what we did in that organization was a wasted time. But I missed a reframe of the problem that could have made a difference, that I only thought today.
If the learning and retraining could have been done in small batches instead of this all-consuming learning effort with poor results in many ways, things could have been completely different.
A main skill I feel I've been developing as a tester by profession is ability to work and be productive without knowing all. I don't need to do full research to start testing - I learn in layers. Instead of using all allocated time before deadline into research and learning, I research a little, try it out and research some more.
Whenever I hear that it takes months for a new employee to provide any value to the new company, I wonder why my experience is so different. I usually find bugs with the new company's software within the first week - or even the first day. And my learning of the product never ends - there's so many layers I did not know of when I started at Granlund 4 years ago, and I just keep learning more about our product.
Testing is learning about the product and sharing the information effectively. And there's a lot of other skills/knowledge that is useful in that, including performance testing and BDD.
