There is no four and six in testing!

If a batsman has to score four or six runs in a cricket sport, he needs to drive or hook the ball to the boundary. He can do that since he sees the boundary. As a tester have you ever seen a boundary?

I have never seen a boundary!

What I mean by that is, I have never seen a boundary as a batsman in cricket sport does.

A batsman is able to score four or a six because he knows where the boundary is. If the boundary kept changing, will the batsman ever be confident of scoring a four or six?

Here is a chat excerpt between me and a tester who is preparing himself for ISTQB!

CT: Pradeep, I have one doubt in testing.
CT: BVA for 4 to 10
CT: the values 3 4 5 9 10 11
CT: is it correct?
me: Man if it is this easy to do a boundary testing, anyone can do testing.

Also, have a look at a questions about boundary testing from a sample ISTQB exam paper:

7. Boundary value testing

a. Is the same as equivalence partitioning tests
b. Test boundary conditions on, below and above the edges of input and
output equivalence classes.
c. Tests combinations of input circumstances.
d. Is used in white box testing.


1. An input field takes the year of birth between 1900 and 2004
The boundary values for testing this field are
a. 0,1900,2004,2005
b. 1900, 2004
c. 1899,1900,2004,2005
d. 1899, 1900, 1901,2003,2004,2005

In my opinion, a tester should be taught that there is no fixed boundary in software!

Here is my story of boundary testing of a multimedia product:

I was testing an audio decoder which was supposed to play any mp3 file ranging from 24 kbps to 196 kbps.

So is boundary testing of such a product something like playing 23 kbps, 24 kbps, 25 kbps, 195 kbps, 196 kbps, 197 kbps?

Huh! The version of software I got to test crashed when I played 96 kbps file and I also found that 128 kbps crashed the application, too.

Yes, I agree that it was supposed to play any value from 24 kbps to 196 kbps ( as per the specification). So does that mean, I did not do a boundary testing on the product because I did not use the value 195, 196 and 197?

Jeez! In my opinion, I did a a boundary testing. I did *explore* the program for it's boundary and found that the version of software I got had a boundary of 84 kbps and any value above which the application crashes ( smoothly) .

Despite 96 kbps and 128 kbps file crashed the application, had 196 kbps file played, does this mean there are more boundaries than you imagined?

Isn't it something like saying Pluto is the last planet in our Solar System and NASA coming out with photographs of a planet beyond Pluto that is a part of our solar system. (Wow! General Systems Thinking, is helping me a great deal)

The next version had a fix for the crash and it appeared to me that a 96 kbps file did not crash the application.

Now that's a story of how I conjecture that boundary is not a static in software. James Bach spoke about Boundary Testing in Becoming a Software Testing Expert Google Video and it gave me more new dimensions about boundary testing and a lot of other things, too. If you haven't watched it, you don't know the secrets of becoming a software testing expert :)

As a tester, I am never *sure* about something that I have observed or claim to know about testing but I am very sure that after reading this post, many testers would spark off with their experience and jump out to say, "I have seen a boundary" or " I did boundary testing the way you said is an incorrect way of doing it".

If I were you, here is what I might want to say, "Pradeep, I have done boundary testing in a way that you pointed out as incorrect. I might have failed to notice the thing that you have mentioned, probably because of a tunnel vision imparted to me. Let me do a few more experiments with it and get back to you".

That sounds great!

Have you ever wondered whether you can see James Bach and Mike Kelly exploring boundary of a software and testing it?

No more wonders, it is a reality! Download this video

The boundary does not exist in the software but it does, with your thoughts!

-- Pradeep Soundararajan - pradeep.srajan@gmail.com - +91-98451-76817

Pradeep's first language is not English--his first language appears to be testing. -- Michael Bolton

Update: BJ Rollison has made a post on this and left a comment in my blog too. I have replied to BJ Rollison in the comments section here.

Tester Developer Relations - A study based on Indian context

Programmers are vital resource of information to a tester!

If testers start looking at developers as vital resource of information, there is a lot better testing that can happen over that place. Rapid Software Testing says, "As a tester be a service and not an obstacle to the project" and isn't that amazing? One dimension to being an obstacle to the project is about having a bad relationship with developers.

The highlight

It is not just a tester-developer relationship that goes bad in an organization. Speaking from my experience, a developer-developer relationship has gone bad and a tester-tester relationship is no exception but the highlight of all is tester-developer. I infer from the results of a bad, developer-tester relationship that the resultant was more expensive than a developer-developer or tester-tester relationship going bad.

The ownership problem

It appears to me that if you ask a developer and a tester, a question of who contributed to the relationship going bad, a testers finger would point at the developer and the developer would be a victim of Newton's 3rd law. It is a rare occasion that a tester or a developer would point his finger at himself. Sometimes, the developer or a tester is not aware that management is also a reason behind it.

In India, I have heard so many stories of management being a major contributing factor to the developer-tester relationship going bad. I must admit that there are certain companies in India who encourage a tester developer relationship but I am not sure where they are.

Fear of university

I am happy of having done this detail research in which I explored the mindset of a tester when he works for a developer from a better university than where he graduated from. In India IIT and IISC are considered to be the most fundoo universities. Start ups, usually hire fresh graduates from IIT and IISC for development and conduct a walk in for testers and pay them 1/10 th of what an IIT Developer is paid. Some testers start feeling inferior and their confidence at the start of the career goes down. They turn out to look for development jobs.

Here is an interesting story: In one of the company I worked for, I was one tester for 3 developers who were from IIT and IISC. They welcomed me with a look as if , "Is this guy going to find bugs in my code? ha" and it took me little time to understand that they too were humans who could make mistakes. After a couple of months, the three developers from top universities called me, "Crash specialist" and I enjoyed a good relationship with them. There was another tester on a similar project in the same company working for 3 developers from premier organizations I mentioned. That tester always exhibited discomfort working with those three as he kept feeling inferior. He quit the company as he could not live with inferiority complex for a long time.

Now, I know the secret of killing inferiority complex when it is caused by someone who claims to be the best programmer on earth. As you are my blog reader, I want to share the secret with you but keep it within yourself. The secret is ...FIND BUGS IN HIS CODE!

Self assumed slave!

I am not sure why such an assumption enters a testers mind but I have seen some of my co-workers running to a developers seat when a developer calls the tester over his extension and say, "Can you come to my seat?". A self assumed slave tester runs towards a developers cubicle dropping the test he was doing and also without asking the reason for the developer calling him.

Here is another story: In one of the companies I worked for, I saw a tester who looked to my eyes as sitting idle and I *requested* him to join me for the test content generation so that I could get better ideas. I said, "Hey let's generate this file as a test input" and started doing it. The tester interrupted, "Pradeep, can I ask the developer and come whether we can test with this clip?". Jeez! why should he ask a developer whether we testers can use a clip for testing? On probing him, I got to know that he was once scolded by a developer for doing a test without informing him. That's funny!

Developerophobia

Most of the developers I have worked with never hesitate to ask for information from testers when they need it and I admire them for that. On a contrary some testers who were co-workers to me have feared to ask for information from the developers. This class of testers feel that developers might consider the questions as *silly*. What this class of tester is not aware is, questioning needs to be his tool to solve any testing problems he has in hand. If you aren't questioning, you aren't testing!

Finding bugs to bug a developer

Some testers are eager to find more bugs to keep the developer busy in case the relationship is in a bad state. Such a tester feels great after doing so and he doesn't realize that he isn't concentrating on learning a product while testing it. He keeps thinking, the crash and the hang that crashes a developers weekend plans.

Another dimension is, the severity and priority of the bug found is for no reason kept high by a tester to bug the developer and only a chain of mails flow to bring the levels down.

The foreign trip trauma

Some developers who come back from an on site assignment behave with testers in a way that makes the tester feel deprived of certain things. Are you thinking I would say, "This is a developers mistake?"
Nah! It is still a mistake of a tester who fails to recognize, being in India he is in a fastest growing economy of the world and the most watched nation of the world.


The jargon menace

Developers seem to talk jargons that a tester might not be aware of. Under some situations, a tester gets to feel inferior but the tester does not realize the fact that he need not know all the jargons the developer knows. A tester ideally should know a product better. In my experience, I worked with a developer who was writing code for an MP3 application whose jargons and lingo I did not understand but came up to me once, to ask in a soft voice; can I know how to do a Fast Forward in this application?.

Do you now think, I am trying to say a tester is better than a developer in this context?
Look at them, they do come out and admit mistakes/ask for information in front of a tester!

Testers need to realize that it is not just by talking and knowing the jargons of a developer helps him become a better tester but *skills* do make them better tester.

Development Managers heading Test team

Yeah! Wonderful point to end. Testers, in some companies report to a development manager. They never miss a chance to share their stories when they meet testers from other company, anywhere. The story is simple, the development manager is partial and developers get more hike and better appraisal each time. There is no end or beggining to such a story.

A story I heard: A tester went to the development manager and asked; why are you heading us?. The tester had to look out for a job, soon and the story ended there.

Think of Time v/s Value and Cost v/s Value , you might start doing more of testing! Enjoy solving better testing problems.

-- Pradeep Soundararajan - pradeep.srajan@gmail.com +91-98451-76817

"Pradeep's first language is not English--his first language appears to be testing." -- Michael Bolton

A tester's screen saver

When man stepped on the moon, the cost of being on the surface and experimenting was a Million US Dollars a second in 1969.

Many projects that we work on today are as critical as the one above, not in terms of the cost of the test but the cost of missing a test, which matters to the client or affects the end user or the organization to whom you deliver your services. It is my opinion that the definition of "complete testing" many testers have, isn't convincing test experts or philosophers of testing. Hence it seems to be less plausible if someone says; I have tested this completely. It is interesting to note that some testers, in my experience have been using this knowledge of , impossibility of complete testing, to defend their work when questioned about a bug that they failed to find.

Investigative scientists and data collection team at NASA used guideword heuristics to maximize value of running test or observation at the cost of One Million US dollars a second. Refer to page 52 of Rapid Software Testing Appendices for more information.

Reading that would motivate a passionate tester to maximize value for the project he is working and would work in the future. The concept of thinking like an expert, enters a passionate tester mind on reading such articles.

It's time you realize, the importance of heuristics for testing a product better than what you have been doing so far, if you haven't been thinking about heuristics.

Now, all this is fine but who is going to help you each time to remember some of the most important heuristics that might help you to test in a way that makes you thank the heuristics and the people who came out with it?

It's none other you, dear passionate tester.

I like to offer a help to all those passionate testers who would want to use heuristics and think of cost v/s value when they test. I was delighted when I got the idea of offering a help and started working on it immediately. I am confident that most of you would like my idea and would recommend the usage of it to other testers too. My fingers remain crossed, though.

It's time for you to have a look at it. So download this www.satisfice.com/RST36.zip . Do not be afraid to run the exe, it's a screen saver that I have built for you, dear tester.

The idea will speak the rest and I stop here :)

Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

Note: There were some issues with the screen saver earlier. Thanks to Venkat Reddy and Rosie Sherry for identifying the issue.