Rapid Software Testing

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.

IMG_20180525_172850697

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
  • History
  • Image
  • Claims (like marketing)
  • User desire
  • Familiar problem
  • Purpose
  • Standards & regulations
  • World
  • Explainability

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.

Tester mindset

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!

2 thoughts on “Rapid Software Testing

  1. Regarding heuristics: your phrasing suggests that the list provided by Bolton is exhaustive, while it probably is not. There might be heuristics that do not fall into any item on their list just waiting to be identified. And then, some people might find this list not discrete as well. Either way, this is the list that Bolton and Bach came up with and found useful for them, but people are encouraged to come up with their own lists that fit them better.

    Also, I would recommend reading what Kaner has to say about heuristics: http://kaner.com/?p=190 . He makes some good points.

    Like

    1. Sorry to make that impression! Indeed You are right, that not only this is not the full list of heuristics and moreover they do not always work for everyone.

      For me, this list is helpful to say something meaningful as a problem justification. It helps me dig into reasons why I believe something is a problem. So many thanks for additional reading! I will check this out for sure.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s