Ok, my original start could have caused unnecessary trouble, in the worst case gotten me to lose my job so I have to keep my openness in check. It was just a whine about how good people are kept from being good testers. With some flavour of course... :)
Even now in this assignment I'm surrounded by very smart people, capable of doing great things, but incapacitated by all the waste. And I hope I could help them as Michael Bolton (not the singer!) helped me in his Rapid Software Testing (RST) course...
And that, ladies and gentlement, is our wobbly donkey bridge to today's topic: heuristics!
RST course introduced these beautiful things to me, even though the concept is as old as the mountains. Heuristic, according to Wikipedia, refers to experience-based techniques for problem solving, learning, and discovery. Heuristic methods are used to speed up the process of finding a satisfactory solution, where an exhaustive search is impractical. And that's how heuristics are tied to software testing!
The more you know about testing the more you understand that it's infinite. A software that takes fifteen minutes to code can take endless amount of time and effort to test (Google: "testing triangles"). Endless amount of inputs/outputs, states, functionalities and their dependencies, environments, development techniques, rapidly changing requirements from every direction, stated and implied needs and quality criteria, different developer/tester mindsets, etc. etc. etc. *pant*
In the very same RST course we got this disk mapper software to test. At first it seemed like a simple software for analyzing computer drives and files, but very fast it came clear to me that the task was overwhelming. I familiarized myself to different file systems, filetypes, etc. and did a very stupid (i.e. no subleties like APIs, networks, etc.) calculation for all the combinations between file systems and types, and came up with over 38 quintillion (30 zeros) things to test!! And that's just on functional level without any dependencies!!! *pant*
The more you know about testing the more you understand that it's infinite.
Remember that.
 |
| Genius at work |
Ok, tester - as any other worker - has bad days. Tester might have slept poorly, caught a cold, be hung over, have problems at home, etc. There can be numerous things that might set tester's mind off balance. Professionals tackle this by honing their worst performance to be good enough. One of my musician friends said: "You're only as good as you're at your worst." There a many techniques to control your effort and making checklist is one of the most used ones. Writing tasks down and executing them accordingly is an effective way of controlling work flow ever if you're feeling bit off, detached from your mind.
But there's a downside to this...
We might want to control everything via these lists. We outsource our thinking to these lists and our mind becomes lazy. And a lazy mind equals stupid. According to Von Manstein's matrix, there are two kinds of stupid; There's lazy and stupid, who is pretty harmless, not doing anything, producing zero, and then there's hard working and stupid, the most dangerous one of all, the one who messes everything up and produces only minus, which then occupies smart people and prevents them from producing plus. By using exhaustive checklists you either attract or create this both kind of audience.
Checklists should not be used for outsourcing our thinking. Make sure that you and your brain are in charge.
 |
| QC admin? |
When Gordon Ramsay makes food, million things go through his head and he just throws everything together, no measurements, no nothing, just quality all over. "Remember salt! Passed!"
When Sidney Crosby - when healthy - tries to score a goal, million things go through his head and he just does it, better than anyone else aroung him. "Don't get hurt! Failed!"
When Liam Howlett composes another smash hit tune, million things go through his head and he just starts making sounds until something marvellous comes out. "Copy Lady Gaga song patterns! No run!"
When Steve Jobs decides to be number one in the most competitive industry in the world, even 38 quintillion doesn't quite cover the amount of things going through his head. Ok, he definitely had check lists and other pragmatics, but I doubt that his success happened because of those. "Beat Nokia! Passed!" ;)
They might have checklists, but not exhaustive ones, and their use varies greatly. Not to mention, they are superstars with their superhuman capabilities of handling massive amount of variables in an instant. Embodiments of talent. And even though our industry sorely needs it, talent doesn't grow on trees. We need mechanisms for common people to utilize our thinking, and talent that we all have in some level. That's how we get back on track to heuristics and planning/controlling testing through them. About time, because I was once again drifting dangerously into jibber-jabber... ;)
I've always used mindmaps to map my thoughts. Whether it's my test planning, my withered book projects, my attempts to compose music, etc. I've always tried to dissect my thoughts into something tangible, into bits and pieces that could be used in more generic fashion in different areas. I lack a lot of skills that would make this efficient so I haven't had any actual results on behaving like this. Not until this beforementioned RST course...
The course gave me structure through heuristics. Mr. Bolton introduced several different kinds of them. For instance heuristic CRUSSPIC STMPL concentrates on quality criteria in very similar fashion than ISO9126. The letters come from Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility, Supportability, Testability, Maintainability, Portability, Localizability. So it's basically a checklist, covering different areas of quality that need to be covered by quality assurance and testing as a part of it. For instance a Master Test Plan having these words as chapters isn't half bad. There are other heuristics covering areas like Project Environments (team building, sources of information, tools, etc.), Product Elements (functions, data, platforms, etc.) and of course Test Techniques, which I think is the most fashinating part as it gives the most to individual tester. There are tips and tricks how to break software; Functions, domains, scenarios, etc. and they can be complemented with teachings from ISTQB and TMap (data combinations, process cycles, decision tables, etc.), basic tricks like boundary value analysis and equivalence partitioning, vast amount of user input variations, exloratory testing tours/chapters/mission statements, and of course more psychological approach via Six Thinking Hats. I've gathered quite an array of these tips and tricks, but the more I gather them, the more I feel that I'm just in the beginning of this learning process. As the softwares we test can be endlessly complex and give an endless amount of things to test, there's also an endless amount of means to break software, and that I find extremely motivating.
I aim to put everything I know about testing into that mindmap. I have instant access it via Dropbox so I can update it as more ideas come into my head. The structure might change, some ideas might prove useless, etc. and then I just adapt. It's important to put everything in it and after that pick the ones that can be used. It's easier to pick from a vast amount ideas than to come up with them when you need them. We have this saying in Finland: "Ei kukko käskien laula", which means something like you cannot make rooster to sing and this is exactly how creativity should be dealt with; When it starts to sing, make sure you're there to hear it.
As my mindmap is still a baby, it's still quite the monster that contains more information than I can hold in my head. However the more I stare at it, the more my actions become fluent in testing, the better tester I become, the more it contacts me with my thoughts and aids me in my everyday work. It grows from my competence and my competence grows from it. If we really get deep now, it gives a promise of something greater; The Truth about testing...
Whoa! What happened there?! I woke up and all these lines of text had appeared!
Hopefully you're still with me, and prepared for more... ;)
Ok, unfortunately the mindmap is personal and contains a lot of information that's tied to several NDAs. I'm however more than willing to show selected parts from it that won't get me into trouble in this blog, in professional get-togethers, seminars and of course trainings as I kick that into high gear again some day. There's a screenshot of it's root level attached. I tried to come up with my own heuristic, a set of letters, but propably the best way to describe it is Japanese kanji string of the word "universe"...
Whoa, still in the zone!
But how I use it? Is it really any good?
It's a big problem/possibility in our field that there are no standardized methods. There are no agreed way of doing things, and I assume there never will be because there are just too many entities trying to get monetary gain from all this; New processes, methods, tools, etc. sprout every time someone conceptualizes, packages and sells a bundle of ideas. Even this mindmap and RST hype are a part of this, but fortunately a good part, perhaps the best one yet. Until something better sprouts.
Ok, as there are no agreed way of doing things, different companies have different kinds of processes, methods, tools, etc. and all I have to do is to pick something from my mindmap, adapt it to dominant environment and gradually bring in more if possible. The key is to sense how much of it can be deployed and what parts are more important than others, because as such it's an overkill and would demoralize everyone. I don't care if release ever happens, as long as it's represents the highest quality possible, but those with the money might not think that way.
And there's one more upside to it; Even though I'm in the most mind-numbing assignment possible, I can always stare at my mindmap and wonder to a world where testing is a joy... :)
I've planned on writing a blog post about how to utilize the mindmap or parts of it as a case example, but hey... I like this high level visioning more. ;)
Ok, one thing before the quote...
Often testing is considered done when a pre-planned list of test cases is executed. And by now you should understand this is madness. It's creates nothing but unnecessary hurry, which is in the most cases the main reason for the lack of quality. Few paragraphs ago I mentioned about seeking perfection. And that, seeking perfection, is totally ok. But first understand that A) it's infinite B) it takes a lifetime to chase and C) you'll never achieve it (see: A). It's like dog chasing cars or physicist chasing the boundaries of our universe. The chase is the thrill also in testing, not the goal. The goal should be finding bugs, preventing them by inventing more ways for development to develop verification robots/automation and giving information about the persisting risks. That's all. Testing might stop because of deadlines, showstopper bugs, missing environment or even because test team has become ineffective i.e. cannot do it's three main tasks. There are number of reasons why testing might stop, but getting to the end of some test case list is not one of them!!
In our home, outer hallway, we have this picture of a snail crossing a green meadow. The snail takes it's time, enjoys the travel, eats few leaves, sleeps, wonders the world and slowly progresses. It has no specific goal, no intention of reaching the edge of this beautiful meadow. It just enjoys the journey and that's all there is to it. That picture greatly motivates me in my career and in my life.
It might help you to think what you're doing.
Quote time! Finally! Our quote today is from a genious known for fiddling around with impossible amount of thoughts in his head and applying them with deadly precision. Ok, in 1996 he was neutered by a machine - a possible future for many testers too :) - but still, he's one of the thought leaders of our time.
"We like to think." -Garry KasparovYours truly,
"QC Sami" Söderblom
Nice blog to read
ReplyDeletehow to read product dimensions