10 Qualities that Can Make You a Good Tester

What makes you think you are good at testing? Why do you qualify as a tester?

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

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 behavior 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 of 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 to 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.

#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.

*************************

Update:

10 Skills to Be A Great Tester: How A Tester Can Be A Great Tester

There is always room for improvement and making things better.

If starting as a QA fresher and spending a few years in the field have not changed you from tester to a Good/Great tester, this article is for you. Read on –

Testing, reporting, and finishing a task is something anyone can do after a while with experience and training. But, being a tester is so much more.

#2)Good communication

A great tester has excellent communication skills and uses it to ask questions, to present his opinions and to discuss critical scenarios/impact thoroughly.

Good communication skillscan beacquired easily by joining communication training sessions and practicing the same regularly. Please note thatgood communication really does not mean, writing or speaking fluent English alone, although that helps.

#3)Multi-tasking abilities

Multi-tasking abilities are the demand of today’s era.

A great tester must juggle multiple activities, such as:

Generate and execute test ideas

Design test cases

Write effective bug reports

Work on multiple projects and provide updates.

Not only that, you should also prioritize and schedule your activities accordingly.

Multi-tasking abilities need practice and the right mindset.

#4)Quick learner

A great tester is a quick and self-learner.

You do not HAVE to learn new stuff, you should WANT to learn it. You should be able to update yourself with new technologies, processes, tools, skills etc. on a regular basis.

Quick learning cannot be taught but it can be developed with patience, planning, practice, and perseverance.

#5)Passion for testing

You have got to love your job.

A passion for delivering quality, for providing better user experience, for generating new ideas, etc. is critical.

It is an absolute game changer. You will never be bored. You will never overlook something to test. You will never report a case without thoroughly researching. You will never ignore a corner case. Most importantly, you will not look at testing as a thankless job. :)

#6)Team player

Being a team player is a must for every job but it takes on a whole new dimension because we have to deliver bad news. To do this well, you have to be understanding and giving. Don't play the blame-game. Stay positive.

Rejuvenating this skill is very important to be a great tester and a good human being.

#7) Think and act as an end-user

Quality ultimately means end user’s satisfaction.

Irrespective of what the requirements say think about the end-user impact. This is easy because we are software users too even though we are professional testers.

With continuous study, observation, and comparison, end user’s perspective can be cultivated.

#8)Analytical abilities

Our primary responsibility is to help make software as bug-free as we can. Every bug follows a pattern and a great tester is always good at observing that pattern and reporting all the bugs of the same pattern.

In-depth analysis and creativity help in nurturing good analytical abilities.

#9)Be an inspiration and a role model

You are right; this has nothing to do with testing. But I believe we have plenty of scopes to spark inspiration in people we interact with every day. You might be the last one in a queue, but in a few minutes, there will always be someone behind you. So, no matter what position you are in, there are people looking up to you.

In a team, if the team lead often gets into arguments with the developers, naturally the team will too. If a team member does not follow a template, the others might think it is OK to not follow a template.

Being aware that every action of ours resonates somehow in another around us should make us aspire to inspire without even trying.

There are plenty of ways to leave your mark on otherwise mundane tasks:

Be the best at what you do

Being on time

Paying attention to detail

Coming up with a new best practice

Finding a problem that could have caused a major breakdown

Learning a new skill and volunteering to teach your peers

Being courteous in your communication

Gather a reputation for being the best tester/best defect reporter/or best metric generator.

#10)Practice empathy

Once again, this might not feel like an attribute testers need. Especially since there is a lot of talk about how testers should guard, protect and guide their defects to resolution and all.

But testers have to have the quality to be able to feel and not just be automatons. It helps the testing process too.

Take, for example, a brand new application that is just being integrated as a trial run. Would you just come crumbling on it, wage a war and report that it is fit for nothing? Or would you test it sympathetically and try to find problem areas so you can help the developers aid further improvement?

Let’s look at it from a real-world example perspective. You just finished building a chair. Would you jump into it or sit carefully the first time? The later, isn’t it? After you are confident it holds you then start adding unusual weights etc.

Testing in the initial stages has to be subtle, slow and kind.

Also, empathy can help you be a better team player – not only within your team but with external teams as well. When in doubt, be kinder than you need to be.

I hope this list gives you an idea as to which area you need to work at to be a better software tester.

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

By the way, did I miss something? I would love to hear from you.

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?

44 thoughts on “10 Qualities that Can Make You a Good Tester”

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?

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.

“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)…

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.

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!

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…

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.

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.

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.