I have seen many testers blog about. To do a god testing job you need to know your context. You need to know it that good that your almost able to predict it’s future. You need to know it so god that you are a part of the context yourself.
Bruce Lee had his own way to express that:
Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot, it becomes the teapot. Now, water can flow or it can crash. Be water, my friend.
Sometimes you must find a way that you don’t know where it will lead or where it will end. Looking for software bugs that no one knows of is always a challenge. To find them, new methods from “other worlds” can sometimes be useful.
In his book, “On Writing: A Memoir of the Craft”, Stephen King shares some of his experiences of writing and how he have developed as an author. One of the things he writes about is when he starts to write a new story, he doesn’t know how it will end. He puts a character in a specific situation and begins to think how this character would react in this situation.
What if a famous writes crashed his car during a snow storm in the middle of nowhere? What if the the person who find him there would be an obsessed fan of him and his books? What if this obsessed fan would take him home without telling anyone else, how would the story evolve from there?
This What-if thought was the start of the novel Misesy. When King started to write the book he had anticipated another end than in the final novel. During the process of writing he got to know his characters better and got a feeling of what they would do. He started to think, this is not the way the author would react when realizing he had been kidnapped in the middle of nowhere.
What if a software tester created a story like this before starting to test? How would the testing evolve from there? The story could be something like:
What if an old-school administrator close to retirement was forced on this new report system by his boss? What if he had a badly written manual? What would he do from there?
What if David Developer had had a stressful morning and a hard time to sleep? What if David also had two other projects to commit to, what would happen to this new feature he just committed to be ready for test?
One thing is to start the story. The next step is to get to know the characters so well that the end of the story will present itself. Hopefully, for the future users of the application, this ending will be a happy ending.
I read an interesting article this week and I would like to share some parts of it with you.
At best, styles are merely parts dissected from a unitary whole. All styles require adjustment, partiality, denials, condemnation and a lot of self-justification. The solutions they purport to provide are the very cause of the problem, because they limit and interfere with our natural growth and obstruct the way to genuine understanding. Divisive by nature, styles keep men ‘apart’ from each other rather than ‘unite’ them.
Prolonged repetitious drillings will certainly yield mechanical precision and security of that kind comes from any routine. However, it is exactly this kind of “selective” security or “crutch” which limits or blocks the total growth of a Software Tester. In fact, quite a few practitioners develop such a liking for and dependence on their “crutch” that they can no longer walk without it. Thus, anyone special technique, however cleverly designed is actually a hindrance.
Let it be understood once and for all that I have NOT invented a new style, composite, or modification. I have in no way set Context-Driven Testing within a distinct form governed by laws that distinguish it from “this” style or “that” method. On the contrary, I hope to free my comrades from bondage to styles, patterns and doctrines.
At this point you may ask, “How do I gain this knowledge?” That you will have to find out all by yourself. You must accept the fact that there is in help but self-help. For the same reason I cannot tell you how to “gain” freedom, since freedom exists within you. I cannot tell you what ‘not’ to do, I cannot tell you what you ‘should’ do, since that would be confining you to a particular approach. Formulas can only inhibit freedom, externally dictated prescriptions only squelch creativity and assure mediocrity. Bear in mind that the freedom that accrues from self-knowledge cannot be acquired through strict adherence to a formula; we do not suddenly “become” free, we simply “are” free.
This could have been quoted from an article about Context-Driven Testing. This could have been written by a software tester, I don’t know who, maybe James Bach or Michael Bolton. This could have been written last month. But it wasn’t.
This article was originally published in September 1971 in the “Black belt Magazine”. The name of the article was “Liberate Yourself From Classical Karate” and the author of the article was Bruce Lee.
Bruce Lee was very Context Driven in his own fields of expertise. He questioned old truths and Exploratory Tested the field of Martial Art to find ways and philosophies to guide him in every single context.
In the quote above I change the original word “martial artist” to “software tester”. I also changed the original word “Jeet Kune Do” to “Context-Driven Testing”. Besides that, the quote is all the words of Bruce Lee himself. I will come back to him and his philosophy in this blog in future postings. If Bruce Lee had lived today, and if Bruce Lee had chosen another path in his life, he could have been a great Star in the world of Software Testing.
When you are eight years old you still have a lot of new things to see and a lot of new things to get exited about. When I was eight, I discovered something new. I discovered the world of video games. I remember this day, right after Christmas. My friend who lived just down the street had just showed me his new Christmas gift. And then we started to explore the world of Super Mario Bros.
Inspired by Rikard Edgren’s text about using everyday analogies and compare them with testing I started thinking about this. To me, exploring the world of Super Mario is much like exploring bugs and features of a new product.
According to Wikipedia, the objective of the game is to race through the Mushroom Kingdom, survive the main antagonist Bowser’s forces and save Princess Toadstool. There are many ways to do this. You can go “by the book” and go through the game world by world (Step by step). Or you can look for the hidden short cuts, find warp pipes to go under ground or ladders to take you up in the sky. Nowadays, you find out about the short cuts on the Internet. Back then, you had to find them yourself. Or you had to have a friend that could show them to you.
Along the way there are bonuses to find to help you get to your objective. Bricks marked with question marks contain coins, mushrooms or flowers that helps you in your quest. Some of them are easy to find. You can find them just by looking at the screen or by reading the “requirements”. Others are invisible to the eye and you have no clue that they exist before you stumble on them. At least you have no clue when starting to play. When you have played for a while you get to know the game world and you start to see patterns. This could be a place for a hidden world, and this could be a place for a short cut and if I jump from this spot I might find a hidden coin.
Finding bugs is much the same quest. Some are very obvious to the eye. Other are hidden and you will have to explore the product, you will have to get to know the world of the product and you may need a little bit of luck to find that bug that might be important to fix. To find and fix that bug just to keep the customer satisfied.
Through many years there have been a common solution to handle situations where we seem to not have full control. The solution have been to create more rules, rigid rules, rules that can help us define a level of “well, we did’t get exaclty what we wanted but at least we got something that we planned for”. Through many years people have seen the limitations of creating rules but still this have been a way to keep things under (some sort of) control and therefor the rules have been coming and coming…
Just having seen Barry Schwartz do a Tedtalk about Practical Wisdom in our society I see resemblance to discussions going on about the different schools of testing and the pro’s and con’s of scripted testing.
Practical Wisdom was a term cretated by Aristotele describing the ability to do the right thing when different vitues conflict with each other. What is most important? To find as many bugs as possible or to complete all planned test cases? Barry sees wisdom as composed by two different components. One is moral skill, the ability to figure out what is called for in a given situation. The other is moral will, the desire to do the right thing.
A tester having a lot of moral skill but not the will would go for the solution that looks best to others, maybe the one that follow the rules and cover ones back. A practical tester would see what would be best in the given situation. To get deep knowledge of some weak areas of the product (finding bugs). Or to get wide knowledge of the whole product (complete all test cases) to base a product decision on. All situations do not call for the same solution.
Learn more about Practical Wisdom
When talking about parenting the danish psychologist Bent Hougaard created the term “Curling Parent” to describe one of those parents who always try to sweep the way of their child. This word has been used both in a good way, describing a parent helping their child to reach their goals. This word has also been used in a bad way, describing a parent doing too much which stops their child to learn how to do things their own way.
A couple of years ago, I worked in a project with lot of interacting systems. All developers did a great job developing their own system. When we started to do end-to-end-testing between the interacting systems we found bugs that could not have been found by looking at the systems one by one, which was what the developers had been doing. Starting as a joke, we created the word “Curling Tester”. The word kind of stuck. I still like the metaphor of the tester sweeping the way for the developer, helping the developer to come closer and closer to the target.
Comparing with the “Curling Parent” we must be careful not to do too much sweeping, then we may end up seeing developers putting a lot of stones into play without control and we then not only have to sweep but also have to watch our legs not to get swept away our selves.
The developer still has to put the stone into play with good precision aiming at the target. And the tester continues to sweep, getting the stone the last few inches closer to target. Keeping the customers satisfied. Helping developers to become heroes. Together with us.