Applying Six Thinking Hats to Let’s Test Conference

Recently I’ve been listening a lot of videos, while driving to work, and back from work to home. Among tens of videos I’ve listened, one has rose above others. That video is Julian Harty’s talk from StarWest 2008. The title of the talk is “Six Thinking Hats for Software Testers” and you can watch it here. It’s good to know, that the talk is based on Edward de Bono’s book about Six Thinking Hats.

Wikipedia describes the underlying principle like this:

The premise of the method is that the human brain thinks in a number of distinct ways which can be deliberately challenged, and hence planned for use in a structured way allowing one to develop tactics for thinking about particular issues.

De Bono identifies six distinct directions in which the brain can be challenged. In each of these directions the brain will identify and bring into conscious thought certain aspects of issues being considered (e.g. gut instinct, pessimistic judgement, neutral facts).

So, you have six hats, which all have different colors, that represent different directions in which the brain can be challenged. It’s good to open up a bit these directions (taken from Wikipedia article, that was referred earlier):

• Information: (White) – considering purely what information is available, what are the facts?
• Emotions (Red) – intuitive or instinctive gut reactions or statements of emotional feeling (but not any justification)
• Discernment (Black) – logic applied to identifying reasons to be cautious and conservative
• Optimistic response (Yellow) – logic applied to identifying benefits, seeking harmony
• Creativity (Green) – statements of provocation and investigation, seeing where a thought goes

You probably noticed, that there is only five directions here. The sixth one is Blue:

Sequences always begin and end with a blue hat; the group agrees together how they will think, then they do the thinking, then they evaluate the outcomes of that thinking and what they should do next.

In his talk, Julian Harty recommended starting also with the Blue hat, then moving on to Yellow, White, Black and Red hats. After those came the Green hat, and finally Blue hat was used for deciding what you should do next.

I’ve listened several times Julian’s talk and wanted to try the method myself. As I am going to Let’s Test conference next week, I thought I could try to apply the Six Thinking Hats to it. I haven’t read the book, so this might be inconsistent with book.

Let’s apply Six Thinking Hats to Let’s Test Conference

• Testing conference for Context Driven testers.
• A lot of sessions, tutorials and Test Lab activity. Lots of prioritizing.
• A lot of skillful and passionate testers.
• Aiming at giving us opportunities to learn from each other.
• A bit isolated location, that gives us more opportunities to confer with each other.

• Meeting a lot of new people.
• Becoming a better tester.
• Learning new skills (e.g. test reporting, python, systems thinking)
• Enjoying the venue.
• Being afterward more part of the Context Driven Testing community.
• I will be seen as a good tester.
• People remember me afterwards.
• Gaining more understanding of Context Driven Testing.

• Excitement.
• Scared.
• Happiness.
• Friendship.
• Socializing.
• Sadness (when it’s over).
• Opportunity to grow.

• 3 days
• 3 keynotes
• 28 sessions (possible to participate 7 of them, will miss 21 of them)
• 13 tutorials (possible to participate 1 or 2 of them, will miss 11 or 12 of them)
• 33 speakers (from which I know in some level – mainly twitter and blogs – 24)
• 16 hours 40 minutes (sessions, tutorials and keynotes)
• XX hours XX minutes Test Lab (done during evening activities?)
• 2 hours 45 minutes in total (breaks)
• 3 hours (lunches)
• 4 hours (dinners)
• 4 hours (evening activities)
• 7 hours (bar and music)
• In total:  37 hours 25 minutes + sleeping time + registration + welcome + morning remarks
• Time to sleep 8 hours, if going to sleep 01:30am

• I will stress too much and become sick, and miss the whole conference.
• I will drink too much beer and become “that guy who drank to much beer”
• I will realize, that majority of the people on the conference are bunch of idiots
• People think I’m an idiot.
• I will not learn anything.
• Because of poor notes, I will forget most of the information about the conference.
• I will make a fool out of myself, by participating into discussions I have no clue about.
• Weather will be awful.
• I will focus too much on sessions, talks, tutorials, test lab and therefore miss all the conferring.
• I will focus too much on conferring and miss all the sessions, talks, tutorials and test lab.

• Gain information about those 21 sessions and 12 tutorials I will miss. Like changing notes, taking pictures of other people’s notes, asking from people about the sessions or reading blogs afterwards.
• Combine notes with the slides, that are likely published later on.
• Instead of discussing with people, I will only listen.
• Use the voice recorder (mobile phone app), where appropriate, and useful.
• Notes will be taken automatically (Wishful Thinking)
• I will learn to know everyone, that is attending the conference (Wishful Thinking)
• Afterwards I can easily return to notes about discussions I’ve had in Let’s Test (Wishful Thinking)

• Don’t stress too much about the conference. Believe in yourself, and consider it more like a place, where you will meet friends.
• Take notes, but also reserve time for just listening. Ask in advance if you can get a copy of someone else’s notes, from a session you’re only listening. Consider using a voice recorder, but make sure, that everyone agrees with it.
• Use a lot opportunities to introduce yourself to others. Don’t let interesting conversations end without knowing, who you were talking with.
• Store all the notes, links and additional material to for example Evernote, or DropBox.
• Talk about the conference for your colleagues. This way you need to go through the notes, and you will gain more understanding about the the topic you will talk about.
• Write a blog post after the conference and try to provide value with it to others. Like concentrate only on conferring or Test Lab.
• There’s lots of time reserved for breaks, lunches and dinners. Use those for learning to know people, and discussing about testing.
• Apply things, that you’ve learned at work. Try at least one thing from every session you attended.

Conclusion

Six Thinking Hats can be a powerful method for generating ideas about difficult problems. I found it useful for approaching a problem. I would assume, that involving people with high variety in thinking styles, boosts the outcome of the method. On the other hand it seems to work well on its own.

I need to read the book, to gain more understanding about the method. Otherwise I will definitely use it on the future to testing related problems, and for that matter any problems I will find it being useful.

I also encourage you to try it, and if you have tried it already, let me know your thoughts.

Visibility of Our Work

It’s been a while from my previous blog post. I’ve been busy with my current project which is actually my first as a consultant. This means that I’m learning all the time a lot and my thoughts around testing are evolving. When I activated on studying testing on March, 2012, I had a clear goal of becoming a software testing expert. Since then I’ve been for example on BBST Foundation and Rapid Software Testing courses. My knowledge about testing has increased hugely from what it was one year ago. I have though run into a problem. The problem is the visibility of our work. In other words, to whom and how much should we transfer our knowledge as testers?

Testing provides information

Image via (Marco Bellucci – Flickr)

I like the idea of testing providing information. It sounds natural for my current context that does not have any outside pressure affecting the way we test our system. Reporting bugs is the common way of delivering my knowledge about the system, but I can do more. At least I am trying to come up with different ways of being more valuable as a tester in my project. Basically that means thinking of to whom and how I could give information about the system I test. This can mean informing developers about the condition of the release or providing my opinion about the state of the system to product owner. Both are something that I have done in my current project.

With information comes responsibility

The information itself is rarely valuable to us only so we have to share it. I’ve experienced moments when filing every bug would have damaged a lot my relationship with the developers. James Bach has talked about Sympathetic Testing on his blog and how that is most often a way to start when facing highly unstable product. In other words not putting too much pressure on the product but more like trying to find out what it can do instead of what it can’t do.

Image via (fresh_photo – Flickr)

So we have to consider what information we provide and when. Especially this is highlighted when you are sharing information about your understanding to people that do not necessarily understand testing. These people might be for example from upper management or product owners. I reported some time ago my opinion about the overall status of the system I was testing. So, basically I just had to describe how I see the status of the system from tester’s perspective. I reported my opinion to several people across the project in one email and I had to make an extra note about how my opinion should not be viewed as final truth. That is why I think we should remember the impact that our information sharing can create. We are responsible for our words and should remember this all the time we talk about our opinion about the system under testing.

When we understand our responsibility we can make a change

The information we have about the system is by no means the truth. It is fallible and biased, but still a result of thought process that is often valuable to stakeholders. When we understand these aspects of our testing – and remember our responsibility toward our information sharing – we can share our knowledge in a way that will benefit the project more than solely relying on bug reports could achieve.

Image via (ForestWander – Flickr)

I also believe that in information sharing and visibility of our work lies the answer to changing the public opinion about testing. The better we evolve in explaining what we do, what we have found out or what we are about to do, the more people see the effort we have put to become a skilled tester. This requires though improving our way of explaining problems, clarifying our messages and treating for example every email or document as one that can be forwarded to any stakeholder on a project. I’ve seen the benefit in this when I have put a bit more effort in explaining things as simply and professionally as I can. And when my explanations are bouncing across the project, I can rest assure that it’s piece of my work like any other testing artifact I have produced (e.g. notes, bug reports).

What, Who and How

I do believe – based on my short experience – that the information we reveal via testing can be shared in various useful ways, but the challenge and my original problem is the ‘What, Who and How‘. What do we share (e.g. overall opinion about the system, opinion about a specific feature or functionality)? Who do we share (e.g. all the stakeholders, development team, upper management, product owner)? How do we share (e.g. email, mind map, meeting)? This is also one of those matters that is highly affected by the context, so there is no “One size fits all” -answer for this.

I will continue experimenting with the ‘What, Who and How’ -problem. I also hope I will be able to create conversation around this subject as it’s a lot linked to test reporting itself. Both are my main themes for year 2013 and if everything goes well, at the end of the year I can write “Part 2” post for this one with more wisdom behind it.

Three Days of Kobayashi Maru

Belongs to http://en.memory-alpha.org/wiki/Kobayashi_Maru

Those of you that have not watched Star Trek, are not probably familiar with Kobayashi Maru. Wikipedia defines it like this

It is a Starfleet training exercise designed to test the character of cadets in the command track at Starfleet Academy.

Rescuing the civilian vessel Kobayashi Maru is the notional primary goal in a simulated battle with the Klingons. The disabled ship is located in the Klingon Neutral Zone, and any Starfleet ship entering the zone would be in violation of the Organian Peace Treaty.

The approaching cadet crew must decide whether or not to attempt rescue of the Kobayashi Maru crew – endangering their own ship and lives – or leave the Kobayashi Maru to certain destruction.

Overall you will be put into a situation where you have – seemingly – no-win scenario ahead of you. Test will test how you will handle the situation. As there is no one right solution and you are under pressure, your actions will reveal your weaknesses (and strengths).

My personal Kobayashi Maru (a.k.a. Rapid Software Testing -course)

Last week I spent three days at Rapid Software Testing -course held by James Bach at Helsinki. After the course I realized that the course was like Kobayashi Maru. Lots of different challenging tests that had us go through situations that didn’t have one right solution. We didn’t have to sacrifice our crews, but we had to figure out how we can test our products as well as we can with our given resources.

The tests (or challenges) also revealed a lot about ourselves. At least it did in my case. I was lucky to have some sort of reputation which led to James knowing me in advance. This on the other hand led to me being given more challenges than perhaps anyone else on the course. Someone might see this as a negative side, but I thought (and still do) I was privileged to participate to those. So what did those challenges reveal about myself? At least these things:

• I can control myself rather well when being questioned and criticized (to certain degree)
• Even under pressure I can solve problems
• I’m able to listen other peoples suggestions (by colleagues for example) about solving the problem
• I need to have deeper knowledge of testing techniques (in a level that is available even under pressure)
• I have a habit of forgetting details under pressure so I need to make sure I have resources that help me coping with my weaknesses (e.g. screen recording and notes)
• I need more experience of different testing problems
• I need to create (or find) heuristics that help me perform under pressure and when dealing unfamiliar subject
• I especially need to develop my ability to ask questions that help me perform the task given (this is related to previous one)
• I need to stop making assumptions! (About things that matter)

Assumptions

Photo by Jacob Bøtter. Used under the Creative Commons license.

If there is one thing I want to raise out of the course, that is definitely making assumptions. The problem that I faced again, again and again during my challenges.

I kept thinking about it and especially why I ended up in that assumption trap several times.   First I realized that when we are under pressure, we are not thinking logically always about the situation. I mean stopping for a minute and think what we are being asked of. The challenges that I was given – and face in my job on daily basis – ask me to solve something. Before you can move into solving the tasks, you need to be rather confident about the fact that you have understood the given assignment as the one who gave it understands it.

If someone asks you to “test this door”, you need to be sure that the door you are going to test is the one you were being asked to test to. Secondly you want know what the person who asked you to test the door really wants. What sort of information is he interested of? Does he want that through that door needs to be accessed 24 hours 7 days a week? Or that it is enough secure to keep people from breaking in? If you just jump into testing the door, you will make assumptions on the purpose of your testing and the needs of the person asking for the testing.

In the end assumptions are a tempting and easy way of doing your job. It’s so tempting to just go with your assumption instead of having the trouble of asking the questions that will test your assumption. But as testers it is our responsibility to test our assumptions. Because if we don’t do that, who will? How can we held our heads high and look back with confidence if we haven’t saw trouble of testing our assumptions? Think about it the next time you discover you have been following an assumption that led you into trouble. What question should you have asked and what point?

Impossible is possible

McFadden, Strauss, Eddy & Irwin (public relations firm) for Desilu Productions.

Wikipedia tells about James T. Kirk’s attempts to beat the Kobayashi Maru:

James T. Kirk‘s back-story defines that he took the test three times while at Starfleet Academy. Prior to his third attempt, Kirk surreptitiously reprogrammed the simulator so that it was possible to rescue the freighter.

This fact finally comes out in Star Trek II: The Wrath of Khan, as Kirk, Saavik and others appear marooned, near death. Saavik’s response is, “Then you never faced that situation…faced death.” Kirk replies, “I don’t believe in the no-win scenario.” Despite having cheated, Kirk had been awarded a commendation for “original thinking.”

Kirk doesn’t believe in no-win scenario and therefore he will find a way to solve a problem, no matter what. As a tester I want piece of that mentality. We have to respect the laws and act ethically, but otherwise there is a lot room for creativity and bending the rules. Even as simple as asking the programmer if he can provide us a logging functionality for a product. An act that can help our testing a lot but is not an option for several people. Or they don’t see it as an option (“it’s impossible” / “he will never do that!”).

During the RST-course I had several moments where I did not use all my resources. I was too busy trying to figure out the solution inside my head. When instead I should have considered how I can get the answer without figuring it from scratch myself? Who has the information? Who can help me? Asking for help is not sign of weakness (to a certain degree). Not being able to ask for help IS a sign of weakness.

I also gave too much respect on my thoughts about what I can do and can’t do. Who is stopping you to do whatever you prefer (with respect to laws and ethics) to solve the problem in hand? And if you are being stopped, at least you have tried and learned something.

De-Focus!

Last thing I wanted to mention from the course is de-focusing. I’ve found it to be rather powerful technique for varying your testing. First of all frustration is the emotion that

Creative Commons Attribution

triggers de-focusing. When you are frustrated and don’t see progress in your testing, you rely on de-focusing. Find pattern in your previous tests and then violate that pattern as much as you can. Prefer MFAT (Multiple Factors At a Time) and vary your observations as well. Observe for sections that you previously did not. Imagination is the limit here.

I witnessed several times during the course that de-focusing helped to solve a problem and will use it on my work also. It can be as simple as using random numbers or help of a colleague, but breaking the pattern is the point.

Few words about James Bach

I’d like to end my post by saying few words about James Bach. I had heard a lot of things about James and knew his reputation as an aggressive and difficult person. At least that’s the impression I had. Before the course started I had a hunch though that James can’t be as bad as his reputation is. I mean, who would hire him as a consultant?

And my hunch was correct. I felt that James was probably the best teacher I’ve had. Amazing amount of knowledge and experience of our field and also entertaining, but demanding style of teaching. I talk about teaching, but he actually enabled me to learn. I had my hard times on being pressured by him but accepted it as a way to learn more. And, boy did I learn. Still have those moments of hard questioning by him clear in my mind. Because of those experiences I was able to find immediately after the course few critical bugs in my current project.

I hope I’ll meet James again at Let’s Test 2013 along with all the other great testers. All these people like James show me the journey I still have ahead of me as a tester, but also motivate me to surpass them.

Interested in books?

It’s been a while.

After finishing BBST Foundations -course I’ve been reading a lot. First I finished the beta version of Elisabeth Hendrickson’s new book: ‘Explore it!’. After that came ‘Perfect Software: And Other Illusions about Testing’ by Gerald M. Weinberg. Now I’m reading ‘Lessons Learned in Software Testing’ which is written by Cem Kaner, James Bach and Bret Pettichord. One of the main reasons why I’m reading in quick pace books now, is that I’m participating Rapid Software Testing -course in few weeks (23-25th of October) and I want to gain more understanding of context-driven testing. I hope that by gaining more knowledge about it, I will also face things that trouble me and I will have good opportunity to ask about them at the course.

I noticed while reading ‘Lessons Learned in Software Testing’ that there is a lot of interesting book recommendations. They fall under many different categories (e.g. epistemology, negotiation, disciplined exploration or reproducing nonproduciple bugs). While seeing all these recommendations, it came to my mind: “Why don’t I do a mind map of these book recommendations?”. And here it is:

I haven’t reviewed it a lot, so there might be mistakes or few books missing. Also some of the books are under few topics, as their content is fitting more than one topic. Personally I have not read almost any of these books, so there is a lot for me to dive in for. Considering my current Amazon Wishlist – which contains 30 books – reading all of these books will take years. But that’s allright. I’ve got time. This is my career. This is my life.

Ut tensio, sic vis

Preface

British physicist Robert Hooke published Latin anagram in year 1660:

ceiiinosssttuv

No one managed to though figure out what it meant and therefore it took 18 years (1678) until he revealed the solution to it:

Ut tensio, sic vis

Which can be translated as: As the extension, so the force. 

Hooke’s law is a law of elasticity and Britannica for example defines it like this:

For relatively small deformations of an object, the displacement or the size of the deformation is directly proportional to the deforming force or load.

At this point some of you might be wondering why I am explaining the law of elasticity here. The reason is, that I think it is a great methaphor for an online course I just attended. The course is BBST Foundations and it is held by the Association for Software Testing. It lasted one month and I’m still waiting for my final grade (pass/fail) for it.

In my opinion, the course was like a spring. The more I put effort on studying and interaction with other students, the more the course gave back to me (and hopefully to others as well). I can also assure that I was far from reaching the elastic limit of the course.

Via Dolorosa
Before I move on to explaining all the things I loved about the course and what I’ve learned, I want to say few words about the journey and especially how hard it was for me.

Few months ago I tried to google information about this course, and especially the amount of time it will take, but I did not find much specific details about it. Sure I found estimations that said it will take 10-40 hours per week, but those were just numbers to me then. I want to bring up how it was for me and not just numbers, but also pure examples from daily live of mine.

(Photo: Creative Commons / Stuartpilbrow)

I knew that the course would be challenging as I have family (fiancee and less than 2 years old son) and a job that requires, at the moment, early wake ups. I did not still estimate well enough the impact that the course would have on my daily life. Because I did not want it to take away time from my son, I did not do the course when he was awake (09AM-09PM). When you add the fact that I had to get up to work every morning 0445AM, you will notice that there was not much room for the course.

I was fortunate to go with a bus to work as I could do the assignments there. Then I also used the weekend mornings (got up 05AM, when others woke up 09AM) and during evenings when son had gone sleeping. But this took quite a lot of the time away from me and my fiancee, which I found troublesome.

In the end I was sleeping on the average 4-6 hours per night and it started to eat me inside. Actually now that I had first Monday since the course ended, I overslept 4,5 hours this morning and I thought if my body just decided to take the sleep debt I had kept building.

You might be also thinking why I participated to the course. But I can assure you, that it was still worth it. I had such a strict constraints in my life that it made the course more challenging to me than it did for other people. I still believe though that I managed to make it an experience that gave me and others a lot. I feel more capable as a tester now than I did before the course.

Evolution
Previous part went through the pain I had to go through in order to evolve. This part goes through about how I have evolved as a tester because of the BBST Foundations -course.

First of all, BBST Foundations requires you to participate into thinking practical and difficult software testing problems. Besides that it also requires you to participating into discussions about these practical problems. I noticed through the course that participating into the discussions was perhaps the most fruitful way of learning.

This photo belongs to: Smithsonian Astrophysical Observatory

Other thing that strike me on the course, was that there were so many problems and assignments that seemed in first glance rather simple, but after a moment they grew out to be anything but simple. I thought though that it was a sign of a important skill, noticing things. Specifically noticing problems that are hiding behind assumptions.

I also learned how effective diversity can be for facing problems. When there are people with different backgrounds and thinking, you will receive several interesting varying approaches besides your own. George Dinwiddie once tweeted that

The roof don’t leak because the holes in each layer don’t line up with each other.

This came after we asked about ways of managing confirmation bias. He referred to having people with different backgrounds. I noticed that with my own eyes while discussing about difficult problems during the course. Solutions to problems vary as much as the people who you ask them from vary with their backgrounds. But more importantly the opinions about what actually is the problem vary to the same degree. This is the power of diversity.

The course also had five fundamental topics that serve long time as pilars for my knowledge about testing. These were: Information objectives drive the testing mission and strategy – Oracles are heuristic – Coverage is a multidimensional problem – Complete testing is impossible – Measurement is important, but hard. They cover a vast amount of information and I have not yet finished all the material we were either required or recommended during the course. My plan is to do that in the near future. That will take time though as recommended readings included several books.

Summary
I think I could sum up things that I personally learned from the course. I want to though highlight that these learnings are based on my experiences. They might change when time goes on, as I will go through the material again. My learnings are also probably different from other students and even from the learning goals of the course.

Before I list things I learned, I want to mention that I highly recommend the BBST Foundations -course. It will require you to give a lot, but in exhange you will evolve as a tester relatively to the amount of effort you have invested on it.

What I learned from BBST Foundations -course:

• Diversity is a good thing.
• Challenge assumptions.
• Five fundamental topics (Information objectives drive the testing mission and strategy – Oracles are heuristic – Coverage is a multidimensional problem – Complete testing is impossible – Measurement is important, but hard) and vast amount of knowledge under them.
• Interaction and discussion are powerful methods for dealing problems and defining what the problem actually is.
• Facing practical testing problems is mandatory for evolvement as a tester.
• Context defines our testing strategy.
• Express myself in a more effective way and think the content of my writings through outline.
• Testing is never perfect. I am never perfect (nor I should aim at perfection). Outcome is a compromise made under the constraints we have.