I am a strong believer that the best way to learn something is to try teach it to somebody else, even if this way you risk embarrassing yourself and/or look stupid. That’s why I started the mentoring section of my blog and that’s how my passion to teaching was born.
It’s been a year, so far, since I started being a part-time lecturer in a local academy for software testing, called Pragmatic. It was a great time and I am sure greater stuff are about to happen.
During this one year I came to realize many things that I wasn’t aware of or not sure of. That’s why I decided to share my observations with you, as some of them are only methodical stuff related to teaching testing, while other concern my vision of the craft, in general.
And may be some context on what I do – I am normally giving lectures on topics like:
– exploratory testing – highly underestimated, therefore tons of “stereotype wreckage” to clean up there
– parafunctional testing
– mobile testing
– performance testing
The groups that I teach are normally 25-30 people, all grown ups, rarely students or university grads, normally they are looking to switch to testing from another career or are now junior testers and looking for basic understanding of testing. Rarely I have senior testers, sometimes with longer experience than me.
So, here’s what kind of lessons I learned during this one year.
Teaching testing is harder than you think
Teaching seems like an easy job – you prepare your lessons, some slides, additional materials and then you just talk, talk, talk, over and over again, until you pass out. Well, it doesn’t work like this. And I knew it since the beginning, as I had my fair share of teaching in school, while I was in the university. But yet I faced some interesting challenges.
Your materials are never good enough.
Especially in my case there was probably no 3 consecutive lectures that I gave with the same slides. As any clever tester I try to improve and read new stuff, sometimes I would find interesting article or a book or concept, model, heuristic that I want to include. The challenging part is that I want to include, but not to remove. Therefore I end up with 100 slides for a single lecture.
Useful conclusion that I made out of this is that just as in software development, changes should be incremental, but also resourceful – you can’t simply compress all testing knowledge on a certain topic, in a single lecture. And also, no matter how good a material is, it’s not always a good idea to give it to complete novices as some of them get easily confused.
You can’t just “lecture”
It is called a lecture and yet, lecturing is the worst thing you can do to your students.
Seems that the learning process doesn’t work using the model that all schools and universities use – one speaker who broadcasts like an antenna and a bunch of student “receivers” who have to process it, no matter if they understand what the fuck is he/she talking about. And that’s the reason why education is so fucked up, and many people decide to look for alternative forms of learning. If you are interested in more information about the crisis in education look for Sir Ken Robinson on youtube.
I knew that, I knew also the best way to teach testing is by demonstrating it and letting people experience it. Yet, I tried for more than a half-year to “broadcast” and don’t get me wrong, I am a good “broadcaster”, but it’s boring. My lessons are 3 hours long and it’s so fucking exhaustive to talk for 3 hours. And believe me, no matter how passionate you are, your audience, you included, will get bored by hours of preaching.
The most important lesson that I learned concerned to this was from Jerry Weinberg’s experiential learning series. In essence he uses part of the theory of Jean Piaget – that students are not simply “empty glasses” in which you have to pour knowledge, but rather you have to make them experience and invent what you are talking about by example and facing real world problems. This was a total game changer for the way that I was teaching testing, as it made much more sense to me organizing my lessons like this.
Therefore, I started splitting my lectures in smaller chunks, trying to make them more interactive, include more dialog, asking questions, discussions, sharing of strategies, etc. It really made a difference.
Finding good practice/lab exercises is such a pain in the ass
As mentioned before practice is essential for testing – we can’t teach testers that testing is learned by doing and not ask them to perform testing as part of their studies. It turns out, though, that finding good exercises for testers is a hard thing.
It looks much easier in programming, for example – if you want to teach somebody to write a loop, you ask him to solve some problem with loops. In testing it’s a bit more difficult, normally our job always includes a lot of analysis and thinking, problem solving, creativity and looking for hidden complexity. And all of these are not easily explained within a couple of hours exercise. That’s why many courses use strategies like asking students to write test cases or generate test data, but to create a complete testing strategy is not fast and easy task.
So, what I found out about assessment and exercises in testing, goes like this. You either go standard multiple choice format and make you live easy or you ask for organic, complex problem solving or testing tasks, that require testing skills, not just memorizing and you totally kiss your free time good-bye. 🙂
So, making things right and meaningful is hell of a time-consuming. Every course I get, every time I give homework I spend normally every single night for a week, reviewing and providing feedback to students. And you can say that by the activity in my blog, during the last year. 😀 I don’t say this is the optimal way, but it’s the right way according to my understanding. If you want to make the things work, you have to invest time and treat every single student with respect and personal approach, as every one of them has different way of learning, understanding, solving problems and so on.
And last on the methodology of teaching testing…
The balance between theory and practice
This seems to be an egg and chicken problem. You can’t have one without the other. And there seems to be a thin line of balance and it’s so hard to keep it.
If you keep your lessons strictly theoretical – you get boring, simple as that, nobody would listen to you. And it really doesn’t matter how super star of a tester of speaker you are, teaching is not a conference talk, you are not there to shine. At the end of the day, if there’s no learning happening, you failed miserably.
On the other hand – if you keep your lessons too practical, you end up having students that are confused, frustrated sometimes, intimidated by their lack of knowledge, because they simply don’t know what to do. Not to mention the lack of vocabulary to explain what they’ve done, even if they did it using their “gut feeling”.
So, this is actually unsolvable problem, I guess I will still try and fail until I get the proper solution to it.
Besides the methodology of teaching testing, I also had some interesting observations of how our testing craft is perceived by new comers, based on what they’ve heard or read or got feedback from friends. I believe these are worth sharing, too.
Tons of outdated bullshit wreckage
May be thanks to the “good guys” who sell certification for living – producing Cinderella testers overnight, may be due to the constant drive of people to oversimplify testing by use of tools, standards, verification, test cases and so on, but there is a huge amount of bullshit floating around, related to testing that I have to “filter” from student’s heads, so they don’t turn into useless test case executors.
In case you wonder what that is, may be you should consider taking a look in the what software testing isn’t series. But to summarize, the main problems that I face in novice’s/new comers’ to testing thinking are:
– we are not simply comparing outputs to requirements
– there’s no One tool or One best practice or One approach to “rule them all” in testing
– “we are not manual testers, unless we test manuals” (credit to M.Bolton)
– we don’t simply look for bugs
– testing is not easy
– testing is not an activity, it’s an expertise and it includes a lot of thinking, not simply doing
And so on and so forth. Once you deal with all that confusion, if you ever do it, you can actually step into helping them build their model of what testing is.
The hardest question in testing…
I found out not only by teaching, but also by observing experienced testers talking at conferences and community events and interviews – that one of the hardest questions to discuss and speak about is – what is your current strategy of testing? The moment you ask a tester to get deeper in reviewing his/her strategy and all of its assets, techniques, heuristics, methods, possible risks and people just fall back to some default scenario to oversimplification, relying on tools, metrics and test cases.
Seems to me that many of the testers are afraid or just consider it of low importance to review their approach and self-analyze, which, in my opinion, is wrong. And that’s probably one of the reasons why testing is loosing its value and looked at as easily automate-able, and testers referred to as people simple following steps/scenarios.
In order to defend the value of our craft we shouldn’t be afraid to dive into our strategy and tell the story about it, review it, refute it and build it from scratch, over and over again, if necessary. This is how improvement works.
I hope this article would be of use not only to testers teaching testing as myself, but also to the ones that want to do it, or anyone.
Any form feedback is welcome, any shares and retweets are highly appreciated.
Thanks for reading. 🙂
2 thoughts on “Learning testing by teaching others: one year of lessons”
I love your blog article.
From my opinion and experience, it is a very good summary and has a lot of “truth”.
I remembered many situations and I’ve hoped that I did learn as much as you.
Just that short Feedback is enough, I do not have more for this Moment.