Today I have a story to share. The source of story is not important so I am not discussing about it, what really matters is the moral of the story and that’s the only reason I am sharing it with you.

There was an aspiring IT company in India with good Development team, Media team, Marketing team, Managers and Testing Team. Sorry I said Testing team but actually there were only two testers in the team :)

So there was a product on which a fully development team of 6 developers, one team leader and a tester was working. The product was running from last 10 years and has gone through many stages and changes. During the last 10 years the team has been changed many times but the product was still there. The product was under development as well as maintenance stage. So sometimes there was new development otherwise most of the time it was under maintenance.

Once there was request for an enhancement in Search module of the product from Client. There were two different search screens for two different entities. Now Client wanted to combine both the search screens i.e. when a user made a search for a keyword, the result should appear in single search for both entities in two different tabs.

The task was assigned to development time. The development team has started their job on the new task. But they took more time in completing the task than the allotted time. In fact there was no time for testing and debugging.

In this situation team leader decided to upload the task on client site without testing and debugging. He uploaded the task on client site and then assigned the task for testing. The tester completed his job and reported the bugs to development team. The development team started to fix the bugs. They have fixed all the bugs and the task is reassigned to tester. All the issues had been closed except one. He again reported the same issue. Development team worked on it but unable to fix it. Every time development team fixed the issue, the tester reassigned the issue back to them. The development team was really in trouble. They told team leader about the problem.

In between Client reported issues in new enhancement. The Client reported all issues except the one which was reopened many times. The issue was regarding search time taken by application in searching the records. According to tester the application is taking too much time in giving result.

After discussing with development team, team leader called the tester for discussion on issue. According to team leader there was not any issue. They had already applied all their tactics to make the search fast and there was no way to make it faster. According to team leader there was hundred thousands number of records so application was taking time in searching.

The tester was not agree with his team leader. According to tester the search was slow and it would really irritate the user in future. He told to team leader that if number of records was reason of slow search result, in that case Google should take hours to display the result and they had long debate on issue.

At last, team leader asked tester to close the issue as the issue was not reported by Client and he decided to upload the remaining changes on client site. The tester refused to close the issue. He didn’t want to dishonest with his job to please his team leader. The team leader felt it as his insult.

After discussion the team leader uploaded the changes on the client site and reported to Manager that the tester was not good team player, irresponsible about his job, never listen his senior and always does useless debate. The result was tester had been put on bench for indefinite time.

More than 5 days have been passed; there was not any complaint from Client. He had used the new feature many times and he seemed happy with new feature. The development team was happy with their job but the tester also was not upset with his decision. He always knew he was right.

After 13 days, a mail was received from Client regarding same issue and he was really unhappy. According to him the search was taking too much time to produce the result. After this mail, manager called the team leader in his room for meeting. What they discussed behind the doors was always a secret but after the meeting the tester was back in team. He was working on the same product and development team including team leader started to take him seriously.

Moral of the Story
For Aspiring Testers:
(i) Be honest with your job as Honesty is the best policy.
(ii) Don’t change your views, ideas, ethics or heuristics to please anyone.
(iii) Never take back steps from an argument if you are right. Doesn’t matter who is in front of you. Just believe in yourself.

For Management of Companies:
(i) Testers are assets to the company. Let them do their work with honesty.
(ii) Testers view the things with Clients perspective. Believe in them.
(iii) Never release a product with issues to client. Little delay is much better than a buggy product.

Continue...

I always want to interview the great testers to know the secret of their great testing skill, to know the way how they perform testing, to know how all they became masters in the field. In short I want to know the recipe of their success as a tester but never got a chance. The reason was I never approached them as I always have a doubt that they will refuse my request as my blog is not popular like the other sites in which their interviews have been published. Even my blog doesn’t have regular readers. This fear never let me approach to ask them for interview and the wish could not fulfill.

But my dream came true. It was different from what I thought but I got a chance to interview. Although he is not a celebrity but he plays very important part in success of a tester. Dear friends, I got chance to interview a Bug. Yes, a Bug.

His name was ‘The Great Bug’, would be abbreviated as ‘TGB’ further. I am using past tense for TGB as he is no more and has been fixed (or ‘dead’) by development team but I promised him before reporting that I would tell his story to the world. So let me present the story of ‘TGB’ in his own words:

Me: Why you are named as 'The Great Bug'?

TGB: I am the first bug of the project. I have seen many generations of bugs. Hundreds of bugs have come & fixed but I am still there. The Sixth version of the project is going on and I am still here. So my follower gave me this name with respect. They believe me as the best bug.

Me: What kind of Bug you are?
TGB: I am a Bohr Bug. Do you know about Bohr Bug?

Me: No, but I would like to know.
TGB: A Bohr bug is a bug that makes itself apparent consistently under a well-defined (but possibly unknown) set of conditions. The Bohr bugs include the easiest bugs to fix, but also bugs that are hard to find and fix and remain in the software during the operational phase. These kinds of bugs are often present in parts of source code that are not invoked very often and thus might remain undetected for an extended period of time, and are sometimes termed as 'Ghost in the code'.

The common example is a program which always fails when you divide by zero.

Me: that’s interesting! What are the other kinds of bugs are there?
TGB: There are Heisenbug, Mandelbug & Schroedinbug and many more.

Me: Would you tell us about them, so that we can classify a bug next time we find.
TGB: hmmm..... I don't see any harm in it for our bug family. Ok, I would tell you about the bug classification.

(i) Heisenbug: Heisenbug is a kind of bug that disappears or alters its behavior when one attempts to probe or isolate it.

A common example is a bug that occurs in a release-mode compile of a program, but not when researched under debug-mode.

These bugs are antonym of Bohr Bugs.

(ii) Mandelbug: A Mandelbug is a kind of bug whose underlying causes are so complex that its behavior appears chaotic.

For example, a fault in an algorithm's implementation can lead to an erroneous computation for specific values of a program variable—a case of fault activation causing an error. The software can use this incorrect result internally for further calculations, in which case the error propagation leads to additional errors. A failure occurs only when the system uses one of these incorrect calculations in a way that influences a perceivable system behavior, or when error propagation causes a failure occurrence.

(iii) Schroedinbug: A design or implementation bug in a program that doesn't manifest until someone reading source or using the program in an unusual way notices that it never should have worked, at which point the program promptly stops working for everybody until fixed. Though this sounds impossible, it happens; some programs have harbored latent schroedinbugs for years.

For example, a database program may have initially worked on a small number of records, including test data used during development, but broke once the amount of data reached a certain limit, without this cause being at all intuitive. A programmer without knowing the cause, and who didn’t bother to consider the normal uptick in the database size as a factor in the breakage, could label the defect a schroedinbug.

Me: Why do bug exists?
TGB: It’s your question or it is your problem :)
Me: It’s just a question about your existence.
TGB: hmmm…. there are many reasons of our existence like
(i) Communication Gap between client, management & team members
(ii)Complexity of the project
(iii) Pressure to complete the time within strict time frame
(iv) Continuous change in requirements
(v) Programming errors
(vi) Poor or Incorrect Documentation etc.

Me: How did you come in the world?
TGB: Do you want to know the complete story?
Me: Yes
TGB: Well, about three years ago Mr. Client got an idea to automate his business. He came to meet Business Manager of company to apply his concept. They had long meetings discussing about their new project. They were very exciting about the project. During this excitement, they forgot a very important concept and I was seeded in the project.
Even in the designing phase, they did not find the glitch in the project and when programmer were writing the code, they gave me life and since then I am here.

Me: So, it's a developer who has given you birth?
TGB: No, My original parents are Client & Business Manager of the project. They are responsible for my existence.

Me: That is really interesting! If it’s true what you are saying then why the developers are always claimed for bugs?
TGB: The developers are the weakest in all of them who is responsible for our origin and its human nature to blame the weakest one. Not all bugs are originated by developers. Most of the bug already present in the project when developer is introduced in the project.

Me: Do you think people will agree with your point of view?
TGB: I am not here to make them to believe me. Everybody has its own conception. This is my truth and it is up to them whether they are agree with me or not.

Me: Do you have a family?
TGB: Yes, I have family. In fact, in earlier period of the project I have a big family but with time they all have been caught by ABS members. Now, there are just few people in the family. I miss them all whom I lost with time :(

Me: I am sorry!
TGB: It’s perfectly alright. So don't feel sorry.

Me: How you spend time with your family?
TGB: As I told you, I had a big family. We use to party all the time. We always enjoy our togetherness and our success. We never think about our future, neither we use to look back on our past. We enjoy the present.
Me: it means you know how to live a happy life :)

Me: I am really curious to know why you were not identified by anyone till now.
TGB: :) It was not an easy task my dear but I always succeeded to hide myself. Actually I disguised myself as a feature of the project. Whenever anybody tried to find me, he could see the feature only.



Me: you talked about some ABS members, what is ABS?
TGB: ABS – Anti Bug Squad. ABS members are really heartless people, they are the people who find us, report to Developers and make sure that we all get killed. (Read as 'fixed')

Me: you mean tester!
TGB: We don't care what you people say them. We call them ABS members.

Me: You know I am also an ABS member!
TGB: Yes, but I am just saying the truth. Due to you heartless people our family could not grow. How can you ask developers to kill us?

Me: This is our job. Company is paying us for finding and reporting about you. We help in development of quality product. Our goal is to find bugs in project, to find bugs as early as possible and make sure they all get fixed.

TGB: huh! Quality.... To hell with your Quality :x

Me: It was really a nice interview and I hope whoever read your interview will have the sympathy with you.
TGB: I don't want sympathy. I just want people know about us. That’s all.......

Me: Thanks TGB for your support, Efforts and Time.
TGB: Thank you very much.

It was the last time when I saw TGB. After this interview, TGB was fixed within next 6 hours. The Great Bug is no more. The bug which was not found in six releases has been fixed at last.

This is the story of TGB.

Disclaimer: This is not the original interview of TGB. The original interview is edited because of foul and abusive language :)
Continue...

It is a hot debate topic among testing professionals “Exploratory Testing Vs Scripted Testing”. Open any discussion forum and you will find one or more such discussions. In these discussions, majority of the test professionals support Exploratory Testing and a very few test professionals are there in favour of Scripted Testing. This displays that the exploratory testing is in trend.

I also think that Exploratory Testing is better approach than Scripted Testing but still we can't ignore the importance of Scripted Testing. Although majority of testers support Exploratory Testing Techniques but still the mostly organizations follow the Scripted Testing process.

In Scripted Testing, tests are predefined in form of Test Cases.

What are Test Cases? - In simple words, a test case is a step or sequence of steps to test the correct behavior of a functionality/feature of an application.

More organized definition of Test Case could be:

A test case is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not.

It doesn't mean that a single test case is sufficient to determine the correct functionality of an application. It may take many test cases to determine that a software system or application is functioning correctly. Test cases are often referred to as test scripts, particularly when written. Written test cases are usually collected into test suites.

Now the question is why we write test cases? - The reason behind writing test cases is to ensure the testing coverage of an application. Another reason is to test the application quickly. The idea is to write test cases based on design while code is incomplete, so that we could test the application quickly once the code is ready.

The test cases can be divided into two categories:

Formal Test Cases : Formal test cases are designed to fully test all the requirements of an application. There must be at least two test cases for each requirement: one positive test and one negative test.

Informal Test Cases : For application without formal requirements, test cases can be written based on the accepted normal operation of programs of a similar class. In few organiztions, test cases are not written at all but the activities and results are reported after the testing is completed.

Test Case Format: A typical Test Case may include

• Test Case No.

• Testing Component

• Description of Test

• Input Data (If any)

• Expected Result

• Actual result

• Test Date

• Status – Pass/Fail

• Remarks

A sample Test Case is attached here.

Continue...

A testing technique in which tester doesn't need to know the internal structure of the code to test an application. The main objective of Black Box Testing is to test the functionality of the application as a whole.

The Black Box testing considers the application as black box so explicitly it doesn't need the knowledge of internal structure or code. While designing test cases, tester takes external perspective of the application and based on the perspective the test cases are derived which can be functional and non functional.

The Black Box testing techniques is applicable to all levels of testinng : Unit, Integration, System and Acceptance Testing.

Advantage of Black Box Testing:

• More Effective when used for large systems

• As the tester and developer are independent of each other, test is balanced and unprejudiced

• Tester can be non-technical.

• There is no need of having detailed functional knowledge of system to the tester.

• Testing helps to identify the vagueness and contradiction in functional specifications.

• Test cases can be designed as soon as the functional specifications are complete

Disadvantage of Black Box Testing:

• Test cases are tough and challenging to design, without having clear functional specifications

• It is difficult to identify tricky inputs, if the test cases are not developed based on specifications.

• It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult

• Chances of leaving many program paths untested

• Chances of repeating the tests that are already done by programmer.

Black Box Testing Techniques: Typical Black Box testing techniques are as follows:

• Error Guessing

• Equivalence Partitioning

• Boundary Value Analysis

Error Guessing: Error Guessing is a testing technique which is based upon the tester's past experience, knowledge and intution to predict where the bugs can be found in application under test. Some areas to guess are: empty or null strings, zero instances, occurrences, blank or null characters in strings, Negative numbers etc.

Equivalence Partitioning: Equivalence Partitioning is a Black Box testing technique in which input domain data is divided into different equivalence data classes. This technique tries to define test case that uncovers classes of errors, thereby reducing the total number of test cases that must be developed.

For E.g.: Consider you are testing a date field which can accept date from 01-01-2001 to 31-12-2010 . In this case there is no use to write 3652 test cases for all valid inputs plus test cases for invalid inputs.

By using Equivalence Partitioning, we can divide all the inputs into three classes:

1. Dates before 01/01/2001 - Input data class with all values below lower limit. i.e. any value below 01/01/2001, as a invalid input data test case.

2. Dates from 01/01/2001 to 31/12/2009 - One input data class with all valid inputs. Choose a single value from 01/01/2001 to 31/12/2009 as a valid test case. One test case for valid input data is sufficient because If you select other values between 1 and 1000 then result is going to be same.

3. Dates after 31/12/2009 - Input data class with all values upper to higher limit. i.e. any value after 31/12/2010, as a invalid input data test case.

By using Equivalence Partitioning, we have categorize all the test cases into three classes. Now we can choose an input value from each class to design our test cases. As you can see by using Equivalence Partitioning, we have covered maximum condition from fewest test cases.

Boundary Value Analysis (BVA): From Practice and Experience, it has been prove that most of the errors are found at the boundaries of input and output ranges of an application component that result in application faults. Boundary value analysis assists with the design of test cases that will exercise these boundaries in an attempt to uncover faults in the software during the testing process.

As Equivalence Partitioning, BVA is also used to design test cases where test cases are selected at the boundary of the input ranges.

For eg: In the above example test cases for date field accepting dates between 01/01/2001 to 31/12/2010 using BVA will be as follows:

1. Test cases with test data exactly as the input boundaries of input domain i.e. values 01/01/2001 and 31/12/2010.

2. Test cases with test data with values just below the boundaries of input domains i.e. 31/12/2000 and 30/12/2010.

3. Test cases with test data with values just above the boundaries of input domains i.e. 02/01/2001and 01/01/2011.

After determining the necessary test cases with equivalence partitioning and subsequent boundary value analysis, it is necessary to define the combinations of the test cases when there are multiple inputs to an application component.

Continue...

It has been really a long time when I wrote my last blog post. In between I was busy with lots of stuffs & changes in life :) Now when everything is settled, I thought to make a new start. So now onwards I will try to be regular with my posts. Continue...