How Pradeep teaches software testing - Part 4

If you didn't know how Part 4 came up? Here is how it came. I first wrote Part 1, then Part 2 and then Part 3 ;-) So, logically here is Part 4 of the series How Pradeep teaches software testing.

"I know how to do certain types of testing but if someone asks me to explain what I did, I struggle to explain" was a problem statement I heard from a tester today. I replied in a confident tone, "I know why that happens. It doesn't just appear to be your problem but I know a lot of testers who appear to have the same problem." 

I continued, "You should consciously practice explaining what you did, first to yourself and then to your colleagues although they probably know how and why you did it. Why? I am going to explain how your brain works (or how I think it does). It has two nodes. One that contains what you know and the other that controls your explanation of what you know. When you make a conscious effort, you are forcing a connection between these nodes in your brain. When you force your brain to connect those two nodes too often, at some point it will judge the need for a permanent connection and create it for you. After that you have a free flow of what you know and your explanation of what you know." 

After I said the above, I could see a smile in the face that reflects, "Yes, I now know how to solve this problem". I read a person's understanding not by their head nodding or when I hear, "I get it", but by the emotions and expressions on their face and the body. 

James Bach identified that I was a metacog. I didn't know I was one. After that, it has been very helpful for me to understand why I do things the way I do. I guess I turned myself into a metacog because I thought it suits the kind of testing I wanted to. It's not a special status, it is just a way of life.

I don't even know if the brain works the way I explained it to be but I guess you can understand why the above explanation makes sense. I make sure I tell people that I am not trying to misinform them about anything when I use such examples. I am just helping the tester imagine why there is a problem and how to solve it. A lot of my coaching is consulting.

Examples like the one you read above govern a major part of my coaching. I observe a lot. I practiced consciously making connections between what I have seen, heard, thought, experienced and know to being explain it when the context demands.

Analogies and Examples are powerful approaches to teaching. I need to know what connects to my audience very well. Although all my audience are testers, I can't use the same analogies and examples, it just doesn't work. Bangalore testers need a different example than those in Pune. In Pune, I would talk about Raj Thackery and in Bangalore I would talk about Vattal Nagraj, in Chennai about Goundamani and not about Vattal Nagraj. Now, for those of my readers from United States or Europe, you wouldn't know Goundamani or Vattal Nagraj and hence I would use examples of Chuck Norris, Sarah Palin, Julian Assange. If you are a F1 fan, I'd talk about testing through specific GP incidents. That's how the examples need to adopt based on audience. I also use a lot of examples from what I think the world connects to. For instance, I closely read and watch Air Crash Investigation in Nat Geo channel. OMG! There is so much to learn from the way NTSB (National Transportation Safety Board) deals with it. So, basically as a coach, I have to keep connecting to various thoughts and happenings to be able to connect with my audience. 

Similes, Metaphor or if you choose to call them Analogies are interesting and tough piece of cake, if you are the one providing it. People tend to take it in their own interpretation than what you intend to. It is good in a way, I get to learn when not to use what type of analogies to what kind of people :)

I use Fishing for explaining test coverage. I know a few other people have already used fishing as an example for teaching testing, so I didn't invent it but I know how to explain different concepts of testing with the fishing example. I think that most learning happens when you are interacting with the audience and not when you are explaining. That's where I do better with the fishing analogy.

I start drawing different types of fish, from guppies to clowns and from star fish to sharks. I then draw a size and shape of a specific type of net to catch fish. I give them a goal of catching as many different fish as possible in a limited amount of time. Some audience come back and tell me, "Ah with this net the guppies will escape"... what's your immediate thought? You would tell them to build a net that has smaller squares to catch guppies?  (Why say it? They know it) I would probably be Pradeep and say, "Fantastic. A lot of time spent celebrating the success of finding one good bug steals away the opportunity to find more good bugs. How do you want to celebrate? 3 minutes left."

So, after they come out with strategy and different nets, I tell people that just because they have nets (tools) to catch a specific type of fish it doesn't mean they can really catch a plenty of it. I then tell a story and examples from my life. One of them: I consulted for an organization who had bought an expensive automation tool hoping that they would now be able to find more bugs. They spent all their energy to set up tests on it and found fewer bugs over the year. I drive points like: Tools don't help you unless you know how to help the tools to do what you think they can.

For a while people think it is possible to catch a shark from a net. It is possible, maybe. I explain how a powerful shark can bring their boat down if they try to catch it through a net or a fishing rod and how a harpoon is better than a net. Sometimes people try to think of similar approaches to solve many different problems. The example of shark, net and harpoons are cool for people to relate to something they have done in the past that shouldn't have been done the way they did it. I then equate different types of fish to different quality criteria. I ask my audience what type of fish are they mostly catching and I hear a shout, "Functionality". 

After a lot of back and forth between me and my audience, we all discover what good test coverage could mean. I then start probing into their projects and figure out how much of fish they are missing that they shouldn't be and try to help them understand why they shouldn't be catching too much of the same fish. Sometimes it upsets the food chain :) 

While there is fishing in my class, there is also plenty of room for Sine and Cosine for Test Techniques, Brian Marick's Minefield Analogy for Regression Test Strategy, Tom and Jerry examples for How Scripted Testing is dangerous, what lessons can we learn from Saurav Ganguly's come back, how to read Sachin and Kambli's career graphs, farming... It must be fun to sit in my class. I don't know, I have never been able to.

Happy New Year!

Truth about test plan document & test case document

Not that you don't know.

Truth About Test Plan Documents

• 98% of test plan documents that are created are not updated, maintained or cared beyond sign off.
• The first 5 pages of a test plan document contains history that doesn't interest even those whose names are mentioned in it.
• Scope of testing section is the most funniest part of the whole document. Some times when testers report serious problems, some people cite it as out of scope. Hey, its still in the product.
• Customers worldwide could have saved millions of dollars if their vendors didn't care about creating test plan documents.
• 4 years into a project, nobody knows about the test plan document.
• No matter how stupid or intelligent the test plan document is, testers still write the test case they want to write.
• As an offshore services company, writing test plan documents are a cool way of billing customers without actually doing testing.
• Every stakeholder feels a false sense of achievement the moment they have a test plan document irrespective of whether they actually have a test plan.
• The cost of reviewing a document that nobody is going to use it is really high.
• Those who think they are not ready to test because the test plan document is not ready aren't testers by any means.
• A simple maintainable test plan document is far superior than a detailed test plan document.
• A mind map is worth a thousand good test plan documents.
• Test Plan Document is a Document, not necessarily a test plan.
• The next time you ask a tester to write a test plan where she knows it is not going to be used or maintained, she is not going to put her heart in it.
• Some test plan documents are written in a way that it is obsolete in its first draft itself.
• Some reviewers of test plan documents aim for perfection. More funny stuff, they may not even know what the product is supposed to do.
• Those who know about opportunity cost are likely to write a better test plan document.

Not that you don't know.

Truth About Test Case Documents

• ~ 90% of testers haven't bothered to think why there is a "case" in "test case".
• For most people on earth, a test case means a test idea that is documented.
• The expected results column in test case documents are a copy paste of requirements document / stories. So much money goes into re-writing the requirements document into expected results column.
• If you are already laughing at test case documentation, you may roar to a bigger laughter at trace ability matrix.
• Most traditional testing services projects have 50% of their project duration spent on writing test cases. The team members in such projects complain unavailability of time to "actually" test the product. No wonder.
• Unless the context demands, detailing a test case is a sin.
• Detailed steps in test case documentation provided for humans to execute is something I personally consider as an act against humanity.
• More than 99% ( yeah, more than 99%) testers I have met have passed a test case (or a bunch of them) without actually executing it. It is so f****** boring.
• Test case documents bring more money to countries like India than what Bill Gates must have invested in setting up an office in that country.
• Those testers who don't know to test without test case documentation aren't testers.
• More than 98% of projects I have consulted in India didn't have testers doing "test design". Here is a way: Take the requirement and write at least two or three tests to "check" if that requirement can be marked a Pass. That is all the design that happens.
• Test case documents are actually "Check case" documents.
• If there wasn't check case documents, software testing as an industry would have attracted more talent and helped in building more passion for the craft.
• Businessmen love test case documentation. Testers hate it. Businessmen hire testers to write documentation. Testers trade their time for money, end up writing documentation for money.
• Test case pass percentage is a great way to fool stakeholders. People love to be fooled.
• I personally can write test case documentation for any buggy product and make it look like a bug free product. 
• If all test case documents created so far were printed and burnt, we'd have fire for the next one thousand years.
• If you rate testers based on how many test cases they write per day, you'd always find people who can meet the number you want them to achieve.
• As someone said, "Testing at its best is, sampling". If you start writing and detailing the samples, you will have fewer samples than what you can have and you will never get to know about the product.
• If X test cases documentation takes Y hours, the amount of time spent on reviewing it and getting to sign off is 10Y. So, if X goes to 10X, we have 100Y hours of work spent on test case documentation.
• Some projects have great test case documents and no time to run them all.
• If you do a lot of documentation, you cant ship software, you can definitely ship documents.
• If you are hiring people who need detailed test scripts to test software, your hiring has ton of bugs in it.
• Those business people who ask testers to write "how long will this test case take to execute" and make estimations of test cycle complete time, should be executed.
• It is about Opportunity cost and Opportunity or Cost.
• No user has ever bought a product because the product was developed with lots of test case documentation.
• 99.999999999% of test case documentation I have seen so far doesn't care what the users really want.
• If testers read 1000000 words in a test case document the first time they were executing, they only read 10000 the next time and 1000 that next time and 100 for the next. Later, they don't need it.
• Some people think test plan document = test case document.
• The service most companies sell is test documentation, not testing.
• All good testers I have met so far, treat other testers as intelligent as they are and don't punish humans with detailed test scripts.
• Test cases don't assure repeatability of testing, at best it assures repeatability of testers getting bored.
• Funny that expected result of a test case should ideally be, "Software should go kaboom" BUT it is mostly, "We should see a boat sailing smooth as the day is bright and clear and the waters are not turbulent".

Just that, I know.

A short post on topic Test is Dead

I know you think I am an expert tester.  I am, safely.

One of the ways in which I remain as an expert tester is by reading what real expert testers are writing about and add my own thoughts to it and thereby making a large population (who don't blog anyway) think I belong to the expert testers league. For over 6 years, I have been successful in fooling many to believe I am an expert tester. I want to take that record further.

For those who don't know the context of Test is Dead, here is a story : Once upon a time some foxes got around a grape yard. They jumped and jumped but could never get hold of the juicy looking grapes. Some grapes that had fallen down due to wind were covered by mud and the foxes poo. One of the foxes ate it and said "Grapes are sour". They started to spread the idea about grapes being sour.

IMO, thankfully, the grapes are sour to those foxes who would have spoiled them if they had access to it.

Scott Barber, Ben Kelly & Matt Heusser has covered a good deal about (those who think) Test is Dead. I wonder if some people reading their blog and then mine might wonder why I didn't write on this topic. As a reader of my blog do you think I have lost expertness factor in testing? No way! Look at the title again, I posted on the topic Test is Dead.