Last three days I’ve spent in a beautiful city in the centre of Poland – Łódź. I travelled there for 3 days of workshop with Michael Bolton. This was organized by this same people, who run a Testing Cup competition & conference. I’ve been following Michael for some time already and yet I found out that reading is sometimes not enough for the information to stay in my head. Some things just need examples and some explanation.
I even attended a meetup with him. I was so impressed by the way he decided to run this. He simply asked us “What do You want to do this evening?” And this part You can see for Yourself – it contains the famous rap!
It is absolutely impossible for me to share with You all the testing knowledge provided to us during those 3 days. It was simply too much. I strongly believe that my brain might have a few days of delay in processing the information due to overload. I feel like it was jump-started with electrical current 😉 It was great to meet Michael in person and to talk with him even about some personal stuff like planning a visit to Kanada. I believe he has a tremendous amount of knowledge to share, and he did his best to share it with us. I honestly believe, that in a month or so I will discover something more in his materials, but for now I would like to share with You 3 most important things I’ve learned and want to use more since today:
I need to befriend heuristics
For a long time, the only oracle that existed for me was a User Story, Specification or other written requirement. One of the first things we did during RST workshop was digging into “the little gods in our heads, who are telling us that something is wrong”.
It is a common practice to assign ‘expected result’ to our defects. Michael did not like it, because what it means? Expected by whom and on what basis? It might be a specification, but it never tells us everything and often it may as well contain errors. And there is a time for heuristics to step up. In one sentence: heuristics are the tools we have to recognise a problem. And they are:
- Consistency (with itself)
- Compatible software
- Claims (like marketing)
- User desire
- Familiar problem
- Standards & regulations
I’ve already had a little example of that in my project. Client asked for a new report in the system. His requirements were incosistent with the behaviour of other reports in our system. We raised a question if this it indeed how they want this report to stand out with the information about broken consistency of the behaviour. As it turned out it was not their intention.
I strongly believe, that testing is mostly about what we have in our heads 🙂 Skills and knowledge will come with time, but what is truly important is our mindset. One of the messages from Michael was: include curiosity. And while it sounds easy in our line of work this curiosity is often hard and take a ugly form like “Hey, what is in this deep, dark, bloody cellar that You have hidden under a carpet?”. But this approach result in discovery. Discovery leads to investigation. All this result in learning – and testing is a synonym of learning.
Moreover, I’ve really appreciated what Michael said: “We should have a shard state of feeling about the product with a stakeholder”. Again sometimes it might be hard, especially when we have a different background. The solution is – question things You assumed to know. And by question I mean ask around or make a research. Asking Yourself deep in Your heart might not be enough.
Right now I am in the process of thinking how this could be applied to the recruitment process. RST workshops had many great exercises, I need to think about them and verify if they can be used.
Find out problems
Time for a few hard questions: What is our purpose? What client expect of us? For a long time, I thought it was “To provide the information about the state of software”. There is the next level of this answer: “To find and inform about the problems”. This changes a perspective a bit, as “give information” is a broader term than “inform about problems”. Not bugs, not defects, but problems. A problem might be that we do not know enough. A problem might be that we have the unstable environment or that error logging does not exist. There are many problems and they should be reported just as we report defects in the software itself.
Break the rules
I know, there were supposed to be 3 points. But somewhere on the way of my career, I forgot how good it feels to question status quo. How amazing it is to break some rules and sometimes fight so they will be removed. And in fact, this is the most important lesson (for me) from Rapid Software Testing. Be a rebel tester: be brave, go where others are afraid to go, do things other did not dream to do, as forbidden or forgotten questions. It is so fun!