Skip to content

Words of Warning

Often, Testers use words, phrases without calculating the probability of putting oneself / team / project in trouble by use of such statements.

Testers should be wary of using such phrases and should not believe in them blindfold.

I have prepared a list of such words, phrases that a Tester should avoid using. So here’s the list that may set the bomb:

I have done Complete Testing:

Do you really think its possible to do Complete Testing? Can anyone claim that the software is completely bug free? Have you tested the application in different environments, paths & combinations? Were your findings enough to cover entire testing? Have you considered all the possible scenarios? What about non-functional testing? Security, performance Testing? Different OS, browser combinations? Configuration Testing? Testing on Mobile with unending number of combinations.

My Assumptions are correct:

Do you rely too much on assumptions? Do you have those pre-conceived notions[1] that you believe are universally true to fit and apply in any System? Have you stopped yourself from observing the situation to validate whether your assumptions are correct or not? Not asking questions can only strengthen your assumptions.

Testing is easy:

So you believe testing is no brainer work. This statement makes sense only if you have no questions to ask. If nothing leads to creating doubt in your mind or you do not want to question your beliefs & is without ideas, you are not only establishing the idea of “testing is easy” in your mind, but also, making your customer’s life difficult and your own life hell. Understand, testing should be an idea generating activity.

Testing is without a mission:

Do you test the application without a mission? Do you believe your role of being a QA justifies your mission. Is Testing more of an Obligation? Don’t you believe in adding Value to the System?

Tester should have a mission that defines their plan of action. No mission means no testing without a reason.

I am a Certified Tester:

Do you think having a certificate is enough to qualify your testing skills. Do you define your Success through the number of certifications you carry in your resume? Do you think only a certified tester can only add value? Are skills equal to certificates for you?

What about the biggest skill of self-learning? You learn through your experiences, through the mistakes. Your learning makes you a strong, learned tester. No external recognition like certification can qualify your only learning.

Am good at playing blame games:

How many times you throw the ball of blame at developers, DBAs, System Admins or our sub-ordinates for the issues in production or for not doing the work on time and neglecting it? Do you really introspect yourself and think about the mistakes that could have been avoided in first place instead of getting into a WAR room now with the management and playing the nasty blame game.

Ego … hmmm:

Does your ego play a crucial role in your work? Trust me, it does no good to anyone.

Approach the situation with open mind. Listen to your peers. Discuss ideas with them. Learning through experience and knowledge sharing is the best form of learning. Don’t let your ego stop that process.

All Symptoms are bugs:

Are you in the race of logging the maximum number of bugs to show to the management how competent you other incomparison to other testers? First of all, you may be reporting symptoms which may not be bugs. And secondly, quantity of bugs reported doesn’t matter. What matters is the quality. Imagine someone suffering from high fever, cold, vomits which may be symptoms to a bigger issue at hand – maleria. So doctor thoroughly tests the patient to know the issue she is dealing with. Only then she prescribe the correct medicine. 

My experience talks about bug tracking tools:

I see resumes where people add a list of bug tracking tools they’ve worked on. Is that a skill to know a tracking tool? Is tester missing the real testing experience to cover it up with tracking tools experience? It’s like adding in your resume, “i know how to search on Google”.

I follow Best Practices:

Do you think only by applying best practices you can provide solution to the problem at hand. I believe first thing is to explore and understand the situation. Understand the context and based on your logical deductive reasoning, apply the solution. Remember, right hand driving may be a best practice with guaranteed Success results in America but the same practice may not work in India.

I am sure you as a Tester can add many more “words of warning” to this list. I am looking forward to hear from you.


[1] A visual guide to Bayesian thinking

Dangers Decoded

Imagine you are testing an application and you come across a functionality which is new and you are yet not sure if it is implemented correctly or not. Ask yourself, do you know the requirement and understand the intended functionality?

If the answer to above question is No, are you assuming the functionality of current application based on your past prejudices attained from working on other applications? Are you generalizing your understanding to apply the same logic everywhere? Are you being ignorant? Is your knowledge of knowing things from past experiences sufficient enough to know the desired goal in current situation? Are you limiting your knowledge? If you haven’t asked questions to management or stakeholders or hasn’t gone through the specification documents, you may be making a big mistake to pass the System  without the knowledge of knowing it. And that’s the first sign of danger.

Making an assumption can either put you in trouble or get you through (remember, assumptions are bad). So you as a Tester should ask questions. Asking the right questions can help you minimize the dangers of your calculated guess going wrong. it’s always good to ask before implementing to avoid the consequences later. Reading, reading the documents, asking questions, learning from previous versions, understanding the market & the competition can help you minimize the dangers of wrong implementation. Even if a mistake is made, it should be a learning not to repeat it again. Making mistakes will only improve your learning process. And, learning without prejudices will only help you gain more knowledge about the system.

If the answer to above question is Yes, is the functionality implemented incorrectly. Has the developer not understood the requirement? Ask yourself, have you given enough inputs to justify the requirement? Have you really understood the test function before handing over the requirement to developers?

Here’s a test:

Imagine there are 2 groups and each group has certain number of contacts common or different.

Group1 has 3 members (a1,a2,a3)

Group2 has 2 members (a3,a4)

Total Contacts in System: 5 (a1,a2,a3,a4,a5)

Answer these questions:

Exclude contacts not in Group1? So contacts are ->

Exclude contacts not in Group2? So contacts are ->

Exclude contacts not in Group1 OR Group2? So contacts are ->

Exclude contacts not in Group1 AND Group2? So contacts are ->

Sometimes, developers may not ask questions and apply their own logic if not enough information is provided. Or at times, developers might ask questions before coding to save everyone’s time. Understand their questions. They may spark a new scenario which you may not have come up with. Understand their views and see if the pieces fit together. If everything makes sense and you are convinced, involve the management to get clarity. Learn from them as to what do they want. Tell them about developers’ findings. Based on feedback, tell developers about what needs to be implemented. A complex application requires Testers to ask enough questions to stakeholders to understand the business logic. And the same logic should be conveyed with utmost details to developers to make it easy for them to implement.

A straight forward flaw in the logic should be immediately detected to minimize the dangers. You as a tester may not have direct control (access) over the code to decode it. You can always discuss it with developers and get it fixed.

A tester should:

  • Come up with as many possible scenarios to cover the functionality under test.
  • Should be liberal in her thinking. Reading and continuous progressive learning should be the most wanted traits.
  • Should understand how the competitor’s application works and come up with test ideas.
  • Should learn from client’s feedback / complaints about previous versions of the application.
  • Should not assume but follow a calculated approach to get clarity. Confirm your assumptions.
  • Should read documents to understand the requirement.

Remember: It’s better to decode the danger now than to regret over it later!

Brace yourself with learning new skills

The world is changing and with changing times, it has become all more necessary to evolve.

Rise of technology has improved lives and made impossible possible. Newer and better Systems is making way for automation, doing work faster and better. Work that was done few years back by hundreds of people is now done by machines in no time. Remember the rise of calculators. it changed the way we did calculations. Gone are the days when you needed a dedicated person to maintain balance sheets and look after the business critical transactions. No more punching numbers on paper and solving business transactions by crunching numbers. Computers replaced those men as they did the same job in seconds. Nowadays companies are relying more and more on machines to do most of their transactions. Recently it was in news, a girl in Australia sent her Robot to Apple store that stood in the queue at 6:30 AM to buy an iphone 6 for her.

So the day is not far when our jobs will be threatened by such powerful machines. So in order to survive, it has become very necessary to learn new skills to compete against the machines. Remember, there is always one skill which no machine can attain and that’s the skill to think. Mind is the greatest tool which no Robot can replace. No machine can create human touch. But there are jobs which can be automated for eg; executing test cases and informing the status during Regression Testing. Do you think that requires skills to run the same tests over and over again? Skill is to build program that does automation.

Companies are now looking for automating tests using Selenium Webdrivers. So this is the need of the hour. This is where QAs need to improve their skills on. Exploring new roads and learning through the experience will keep one alive in the competitive market. Acquiring new skills and learning should never stop. Companies are looking for better performing applications for customers to always keep ahead of competition. JMeter has lately become a powerful open source tool to learn and do performance testing. With so much of rising competition, no stakeholders wants to take risk of application crash due to increase in user load, long running duration of the application or huge data transfers. And Jmeter comes in as a very effective open source tool to do performance testing.

Open source tools have really opened doors for testers to learn new things and be technology smart. They need to be skillful. Learning should be at top priority. Testers should make use of technology to improve upon their methods of testing.

There are so many open source tools available in market to learn and improve skills. Testers should try to grab them with open hands and learn them to perfection. Remember no learning is real as long as it is not put in use. So just don’t read to understand the application. Implement it. Take help of fellow testers who are skilled in any particular tools or join a course. Watch youtube videos and implement them. You won’t believe number of groups on various social media websites that has come up where people ask so many questions to learn new things about various tools and get their problems solved. learn from their as well as your own experiences. Ask questions, go through the tutorials, blogs, join communities but don’t let your learning stop. Once you stop, the day is not far, when company will stop noticing you. You don’t want that day to come anytime soon!

Every new day should make you feel as if you learnt something new from yesterday. These everyday small learning changes will have a lasting effect on your learning. If you are enthusiastic about learning, ask questions, learn new technologies and how you can become skillful in that technology. There’s nothing wrong in asking for help. Don’t let your ego come into picture if your fellow colleague knows more than you and you shy away asking him to help you because your reputation is at stake. A learning mind only worry about one thing – To be Skillful !!!

Bug Advocacy

How often (or rarely) does it happen when your bug gets rejected with a comment (from devs) that they were unable to repro the bug reported. Or it was rejected on the grounds of being incomplete or obsolete ?

if it happens more than often, it’s time to introspect.

Bug Advocacy is crucial to the project. An incomplete bug report can only harm the project to delay it further as it puts everyone’s time and money at stake. QA’s have to put in time to write the bug. Devs have to study the bug and send it back if they do not understand it. Meetings with the management. Stakeholders time and money is involved. Too much of to-and-fro communication just depletes the time and money inches down.

You as a tester need to take charge here. A tester guides the project. you are the one giving direction to it. If a Tester mislead, the project can derail.

Few things that you can do as a QA.

  • Understand the reason for Bug Rejection. Go through Devs comments and if nothing much is mentioned, talk to them. Take Rejection in a positive way. It’s Okay if the bug comes back. Don’t go in exile. See if you missed adding crucial information while writing the bug report. Add comments and update the issue.
  • At times, developers directly start reading the repro steps without understanding the Observation & Expectations. See if you haven’t missed out on repro steps. If there are too many steps involved, it’s always good to attach a video. Record the steps and share the video link in bug report with developers. This makes it real easy to understand the issue and fix it at the earliest. You can download the free screen recording software from Screen Cast O Matic. You can create a free video of up to 15 minutes using this software. Upload the video on YouTube / Vimeo and share the link in the bug report. Make sure the link is not public and is accessible by intended members of the team only.
  • Share enough information by adding screenshots especially if the bugs are intermittent.
  • Developers mark bugs as Obsolete when there is a change in functionality and the issue reported does not exists anymore.
  • Your bug report should stand on its own to create an impact on everyone involved in the project as to why the bug is important to fix. Anyone in the team reading your report should be able to understand the issue.
  • Do not edit someone else’s bug report. If you find anything missing / incorrect, update it in comments section in the bug report.
  • if you think the report is complete in itself, sit with the dev team and talk to them over phone, Skype or in person. Get clarity. Get inputs and try to resolve the issue at the earliest.
  • Tester must write the bug report keeping in mind the end user who might face the issue.
  • Sentences should be grammatically correct enough to convey the message.
  • If it’s a Browser related issue, mention the browsers with their Versions used while generating the bug.
  • If it’s a UI issue, mention the screen size, resolution, browser, OS details. it may not be possible UI issue you see on your machine should be visible on all screens or OS. Check browser / OS related UI / UX issues using Browserstack. It gives a trial account with 30 minutes window to select from variety of OS / browsers combinations.
  • Prioritize the bug. High priority bugs are less likely to get rejected. if it does, it must be addressed immediately.
  • Keep it simple. No use of long sentences or descriptive bug reports. Developers have time crunch to read the entire bug report.
  • Do not add too many issues in one bug report. Developers may only fix few of them and ignore the rest. It’s better to create a separate report for each bug found.

Bottom line, make sure the message is conveyed in the right way without too much of to-and-fro.

And before you leave, I would love to hear your views on this.


Take a Break from Testing

I was testing an application for quite some time and was out of ideas to find new bugs. Now this does not mean that the application was without bugs. Remember, no application is completely bug free.

Failing to find new bugs does not mean that there are NO bugs. I was out of ideas and was tired to find issues, defects, anomalies or anything that felt suspicious within the application after continuous hours of testing thanks to my exhausted mind. So i decided to take a break and come back fresh.

Image you get pest control done in your house and you believe that the house is bug free for now. Yes, it may be bug free only in those areas where the pest control was done. But what about those tiny little gray areas that the pest control team missed out on. Areas that are still exposed but not visible to naked eye. And those are the bugs hide-out places.

It’s not rare to miss such areas while testing. A fresh mind acts as a tool that will soon find and hit on those gray areas in application that were not tested before. So it’s essential to take break and come back with a new version of testing the application (any functionality in particular) which might have been ignored in initial QA.

A Tester’s job is to cover every business critical functionality in the interest of stake holders.

A function may have many attributes, so it’s necessary to test the function from all perspectives. for eg: if the “Image Upload” says to upload jpg, jpeg, png, tiff images only and you test it with all except tiff because you never had the test data for it, you might be ignoring an area that may not be bug free.

Sometimes a QA may miss testing the lesser known attributes of any function within the application if the major functionality is intact and running fine. And this may result in your first gray area and a potential bug. Once the application goes live, your end user will find it out for you and this may not be in the best of interest of stakeholders or you as a tester. Tester can avoid such situations by taking break from testing the application and come back strong with fresh outlook. Pair Testing is another good way to think differently and ask questions. it gives a new perspective to test the application. No two testers think alike. So it’s always good to involve team mates when you are out of questions to ask.

If a new functionality is introduced within the application, Tester may skip testing it in other Browsers considering the fact that she has already tested most part of the application in other browsers before the new functionality was introduced. So she assumes that the new functionality will just work fine in other browsers as well. So she has just created another gray area.

Testing the application from an end user’s perspective as to how an end user will work upon the application with respect to business critical transactions is quite a necessity.

Mind is the greatest tool for a Tester. So make sure when you test the application, you explore new areas with an approach to break the application and not be broken by the application because of an exhausted mind!!!

Why Testers overlook to report a bug?

Have you experienced when you do not report a bug and the same would get caught by your stakeholders and then you repent on your decision of not reporting it?

Oh! I noticed that bug but did not find it important to report it.

Oh! I noticed that bug but I was held up with other things that did not get time to report it.

I think this happens and there could be many possibilities of failing to report it. What might lead to take a decision in such cases? How one can decides to report it? What makes anything new more appealing than the one you overlook ?

  1. Non – reproducible bugs: This is could be the main reason for QAs to ignore issues which are intermittent in nature. However I know that most of the issues are not intermittent in nature. If you try hard enough you can easily find the pattern and reproduce it again.
  1. Assumptions or Beliefs: QA assume that it is not important to report a bug as it looks minor. You believe that this is how it works and there is no other possible way of functioning. Your ego may come in between what you believe and what you know. Your ego keeps collecting the knowledge of application. You will be known as subject matter expert within your team because you have lot of information compared to others. But in that case QA is overconfident about his findings, he may lose grip on the issues which he’s supposed to report. He is busy boosting his ego so how he would get time to report issues.
  1. Not having enough reasons to consider a bug: When QA is not having enough exposure to the latest trends in the technology or has not tested similar or different kinds of applications then there may be cases that you may not get enough reasons to consider it as bug. Your focus narrow downs and you will not be able to see anything apart what you can test.
  1. Stakeholders do not entertain such issues like this so they go unnoticed: I am not saying to raise issues which your stakeholders asked you to know report. What I mean is if your raised issues are not fixed it does not mean stakeholders do not want them, there may be cases priorities wise it may not look important that time to fix it but later they may consider. Actually you should not get motivated based on how many of your issues are fixed. You should get motivated by helping your stakeholders to know the application better. for eg; In one of my project when I raised issues related to SEO then stakeholders informed me that they don’t want their application to be searchable on google. So it means stakeholders do not want issues related to SEO and it make sense no to report them because it is not in the scope of application development.
  1. Get frustrated with reproducing the bug again and then it looks very small to report: Some issues are extremely painful to reproduce it. All sudden app getting crashed and you won’t be able to reproduce it. It takes huge efforts to reproduce them. If you find it difficult to report it then give a try next day and despite all your efforts still you are not able to reproduce then still report the issue. Take information from log files. I always report app crash issues with logs and write steps before the crash. Actually it helps development team to fix around the functionality if they cannot fix the issue which may help in application not getting crashed anymore. But it’s different thing that it does not guarantee. The whole point is report issues even if you are not able to reproduce them.
  1. QA get busy with other test techniques or major bugs and get sidetrack these issues. Most of the time QA work under pressure because when you receive the build then your stakeholders expects the results and you are in hurry to report for major functionality. In such situations find most possible scenarios which will cover the maximum portion of the application and try to test functions within given times.

Actually for this it needs extreme focus and efforts to test application with given time. But that’s the real art of QA. What is the point if movie director make movie with 10 hours long length. Nobody would ever watch. Its skill of movie director to wrap all things in 2-3 hours length of movie. It requires tremendous skills to comprise everything in such a short span of time. Similar QA supposed to work effectively to the results which add more value to your stakeholders.

  1. Sometimes QAs take screenshots of the bugs they came across but do not them. Either you keep the screenshot unsaved on your desktop or you save it to raise the bug later.

What are the consequences?

if you do not save the information captured (wither text or screenshot) and if your System (desktop / laptop) crash, the unsaved information is lost forever and now you will never know what those bugs were if there were too many number that you noticed but never reported.

if you saved the information but sidelined it as you were busy working on other important stuff for eg: builds, finding more important bugs etc. etc, later, if you go back to the saved information, the chances of finding the real issue present in the screenshot are very less because of your lesser tendency to remember what the text / screenshot is trying to convey?

You end up with questions like:

– What steps i followed while capturing the screenshot / text information?

– Why didn’t i mark it in the screenshot as this link / button had the problem?

– Oh there’s a Server Error screenshot. What was the previous step and the link / button i clicked that landed upto this Server Error. Did i take the logs ?



While saving information regarding any bug, add as much information / details as possible and if you do not want to report it at that moment, report it later but make sure you have enough information to reproduce it again and attach considerable data (from logs / screenshots / text) supporting your bug.

Being a QA I always feel that every little thing should be reported no matter what the conditions are. QA sometime misjudge the importance of bugs or you may not be able t to think from your stakeholders perspective so it’s better to  note every small thing and throw some light on it. There may be chances of you finding something extremely important. I mean you can find a gold treasure by considering these little clues.

It’s like traveler who collects the clues to reach his destiny but there might be chances of not getting anything out of it but frustration. You may not find any further while you dig but now you know where not to dig which is again a learning. At least you gain experience and you become wise in your act.

I practice that if something bothers me while testing the application then I make sure end of the day I report it. I don’t postpone the reporting because tomorrow I may not think in the same way. I might have changed my lenses to look at the application. So I am afraid of losing anything that I found and did not report to the stakeholders.

You may find it tiring to raise anymore further issues but I personally feel if anything is tiring then it is just an activity not meditation J

Does common sense affects the usability of the product?

I read in one of the FAQs Help provided on one of the plugin’s website that ‘it’s a common sense to add plugin file to so and so directory’.

I was wondering how this can be “Common Sense” to place a plugin file in the expected directory?

What if there are two directories with the same name or what if the directory is missing? Or what if the user is completely new and she is unable to find the location.

You blame a person for not doing what the system intended. But is it really the person is to be blamed?

It is like designers design the product and engineers implement by keeping their common sense in mind. What about the end user, whose common sense is going to vary because everyone’s psychology is different to perceive, understand or judge a product.

I remember an incident with one of my client about ‘WebEx’s Go To Meeting’ application. My client was unable to join the meeting and failed to understand what was going on in application’s background. I was able to join the meeting easily as I have used Go to meeting application multiple times. But first time when the user loads the application in system then it takes quite some time to load it completely. In my case when I installed the application for first time, for a moment, I felt that the system got stuck. There are high chances that people seeing a loading webex ball (not the progress bar) for quite a while will end up closing the session to start all over again.

I asked few questions to my client to ensure that he is doing the right thing. He confirmed that he has Java installed on his system and also removed cache from the browser. After half an hour he informed that he is still getting a WebEx window which still said, “a moment please…” and the WebEx ball kept moving on the page.

My client was clueless as to what was going on in the background of this application. The unwanted pressure of not being able to join the meeting kept building up.

Technology is there to help us to be more productive rather than making us technology-handicapped. Some of us might have blamed the client for not being able to use the product but that would have been very wrong.

Again it’s no common sense to make the user wait for 10-15 minutes to load the meeting application without showing a progress bar with percentage of the activity that got completed in background.

If System does not give feedback frequently to the end user then it is not a common sense to understand what is going in background.

If Help (or FAQ) does not cover every possible aspect of the product then it is not a common sense to know the product.  (You can also add if user do not understand the help then it is not a common sense to know the help’s intention.)

If Design does not help end user to use product then it is not a common sense to use the product with ease.

I do not accept this common sense terminology when it comes to application testing because I do think that everyone’s psychology is different and this will majorly affects the usability of the product.

You missed that scenario!

“You missed that scenario!” ever heard client saying that when you showcased your completed work?

In one such situation, the client was upset because they found an issue in production. I tried to convince her by presenting what we did and how we carried out our testing. I also assured that we will take care of such scenarios.

I was curious to know more about the production issue, wondering how I failed to recognize that particular scenario!

According to my client the issue was with a particular record not fetched using search functionality. When I found the pattern then, it was like search query fired with space followed by underscore would not fetch the correct results. I discussed my observation with developer and they informed that “technology” does not allow this kind of combination string in search query. It has technology limitations.

If I would debate whether this is an issue or not, nobody wins, because you can’t deny the fact that end user might use this kind of query to search results and technology has no answer to it.

The point is to convince the client that 100% testing or bug free software is a marketing term, in reality this may not be possible. Quality of the product depends on designs, development, time, technology, testing and decisions made against the bugs.

If tester can’t find bugs, it does not mean that there are no bugs or testers are not doing their job or being careless. What I would say is a skilled tester would help you to do good enough testing and help you to release good quality product.

May be we can avoid this kind of situation by

  • Educating client about testing completely is impossible.
  • Educating client about time span given to the testing. If you think you may require more time then justify your need in appropriate way.
  • Showing possible scenarios or combinations to the client with how much time it will take to do testing so they can understand the complexity involved in testing
  • Ask questions to stakeholders with respect to understand end user expectations and usage of the software
  • Keep note of every possible tests and your observations. Not everything can be written but definitely everything can be recorded in a tool called mind.
  • Focus on non-reproducible bugs. Just don’t leave them because you are not able to reproduce.
  • Catch hold of log files. If you can’t, ask involved stakeholders to provide it.

Last thing – Never feel demoralized. Instead, learn from it and understand your stakeholder’s expectations and keep educating the client.

Confirm your Assumptions while testing

I have been very careful about my assumptions while testing software. Many times I confirm certain things if I am not sure about it for eg. functionalities, flow or purpose of the feature.

Recently I was testing a web application for the client. He provided all the details about the URLs, login credentials and brief about the functionality.

Being a tester, the excitement was always there to test the software.  It was first time I was testing given web site. Whatever questions I had in mind I asked to the client in the first meet. And I thought remaining questions will have answers once I start exploring the software.

I was confident about my work so I presented it to the client. After few minutes I got a call from him. I thought he is going to appreciate my work.

He informed me that I have not tested the given application in correct environment. I was startled on listening this. However I kept calm and instead of reacting, I wanted to find out what exactly happened.

Actually client provided QA environment link but I was led to production link present inside the QA environment. I did not realize till he pointed out the difference between two URLs.

I figured out that while testing the application I found new areas which led me in a new direction and left me completely unaware of the URL changes that happened while i was exploring them. Later when I got back on track (the correct URLs given by client i was supposed to test), I figured out i was in a wrong environment, the one i was not suppose to test.

The lesson I learnt is – despite you being confident about your work, just confirm your initial hour’s testing session’s output with the client to know that you are on the right track, because it may have a direct impact on stakeholder’s health and your service is affected eventually.

Note: You need to know what your assumptions are while testing.

Think twice before accepting rejection of non-reproducible bugs

It’s a story about two testers who were testing the same application. Their client had direct access to those machine which these testers were accessing remotely using software.

Tester A found a bug and she reported to the client. Client declined a bug stating that they were not able to reproduce the issue. For a minute she looked at the issue and close without giving a second thought.

After a week Tester B raised same issue and client again declined the issue giving the same reason. Tester B was restless because he was not able to understand the reason of not able to reproduce the issue. He tried on another machine and also confirmed with Tester A but all his efforts were in vain. He did not have access to log files and it was impossible to get at this juncture.

He was above to give up on the bug but he kept asking himself what if it will not get fixed. What could be the consequences? Does client afford this issue if it occurs in future? Does it affect testability or any other quality criteria of the product?

He realized that if this issue is not fixed then they will not be able to test the functionality. He explained the consequences next day to customer and customer understood it. They were ready to fix the bug inspite of non-reproducibility of the bug.

Here the lesson is many times it happens that your customer will not be in a mindset to accept non-reproducible bugs however its tester’s job to convince them by providing as much as information possible.

Sometimes client may fail to think the consequences of the bug and that leads to rejection of bugs.

Client requires enough information to accept a bug for fix.

A tester is a torch bearer who leads customer in right direction that would help them to improve quality of the product.

Tester provides information but it makes difference if you provide useful information.