The week starting with October 26th I attended the courses Rapid Software Testing (3 days) and Rapid Software Testing for Managers (1 day). It was brilliant! I feel I learned so many from both the course material and the trainer James Bach. Further on I’ll detail three things I learned and find valuable, and also mention other things I loved in this course.
What I learned
1) Our job is to not be fooled
When something feels strange, I’d better not ignore it but instead verbalize it, even if I particularly have a “special thing” related to that. I’ll explain. During an exercise with James I felt something was weird: I was given to hold in my hands something very warm. But I thought “Hey, I usually have cold hands, so my senses must be exaggerate, the temperature surely is at normal parameters”. The result was that I dismissed my feelings without even giving them a chance. Well, it appeared that in this case the temperature was actually a hint for something that would have been important to question, as it was the key of the exercise. Analyzing this, I can’t blame myself too much that my past experiences influenced my thinking, as most of the times I was right not to rely on my body temperature sensors. The twist however, is that besides the temperature there were at least two other hints, unrelated to temperature which I dismissed as well. Just like the promotional offers: if you buy the big toothpaste, within the same price you also get a toothbrush. The same happened to me, only that with dismissing hints 🙂
I was fooled. This kind of things happen, and are part of our human nature. Only that the projects we work on would benefit a lot if we could minimize the frequency of being fooled. James put it this way: if even the tester in the project doesn’t get to investigate “the weird”, what are the odds that someone else will? Our job is not to get fooled, and improve the skills to minimize that to happen.
2) Get rid of hesitations in our speech
A few years ago I learned that strategies are not ultimate but rule of thumbs (heuristics), that there are many unknowns, that black swans are not impossible, and that we make assumptions sometimes without even being aware. Since then my perspective shifted to a mindset where certainty became a myth and anything is possible at any time. This had effects on my speech as well. Of course, this is not the only cause that lead to uncertainty in my speech, but had strong influences.
In this course, James’ point of view was to try to get rid of hesitations in our speech. “But”, I thought, “how can I get rid of them if I’m not sure if what I say is applicable? What if a black swan pops in? Maybe if I am unsure, it’s good to transmit that through my speech.” After thinking a while about this I realized that one can be confident in his speech and at the same time talk with confidence about the risks and possibilities of unknown. Hesitations in speech can easily transmit the message “Don’t trust me nor my testing”, when in fact what I, at least, want to transmit is that “I can’t tell you that the product will behave excellently in any possible situation, because I can’t predict any possible situation unless I become a witch with a magic globe. I covered all the scenarios that I thought relevant, here’s what I covered, what I haven’t and why. These are the risks that I see…” And so, I can be confident with saying that, even if I’m not confident on the whole product because of the tests I did not run, information I may have missed, or black swans. Confidence in speech and confidence in the product are not necessarily directly related and can be treated as separate.
However, I think that James’ intention, was not to advise to be confident when we don’t have arguments. Also, ideally it would be nice of people not to dismiss someone’s ideas only due to lack of confidence in their speech, and try to understand the relevancy of the arguments. Unfortunately, it is not easy to do that in every single situation. Each one of us have our moments when we are in a hurry, feel time pressure, did not drink our morning coffee yet, etc. Therefore getting rid of hesitations in our speech when we have arguments is most of the times in our area of control, which helps a great deal to communicate efficiently and build trust.
3) Try harder not to misuse words. They confuse people who don’t practice our job
I was happy to see alternatives to some words I misused, e.g
- I used the word assumption even for inferences. An assumption is a thing that is accepted as true or as certain to happen, without proof. An inference is a conclusion reached on the basis of evidence and reasoning. In many situations I make inferences, not assumptions, but I used the word assumption for both cases.
- I used good practice instead of best practice, as I acknowledge there’s no such thing as best practice that works in every context. Good practice is a milder syntagm, but still, just the same as best practice has the effect of turning off judgement, and people are more likely not to question the practice and therefore not to adjust it to their own context and needs. Wording alternatives are favorite practice (why not admit it’s not something universally applicable as we did not test it for that, but our own favorite), common practice or simply practice.
- I knew that numbers and percentages can be misleading. Numbers, especially Test Cases numbers don’t have the same weight: some take more time to run, some less, some are more efficient and cover more functionality, some less, some require more setup, some less etc. When it comes to thinking in percentages, the idea of 100% implies that we know all possible tests that can be done, but that’s just an illusion, because it’s impossible to test everything. So based on these reasons, I avoided using numbers and percentages in test reports or other types of writing. Sometimes though, I found myself using them in my speech, saying that something is 90% done, when actually what I wanted to say is that I feel good with the coverage so far, but I still have some work to do. It’s interesting how we think we know some things, but still don’t apply them in every situation and context. We need to practice, practice, practice in more and more situations and contexts. James also explained in the course about the “Numbers bias”: usually when we see numbers we think of operations with them like adding, subtracting, multiplying etc. If we express our testing in numbers people will automatically think of doing operations with them to meet deadlines or other constraints, but testing doesn’t work like that. Instead, if we express our testing using colors, labels, words, we’ll bypass this bias. Nobody will try to subtract colors or words, or average them and get misleading metrics.
What I also loved in this course
There were many other things I loved in this course. From James’ vision to encourage choosing, reasoning, being responsible, to the importance of managing stress or being aware that confusion when starting a new project is totally normal. Also the analogies used in this course I found very good. I’ll share some below.
- Real life testing is not clean. It actually is super dirty, like one of those survival shows taking place in a swamp.
- Nobody asks a programmer “Are you a manual or an automated programmer?” And what would be the answer to that? That she’s a manual programmer because she “manually” types at the keyboard?
- A tester’s job is very similar to a scientist’s job. Actually it’s even more difficult because scientists don’t get new builds. I laughed then and still laugh now when I think of James’ joke that in science God doesn’t send an email saying “I’ve been thinking more, and we need to change the way the electrons work. Oh, and don’t forget to do a regression test on photons, to make sure we don’t break anything” : )
- Along with parenting one learns many that can be applied to managing. A child shows you how helpless you are. You can use force with him, but that doesn’t mean he will listen. And as a manager you need to be listened.
- Think of management as a bee swarm. The beekeeper does not control the bees nor where and how they fly. The bees are free to wander the world, from flower to flower. Instead of controlling them, the beekeeper creates the conditions so that bees want to come back at his beehives.
The RST course was a great experience for me, I learned many and acknowledged even more. James is a great storyteller and a very thorough tester. I like that he’s aware of models he uses when he tests, and shares them in ways that are easy to follow and understand. I think that reflecting on the models we use is important, because the models that are in our head control our testing. Perhaps model is not an easy to grasp word, James offered an alternative for it: learning : ). At the end of this blog post, I’d like to share my favorite quote from the course “To be a good tester you need to be an ArTist of your own mind”.