What Makes a Great Software Tester?

I've learned to do my homework before jumping into anything technology-related. Although software can be updated, sometimes there isn't much you can do with hardware choices.

I always appreciate reading thoughtful feedback about the products I want to try. Even for something as simple as a mobile app, a few reviews can give me a good starting point to test. However, it is ultimately my own testing that determines whether I will keep using it. I try to skim through the surface feedback and get to the real use cases. In other words, I'm not going to buy a shovel if the reviewer hasn't used it to dig a hole!

It's difficult for any software or hardware provider to deliver a perfect product. In my experience, nobody has produced a defect-free product, not even Apple. Just visit any Apple forum and in between all the happy stories you read, there are plenty of negative ones.

So who are all these people testing products and what makes them good at it?

Characteristics of a Tester

Anybody can play an integral role in testing. Every professional in the world must decide on how to implement new technology and procedures. In order to do so, they have to weigh the pros and cons associated with them.

Provide Constructive Criticism

While discussing any issues, defects, requirements or clarifications with developers, do not use words that point to their personal characteristics. Be very tactful in the describing issues. Try not to point fingers at the person who developed the software or who collected the requirements for it either.

The #1 rule of good criticism is to be specific.

Communication Skills - Oral and Written

As a software tester, there are situations when you have to interact with different people - analysts, designers, developers and other testers. Therefore, it is necessary to explain yourself to different people in a way that is clear and concise. Simply stating a defect won't help if it's not clearly understood by the receiving team.

Be clear and concise in your oral and written communication.

Critical Eye

Look out for details. As a tester, you should be in a position to look out for any implicit or unstated requirements that need clarification from the clients. Always check for "what if" scenarios and get the answers. Think in a multi-dimensional way about a problem or requirement.

For example, during testing of a home banking application, there was a requirement to display all balances in dual currencies (Euro/local currency). The business requirement stated the list of screens pertaining to the withdrawal and Balance Inquiry modules for which this requirement was supposed to be implemented. On analysis, this requirement was affecting more places such as the screen in which the user checks out the history of transactions, makes a deposit, or sets up a standing instruction to the bank. While discussing the issue with the client, I found that they thought this was implied.

Have a critical eye for minor details, even if others think they are insignificant.

Do Not Assume Things

This is a continuation of my previous point – a tester should not assume any of the requirements, issues, problems or defects. For example, never assume that in a screen where data is captured, a field that is labeled “Clear” will clear the entire content. Ask more questions and get the affirmations from the respective persons.

Also, remember that it is necessary to test the software from the end-user's perspective and not just compliance with the requirements given by the client.

Never assume anything. It might not be as true as you think!

Be Empathetic

Listen to the developer or business analyst who has developed and collected the requirements carefully. Try to understand the reality and limitations of the testing project. Conflicts will arise but always try to resolve the limitations or issues in different possible ways.

Develop good rapport with other teams; it helps!

Effective Follow-Up of Issues

Many times, defects are written and deferred to the next release. Then, at the start of the next release, not all of those issues are picked up and fixed. The status of defects that are left over from previous releases need to be discussed at the beginning of every release with the business analyst and development team. Also, any issue that has not been converted to defects need to have a closer follow-up. These need to be documented as open issues at the end of the testing activity.

Be good with follow-ups!

Good Reviewer

Be a good reviewer and look out for inconsistencies of a particular requirement across different sections. Review all user documentation apart from testing the software. Also, check for inconsistencies in the description of the software, such as the glossary and index. This enables you to easily search topics of the user's choice.

Sharpen your reviewing skills!

Test Environment

Putting yourself in a proper position will allow you to better evaluate application and environment issues. If you find something works in one situation and not in another, then you can better determine what factors are directly related to the issue.

Create a test environment to isolate issues.

To sum it up: as a tester, you need a special set of interpersonal skills to go along with your technical and functional skills. And don’t forget to practice a lot!