Peaks are fun, but bit scary

Writer Meta Thoughts.
Last week was definitely a peak in my writing journey. On Sunday, an article of mine was accepted for print by "Testing Experience" magazine. On Tuesday, Pradeep Soundararajan mentioned my name among other "Good thinkers and future experts". I wrote a post on Wednesday, and on Thursday discovered that my site had a record number of visitors. A short investigation led me to the traffic source - The following Tweet by James Bach:
jamesmarcusbach: Another new sapient testing blogger (avoids pat answers, critical self-analysis). I like this guy http://bit.ly/dl042u
Thank you, James!
What a week! No wonder, this week was also my Birthday week. While enjoying the compliments, a concern sneaks into mind - How do I maintain my reputation? The concern fades when I look down the path - remembering the journey I started a year and a half ago, daring to blog my first post and going from there, searching for my inner voice and improving my writing skills. Continuing the journey, looks less scary than taking the first step.
Here's to another year of new Insights and Peaks.

The numbers monster

I just finished polishing my article about meaningful indicators; I had hit the "Send" button and felt good. I was able to express my thoughts about meaningful and meaningless numbers, and my article had been accepted to print.

While writing about indicators and numbers, I remembered that James Bach described the moment when he realized that the test cases count he had been asked to give his manager was meaningless as a turning point in his career (utest blog, "Testing the limits" with James Bach).

smiling, I lean my head towards my laptop, taking a small nap.
Through the mist, an email message popped up to my face. The magical forest keeper forwarding me a message from the numbers monster: The numbers monster is hungry and wants me to give her some numbers.

I replied to the forest keeper: I understand that the numbers are very tasty, but they are complete junk food. We can ask the monster what is her purpose in digesting the numbers, so I will be able guide her to find some good herbs that will satisfy her, instead of fattening her with the junk food she asked for.

The forest keeper replied again in few seconds: The monster demand her numbers.

I replied back: our forests success depends on the monsters health. I know that she is used to the junk food that she gets from other creatures in the forest, but I don't think it is good for her. I watch monsters when they eat the numbers junk food, they start going in the wrong direction, and even when they go in the right direction, they waste the dwarfs energy supplying them junk food, instead of gardening the herb plot and taking care of the forest's prosperity.

The forest keeper replied again: The monster demands her numbers. As a forest keeper, I need you to co operate in order that the dwarfs will keep feeding the monsters numbers. It’s easy for you and for them, and most importantly, it gives the monsters the feeling that they control the forest and not the dwarfs.

My mind starts thinking how to convince the forest keeper to give up his tradition and do a better job for our forest, but then I woke up from the dream.

What do you do when you meet the forest keeper and the numbers monsters?

Humor and bug submission - comedy or tragedy?

One of the testers working on the validation project I am leading, submitted a bug with the following title: "Unbelievably short period of appearance of the feature menu - feature impossible to use". In addition he mentions in the bug description that the feature is impossible to enter for anyone but an experienced "Quake Tournament Player".

Both the title and the description made me laugh, especially since I remember that many years ago, a few of my fellow testers and myself used to spend our lunch breaks playing Quake.

While enjoying the humor, all of my bells of bug submission guidelines rang. We know that bug submission is a very sensitive and responsible task, and the bug must be presented in an objective manner, which was not the case here. On the other hand, reading the bug gave me a real laugh, which we need while working so hard. In addition, I can even say that using the funny example helped me identify with the end-user described as not an experienced "Quake Tournament Player", since I suck at playing arcade Quake, too.

We know that humor should be used wisely - to relieve tension and give us a good laugh that relieves the stress. Even the serious discipline of medical treatment is aware of the contribution of humor and laugher to the patients and invented the profession of medical clown.

Should we go in the sterile “BKM” direction or share our sense of humor even in our bug descriptions?

Since I value risk taking, I would say that sometimes we can allow ourselves to go a bit wild with a few guidelines:

• Make sure you personally know the possible stakeholders who will look at, or work on, the bug, and make sure they know you and value a sense of humor.
• Don’t start with jokes before you've established your credibility as a serious bug submitter.
• Don’t do it too often. Once or twice in a project life cycle is enough.
• Make sure your joke is funny (perhaps you would like to test it before hand).
• No need to mention that the joke should not be offensive in any manner to anyone.
• At the end, make sure that the bug is perfect and clear from all other aspects. A bug with a joke, but without steps to reproduce, might look even worse than just a bad bug missing steps to reproduce.
• Understand that following all of the guidelines above cannot guarantee that you will not fall into hidden traps.

Comedy can easily turn into tragedy. Sometimes taking risks pays off, and sometimes not. Do it, but at your own risk!

Celebrating 10 years of testing - the Milestones and the People

This month marks 10 years since I moved from the I.T. support field into SW testing. Celebrations often find you very busy with other activities like I am now these days, in a middle of a validation project, but nevertheless I would like to give some thought to important milestones during this testing decade.

I will follow the context driven school of testing, which emphasizes the people as the most important part of the Testing project and I will celebrate each milestone and mention the related people who helped me reach it.

Milestone: First mistake
Person: Myself (who else could I blame…?)
Bad decision – bad result – when I let development close a non-reproducible bug, it was a mistake - since such bugs tend to reproduce at a later stage... Fortunately, failure reproduced again before the product went out to certification, during the pre-certification process, but that caused a lot of noise. Believe me - learning this lesson made me a much better tester.

Milestone: Leading a team of really great testers
People: Jose & Itzik
Jose, a new student (now a firmware architect) and Itzik, a tester with some experience (now a SW developer) joined my team. Together we built a team of passionate testers who challenged the tested SW. Without knowledge of too many methodologies and processes we explored and invented new methods and tools. We did a great job for our stakeholders.
I discovered my skill as a team leader – not intimidated by the talents of others – but helping the team express their abilities.

Milestone: My really great bug
Person: Jose
When I wondered “what would happen if…” and did the extra action that exposed a major failure in the product, I did not recognize how great a bug it was. Only when Jose (appearing in this post for the 2nd time), pointed out the thought process and mindset that led me to find this bug did I understand the significance of this occasion. Since then, a framed hard copy of the bug entry hangs in my cubicle and I refer to it as my own Tester Certification.

Milestone: Redefining myself as a Tester
Person: James Marcus Bach
When I was sent to his “How to be an expert tester” session, I did not anticipate its impact. Perhaps I was ready after 5 years of experimenting and perhaps it was James’ style, but this session made me start a journey of reading, talking and thinking about testing, exposing myself to different approaches, finding my preferences and defining my approach to different aspects of our profession.

Milestone: Participating in the Methodologies workgroup
People: The workgroup members
Participating and contributing to the methodologies workgroup of my testing department was not only an honor, but a challenge. Besides reviewing the work of others, I contributed two of the chapters of our methodology document. I had to explore, define, write and discuss the methodology of bug submission and test case authoring, exposing myself to criticism and debate.

Milestone: Starting to blog
People: Shmuel Gershon, Pradeep Soundararajan, Parimala Shankaraiah
During the last year, I started blogging. The inspiration came from my friend Shmuel Gershon who has been blogging about testing for a few years. I started blogging with a first post that reviewed Test books and magazines. Then I read Pradeep Soundararajan’s post “Why good software testers should come out of the well?”, and started blogging my own ideas too. I had been thinking about it for a long time, but his last post gave me the final push after a few months of an idle blog. Parimala Shankaraiah with her refreshing blog “Curious Tester” inspired me by showing how simple ideas turn into brilliant and refreshing posts.

All of these people and milestones have made me the Tester that I am today, and made for a thoroughly enjoyable decade. Thank you, And have a great next decade.

Bugs in children’s literature

During the last week, we heard that the famous books illustrator Shmuel Katz (see also Hebrew Wikipedia article ) passed away. His biography as a holocaust survivor, Kibbutz member and an extreme left-wing activist may be very interesting, but he is most famous for illustrating the children’s book Dira Lehaskir ("Apartment for Rent") by Lea Goldberg which was written in 1959 and became one of the classics of Hebrew children's literature.


Katz’s painting on the book cover is also the most famous kid’s literature painting bug.
The book starts with the following words: "בְּעֵמֶק יְפֵה בֵּין כְּרָמִים וְשָׂדוֹת עוֹמֵד מִגְדָּל בֶּן חָמֵשׁ קוֹמוֹת", or in my free english translation "In a beautiful valley between vineyards and fields stands a five floor tower".

When Katz passed away, one of the T.V. channels broadcast a recent interview with him. In the interview he admits that he regrets the moment when he noticed that he painted only four floors(As you can see in the picture above) while there are five in the text. He didn’t take the time to fix his mistake since he believed that no one would notice. (Un)fortunely, the book become a best seller and he got many complaints about this bug for the rest of his life.

If you are in the business of Testing and Development that sounds familiar, no?

Even when the author himself is the illustrator bugs slip through the paintbrush.
The great Israeli Children books author and illustrator of the current century (And I can say that as a father of three who has been reading bed time stories for few years), Rinat Hoffer (No Wikipedia article about her yet) does it too. In her funny book “Tom’s day”,about a day's in a nutty girl's life, she asks:”What's Grandpa hiding in his coat? A toy car? Or a lollipop? No! today he brings Grandma Rachel!” Very funny, and when you open the coat you can actualy see Grandma Rachel hiding, but also a lollipop, which we just said is not there... My son spots the bug easily, and when we will have time we might complain to Rinat.

These are only two examples. From time to time me and my kids spot more bugs in our books. You are welcome to submit your examples in this posts' comments.

The thing that most annoys me when spotting such bugs is that I suspect that most of the time the bugs were spotted before the publishing of the books, but the editors did not have enough respect for our kids intelligence to think that they would notice the mismatches.

The analogy for SW development is obvious. Who didn’t hear “Who will ever use this feature?” or “No one will notice?”. We would better remember Katz’s lesson and respect the anonymous user.

Methods for testing in a scripted test design environment

The original title of the post was "Methods for exploration in the scripted enviroment". However I went a step forward, using Michael Boloton's distinction, to sharpen the point of the discussion. I know that not all of my points in this post adhere to Michael's definitions in his article (for example about using specs), but I permit myself to use his most basic definitions for the sake of my post.

Michael Bolton in his famous post about Testing Vs. Checking defines:
Checking Is Confirmation
Checking is something that we do with the motivation of confirming existing beliefs. Checking is a process of confirmation, verification, and validation. When we already believe something to be true, we verify our belief by checking…. Checking is focused on making sure that the program doesn't fail.

Testing Is Exploration and Learning
Testing is something that we do with the motivation of finding new information. Testing is a process of exploration, discovery, investigation, and learning. When we configure, operate, and observe a product with the intention of evaluating it, or with the intention of recognizing a problem that we hadn't anticipated, we're testing. We're testing when we're trying to find out about the extents and limitations of the product and its design, and when we're largely driven by questions that haven't been answered or even asked before…

Now that we have refreshed our minds with Bolton’s definition of Testing, the challenge of doing testing in a scripted environment is clearer. In other words – when we are in a scripted environment that naturally emphasizes following the written instructions which is actually checking, how do we encourage the testers to do testing when scripted test design is a given? This is the case in most of the testing that I am involved in, although ET is getting more and more space in the activities that I am part of.

I would like to list a few methods that I used, learned or was witness to. I don't have a “preferred one”, but I like them all:

"Run, then read” –Read the test title, design the test in your mind or on a piece of paper, run the test, then read the test steps and complete any items you hadn't thought of, if there are such items.

“Do something new” – In this method test results of “Pass” or “Fail” are not enough. The test report tool also has a mandatory field of a description of an additional test that you perfomed.

“Reveal the sources” – the test case author attached, linked or copied the requirements and/or design document as a relevant part of the test case. When the base of the test design appears in front of the tester as part of the test design itself – the tester is invited to again review the logic behind the design and to think about new ideas.

“Dialogue with the script” - Use the script as an exploration tool - see what the test case isn’t telling me, and to do so in each of its steps. “Do A, B, C; expect D” becomes: “Does it matter where A started from? What happens to B if A isn’t done? In how many ways I can do C? What else happens to the system apart from D?

“Doubt everything” or “Challenge everything” - start the tests considering the Test Case as wrong, equivocating and lying; everything is disputed (sometimes aggressively). The script told us to do something, we didn’t agree with it, or with the design that generated it, or with the requirement that generated the design, or even with the customer who generated the requirement.

(Thanks to my colleagues: BatSheva, Itzik, Shmuel and Jose who inspired me with these and other methods during the last decade.)

Enviromental factors that increase Testing among testers:

Focus on bugs, less on coverage: A culture of “Fail is good”, example - “Bug of the week” discussion in each team meeting...

Emphasize the responsibility of the testers for the quality, not for the test execution

Encourage continuous learning - reading the requirements(again…), learning the product technologies and continuous discussions with the customers (and their rep. in the organization) architects and developers .

Are you (still) working in a scripted environment? How do you increase testing? please Tell me.

Read the requirements (again)!

This week I helped my 7 years old Son, Harel, in a school project – building a model of Noah’s Ark. Since I liked it to be educational and to teach him a bit about approaching a project, I asked him to list all the Ark's requirements directly from the source. We opened the Bible and read (I am quoting here the original Hebrew text and the American standard version, Genesis 6,13):

עֲשֵׂה לְךָ תֵּבַת עֲצֵי-גֹפֶר, קִנִּים תַּעֲשֶׂה אֶת-הַתֵּבָה; וְכָפַרְתָּ אֹתָהּ מִבַּיִת וּמִחוּץ, בַּכֹּפֶר. טו וְזֶה, אֲשֶׁר תַּעֲשֶׂה אֹתָהּ: שְׁלֹשׁ מֵאוֹת אַמָּה, אֹרֶךְ הַתֵּבָה, חֲמִשִּׁים אַמָּה רָחְבָּהּ, וּשְׁלֹשִׁים אַמָּה קוֹמָתָהּ. טז צֹהַר תַּעֲשֶׂה לַתֵּבָה, וְאֶל-אַמָּה תְּכַלֶּנָּה מִלְמַעְלָה, וּפֶתַח הַתֵּבָה, בְּצִדָּהּ תָּשִׂים; תַּחְתִּיִּם שְׁנִיִּם וּשְׁלִשִׁים, תַּעֲשֶׂהָ. יז וַאֲנִי, הִנְנִי מֵבִיא אֶת-הַמַּבּוּל מַיִם עַל-הָאָרֶץ, לְשַׁחֵת כָּל-בָּשָׂר אֲשֶׁר-בּוֹ רוּחַ חַיִּים, מִתַּחַת הַשָּׁמָיִם: כֹּל אֲשֶׁר-בָּאָרֶץ, יִגְוָע. יח וַהֲקִמֹתִי אֶת-בְּרִיתִי, אִתָּךְ; וּבָאתָ, אֶל-הַתֵּבָה--אַתָּה, וּבָנֶיךָ וְאִשְׁתְּךָ וּנְשֵׁי-בָנֶיךָ אִתָּךְ. יט וּמִכָּל-הָחַי מִכָּל-בָּשָׂר שְׁנַיִם מִכֹּל, תָּבִיא אֶל-הַתֵּבָה--לְהַחֲיֹת אִתָּךְ: זָכָר וּנְקֵבָה, יִהְיוּ. כ מֵהָעוֹף לְמִינֵהוּ, וּמִן-הַבְּהֵמָה לְמִינָהּ, מִכֹּל רֶמֶשׂ הָאֲדָמָה, לְמִינֵהוּ--שְׁנַיִם מִכֹּל יָבֹאוּ אֵלֶיךָ, לְהַחֲיוֹת. כא וְאַתָּה קַח-לְךָ, מִכָּל-מַאֲכָל אֲשֶׁר יֵאָכֵל, וְאָסַפְתָּ, אֵלֶיךָ; וְהָיָה לְךָ וְלָהֶם, לְאָכְלָה. כב וַיַּעַשׂ, נֹחַ: כְּכֹל אֲשֶׁר צִוָּה אֹתוֹ, אֱלֹהִים--כֵּן עָשָׂה. וַיֹּאמֶר יְהוָה לְנֹחַ, בֹּא-אַתָּה וְכָל-בֵּיתְךָ אֶל-הַתֵּבָה: כִּי-אֹתְךָ רָאִיתִי צַדִּיק לְפָנַי, בַּדּוֹר הַזֶּה. ב מִכֹּל הַבְּהֵמָה הַטְּהוֹרָה, תִּקַּח-לְךָ שִׁבְעָה שִׁבְעָה--אִישׁ וְאִשְׁתּוֹ; וּמִן-הַבְּהֵמָה אֲשֶׁר לֹא טְהֹרָה הִוא, שְׁנַיִם--אִישׁ וְאִשְׁתּוֹ. ג גַּם מֵעוֹף הַשָּׁמַיִם שִׁבְעָה שִׁבְעָה, זָכָר וּנְקֵבָה, לְחַיּוֹת זֶרַע, עַל-פְּנֵי כָל-הָאָרֶץ

Make thee an ark of gopher wood; rooms shalt thou make in the ark, and shalt pitch it within and without with pitch. And this is how thou shalt make it: the length of the ark three hundred cubits, the breadth of it fifty cubits, and the height of it thirty cubits. light shalt thou make to the ark, and to a cubit shalt thou finish it upward; and the door of the ark shalt thou set in the side thereof; with lower, second, and third stories shalt thou make it. And I, behold, I do bring the flood of waters upon this earth, to destroy all flesh, wherein is the breath of life, from under heaven; everything that is in the earth shall die. But I will establish my covenant with thee; and thou shalt come into the ark, thou, and thy sons, and thy wife, and thy sons wives with thee. And of every living thing of all flesh, two of every sort shalt thou bring into the ark, to keep them alive with thee; they shall be male and female. Of the birds after their kind, and of the cattle after their kind, of every creeping thing of the ground after its kind, two of every sort shall come unto thee, to keep them alive. And take thou unto thee of all food that is eaten, and gather it to thee; and it shall be for food for thee, and for them. Thus did Noah; according to all that God commanded him, so did he. And Jehovah said unto Noah, Come thou and all thy house into the ark; for thee have I seen righteous before me in this generation. Of every clean beast thou shalt take to thee seven and seven, the male and his female; and of the beasts that are not clean two, the male and his female."

So Harel took a pencil and listed the requirements of his model in his own words:

1. It should be made pales from a certain wood type

2. The ark should be sealed (with pitch)

3. Size in cubits will be 300(Length) X 50(width) X 30(height)

4. A window should be on the upper floor in size of one cubit

5. A door should be on the side of the Ark

6. The Ark should have 3 floors

7. In addition: The Ark will hold Noah’s family and the beasts: a pair of each kind, but seven of each “clean” kind.

When he was done listing, we noticed a few things which are not usually shown in the typical drawings or models of this favorite subject: I never saw anyone painting the Ark in black, however, it’s very likely that after Noah pitched the Ark from outside and inside he didn’t paint it brown and draw wood parts on it, like is shown in most pictures. No one also painted seven sheep or giraffes although these animals are from the “clean” type according to the tradition and Noah might have brought seven of them. We also noticed that the triangle roof and the ramp are optional components. Then we went to work – fulfilling the requirements without the bias we had from other sources, and learned a lesson about getting the requirements from the original source.

Harel demonstrates great requirements reading skills. I am not sure what is the chance that my son will be a tester in his future (currently he wants to have a career as a gaming SW tester, which in his eyes is the perfect profession), but for me this experience is an additional reminder of the danger of executing a test from a test plan without reading again the requirements.

The traditional test execution process (unlike ET), is built as a linear line of of turning the requirments and SW design into test cases and then executing them, but our mind is not linear. The ideas and understanding of the product evolve with time and experience, and our original perspective changes - for better, since it's more mature with time, and for worse, since it's likly to disconnect from the original sources of knowledge. Returning to the requirements at each stage of the execution will reconnect us to our mission definition and will give us an opportunity to relearn the material when our mind is more ready.

My recommendation to everyone who opens a bug or executes a test is always: Read the requirements (again)!

The Ark model.

We didn’t paint it black (we thought brown is nicer). We placed two

sheep and not seven (resources limitation), but we did it consciously.