10 Qualities that Can Make You a Good Tester

What makes you think you are good at testing?

The question still bangs in my ears whenever it comes to an interview. This was the question I was asked at the beginning of my career as a software tester. The interviewer asked some aptitude questions as usual and suddenly he threw this question to me. I was almost speechless. Most of the time, we think we are good at something because we are doing it or maybe we presume we are good at it.

After spending almost a decade in the industry, when I look back I can understand the importance of the question and therefore today I am going to present you a list of points I have jotted to make myself feel that I was/am good at testing.

Let’s take a look. On a side note, you are invited to add your point to the list and we will accept it with open arms.

10 Qualities that Can Make You a Good Tester:

qualities of a tester

So, here you go. Please prepend the condition “you are good at testing when” to each point and read through:

#1. You understand priorities:

Software tester unknowingly becomes good time manager as the first thing he needs to understand is a priority. Most of the time, you are given a module/functionality to test and timeline (which is always tight) and you need to give output. These regular challenges make you understand how to prioritize the things.

As a tester, you need to understand what should be tested and what should be given less priority, what should be automated and what should be tested manually, which task should be taken up first and what can be done at last moment. Once you are master of defining priorities, software testing would be really easy. But…….but my friend, understanding priority only comes with experience and so patience and an alert eye are the most helpful weapons.

#2. You ask questions:

Asking questions is the most important part of software testing. If you fail at it, you are going to lose an important bunch of information.

Questions can be asked:

  • To understand requirement
  • To understand changes done
  • To understand how requirement has been implemented
  • To understand how the bug fixed
  • To understand bug fix effects
  • To understand the product from other perspectives like development, business etc.

Can be beneficial to understand the overall picture and to define the coverage.

#3. You can create numbers of ideas:

As I have written in almost my all posts, software testing is about ideas. When you can generate numbers of ideas to test the product, you stand out of crowd as most of the time people feel self-satisfaction after writing ordinary functional and performance test cases.

As per me, a real tester’s job starts only after writing ordinary test cases. The more you think about how the product can be used in different ways, you will be able to generate ideas to test it and ultimately you will gain confidence in the product, customer satisfaction and lifelong experience.

So, be an idea generator if you want to be good at testing.

#4. You can analyze data:

Being a tester, you are not expected to do testing only. You need to understand the data collected from testing and need to analyze them for the particular behaviour of application or product. Most of the time, when I hear about a non-reproducible bug, I silently smile. There is no bug that is non-reproducible. If it occurred once that means it’s going to pop out for the second time. But to reach out to the root cause, you need to analyze the test environment, the test data, the interruptions etc.

Also, as we all know, when it comes to automation testing, most of the time it’s about analyzing test results because creating scripts and executing them for numerous time is not a big task but analyzing the data generated after execution of those scripts, is the most important part.

#5. You can report negative things in a positive way:

yes, you read it correctly. A tester needs to learn tactics to deal with everyone around and needs to be good at communication. No one feels good when he/she is being told that whatever they did was completely or partially wrong. But it makes a whole lot of difference in reaction when you suggest doing something or rectifying something with better ideas and without an egoistic voice.

Also details are important to provide details about what negative you saw and how it can affect the product/application overall.

No one would deny rectifying it. :)

#6. You are good at reporting:

For the whole day, you worked and worked and executed numbers of test cases and marked them as pass/fail in test management tool. What would be your status at the end of the day? No one would be interested in knowing how many numbers of test cases you executed. People want a short and sweet description about your whole day task.

So now onwards, write your status report to the client as – what you did (at max 3 sentences), what you found (with bug numbers) and what you will do next.

#7. You are flexible to support whenever it’s required:

The duty of software tester does not end after reporting a bug. If the developer is not able to reproduce the bug, you are expected to support to reproduce it because then only the developer will be able to fix it.

Also, tight timelines for software testing makes many testers ignorant for quality. The right approach should be proper planning and an extra effort to cover whatever is required.

#8. You are able co-relate real time scenarios to software testing:

When you are able to co-relate testing with real life, it’s easy. Habituate yourself to think or constantly create test cases about how to test a train, how to test a vegetable, how to test a monument and see how it helps in near future. It will help your mind to constantly generate ideas and relate testing with practical things.

#9. You are a constant learner:

Software testing is challenging because you need to learn new things constantly. It’s not about gaining the expertise of specific scripting language; it’s about keeping up with the latest technology, about learning automation tools, about learning to create ideas, about learning from experience and ultimately about constantly thriving.

Also read => 10 Tips to Survive and Progress in the Field of Software Testing

#10. You can wear end user’s shoes:

You are a good tester only when you can understand your customer. The customer is GOD and you need to understand his/her needs. If the product does not satisfy customer needs, no matter how useful it is, it is not going to work. And it is a tester’s responsibility to understand the customer.

With this, I am ending this article with a hope that I could cover most of the points, which are making me a good tester. What about you?

About the author:This post is written by STH team member Bhumika Mehta, a project lead with 7 years of experience.


#1 Sheetal

simply awesome list. wish all testers have these qualities eventually.

#2 Nandini

Why a developer who fixed the bug, would tell us how he fixed and how we would be able to understand it, we are not whiteBox Testers?
So what are the things in which manual tester would be interested in when this question asked “To understand how the bug fixed”? So that we can grow(towards becoming a whitebox tester) and understand and suggest to do “thisFix” in code so that next time “thisBug” wont come?

#3 Nandini

@Author: Please post the answer as this a real time situation I am facing.

#4 Bhumika Mehta


To understand how the bug fixed does not mean we need to look at code level changes and need to become whitebox tester.
It actually means to understand the logic used and from the experience understand that the logic has /had not affected any other areas. Also, if the logic worked correctly, why it has not been applied to other similar areas of product.
Basically understanding the bug fixing gives an experience to a tester about –
1. logic applied
2. impacts of logic applied
3. searching similar areas of product
and ultimately it prepares the tester for future. Because this kind of experiences help in future and we can suggest the fix for similar bugs.

I hope I answered your question.
Please let me know, if I can help with anything else.


#5 Neoanderson27

“To understand how the bug fixed ?”
First, we have to find our selfs “what kind of testers we are?”. I found my self as a “functional tester” has around 3 years in ST. Manual Testers should have knowledge (interest) how the product (application) works.. We should know the functionality of module not the logic of module…

White Box testers should know the logic of code how the code coverage works and etc…
But, Manual Testers should know the functionality of (module, phase, product/application)…

#6 Shuza Haider

To understand the requirements :
black box Testers should have knowledge, – how the product / application works.
They should know the functionality, validity, security, GUI of module …….

#7 Bibhishan

Nice Article sir…

Looking for new articles..

#8 Priyanka

Great one!! Looking forward to some other great posts as well…..

#9 Avishek

Hi Bhumika,

Very nice post you updated.

I have a few small querry for the point #2. Please find my question inline to your points:-

To understand requirement
#This can be possible from the SRS or from the BRD
To understand changes done
#This thing can be possible from the bug report that a tester posts for it .
To understand how requirement has been implemented
#How this thing can be know? This thing knows only TL, PM, DBA. Why this cruical info will share to others testers apart from Test lead. I think this will compromise the security of the project. I might be wrong please let me know.
To understand how the bug fixed
#By knowing this thing , will we be given any access to test the core of the project / get the provision to access the code? how?
To understand bug fix effects
#From whom to know where the new code will effects in the projects? does the developer know the exact page or in which functionality or in the UI it will effect?
To understand the product from other perspectives like development, business etc.
#This thing can be known.


#10 Preethi Krishnan

Hello All,

Are you suddenly facing an issue with the loading of this site – https://www.softwaretestinghelp.com – or is it just me? :-(

The outlay of the website is not getting displayed properly and I am finding it difficult to browse through it! :-(

#11 MerLyn

Great article!.
I see myself nodding my head in agreement to your key points as I read through them. Of course, one can only expound and provide more insights of what other details are needed to be better at it depends on what kind of testing specialization does one individual do. Keep up the good work!

#12 Noor


Hi Nandidni, the developers would tell us what did they do to fix the defect as a part of resolution notes for that particular defect and that would help testers understand the fix and what other areas testers would have to do regression around for that particular defect fix. Basically by knowing what the fix was (Code) would give QA an idea of what other areas that code may have touched or have impacts on. QA than not only re-test the defect fix but will have to do regression testing around the impacted areas of the application where the code fix may have touched…

Hope this helps!

#13 Trang

Very helpful article. Thanks for the post

#14 chandrasekar.M

Hi Bhumika,

I have to a doubt, You are saying that customer is God. Ok but there is chance to God also may do mistake if you remember any god’s history. This is no joke. I am asking seriously. Why don’t we have guts to pointed out if customer has done any mistake or their understanding is wrong. Obviously you might have faced this kind of any situation. can you share that moment and How did you handle that situation.

#15 Ganesh

Nice Article…

#16 Bhumika Mehta

@Ganesh, @Trang, @Bibhishan , @Priyanka, @MerLyn

Thanks for the continued readership and glad to know that you liked the article and it was useful.

#17 Bhumika Mehta


Glad to know that you liked the post.

Answers to your queries :
To understand how requirements have been implemented
This point indicates basically what logic has been applied. Also, this means what kind of compromises had to be done to implement the requirements, what kind of issues faced while implementing the requirements and are there any known loopholes about the requirements implemented. Answers to these questions can be received from developers and management provided the tester proves how essential it is for him to know about it.

To understand how the bug fixed
I have already answered this query while replying one of the reader’s question. Please refer the same.


#18 Brinki


Simple and Good article

#19 yaser

Nice article

#20 Suresh

Hi Bhumika,

Very nice post you updated.
If possible can you post article about software metrics…

#21 Bhumika Mehta

@Brinki, @Yaser, @Suresh,

Thanks for the readership…..Tune in for more such articles :-)

Happy Testing as always.

#22 Bhumika Mehta

@Chandrashekhar M,

Thanks for your readership and your question.

Meither I nor our history ever claimed that we should follow the god blindly. By saying the customer is god, what I meant was he is the one who gives business.
For many times in my career, I have faced situations where –
1. Customer reported a bug and blamed that QA did not report it even after conveying the scenario was invalid.
2. Customer demanded to implement or change the requirement in impractical way
3. Customer asked to repeat testing cycles even though there was no recent change in code.

How to handle the situation?
well, as I said, I repeat – customer is GOD as he gives us business, we need to be slightly strategic while handling these kind of situations.
1. We can prove that what ever he thinks / wants to implement is wrong / impractical in polite words.
2. We need to show the real time examples where the idea or the demand was a failure.

I think I answered your question. Please let me know if I can help with any other query.


#23 Raghavendra


It`s a very good article. It will help testers to grow in software testing field by giving innovative ideas to manager as well as customer.

#24 stella

I wanted know about healthcare domain testing process . How its done ,what tool to use to do those test etc ..Can someone guide me .

#25 Brine

Very nice list…

#26 Anamaria

Very nice topic.
If possible can you post article about security testing for web application?

#27 Anand

Hi Bhumika.

Really nice article especially 6th and 8th point.

#28 Azam Khan

Hi Bhumika
Nice article point no 8 is awesome .
Could you please explain RTM with examples.

#29 Deepak Mahapatra

Its really awesome..Thanks a lot….

#30 Sheikh

Please i want some help from your side .
i am new in this field please give me some tips to test websites manually and how can i polish my skills?
I will be waiting for your answer

#31 Sebastin

Really Good Explanation…..
especially 5 and 10

#32 Rahul

Nice Article

#33 Ankita M

Good Point

#34 Shiven

Great read and very useful information! Thank You!

#35 Raguram

@author, What can be boom in future??….

Automation testing or Manual testing???…..and explain me with gud exmples.

#36 kaveri

Thanks for the wonderful information

#37 sivajiraw

nice posting… and its really useful, thank you so much…

#38 Maleshwar Kinagi

Superb artical

#39 Deepak

Nice to see this article and also got good question from Bhumika mehata your assumptions right .

#40 Deepak

Nice to see this article and also got good question from Bhumika mehata your assumptions were right .

#41 Anoop

nice posting… and its really useful thank u very much.

#42 sai

halo…..guys recently i got a job in testing platform soo…can any one help me out that how can i learn more testing skills so….plzzz can any one help me out guys…..
my id saikrn469@gmail.com

#43 Mohak Thaker

Hello ma’am

Some time client post a bug which is not a non-reproducible bug

I agree with you that “If it occurred once that means it’s going to pop out for the second time”

in this case, I try to reproduce the same bug with all different scenarios which are related to the functionality in which the bug has been found but in the end still the bug cannot be reproduced

in this case, I also reach to my TL, Manager and explain the scenario that as our end we are unable to find the same bug which is reported by the client.

in this kind of scenarios what should we have to do to find out the bug?

Leave a Comment