Characteristics of a Tester

Introduction

All professions in the world have certain traits or features attached to it. Software testing is no exception to this. Many a times you must have seen that as a tester your inputs are not being accepted in the real time software projects. You must also be working overtime for no fault of yours but due to bad planning by others. You are often asked to "complete the testing" or "windup testing" but also asked to ensure to deliver a defect free product. What should you do to be prepared in such situations? How to tackle the different sections of persons in the software projects? What characteristics portrays a successful "software tester"? Read on…

Communication skills - oral and written

There are situations when as a tester, you would have to meet / interact with different sections of people - the business analysts, the design team, the development team and other testing teams. In those situations, it is necessary to explain yourself (the issues/problems/clarifications that you may have) to them. It has to be conveyed in the correct way so that the person(s) sitting across the table is/are able to understand clearly. Also, it is very important that any defect that is written by you has to be understood clearly by the receiving team.

Be clear/ concise in your oral and written communication skills.

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 multi dimensional way about a problem/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 impacting more places like the screen in which the user checks out the history of transactions, or does a deposit, or sets up a standing instruction to the bank. On discussing the issue with the client, it was found that they thought that this was implied!!

Have a critical eye for minor details though others might think them as insignificant.

Do not assume things

This is the continuation from previous point that as a tester it is very important that you should not assume any of the requirement / issues / problems / defects. For example, never assume that in a screen where data is captured a field labeled "Clear" clears the entire content, though it is pretty evident. 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 may not be true as you think!

Convincing skills

It is a skill to convince and explain to a person who has developed the software as to why a defect report written is indeed a defect. Put forth this in such a way that the developer also starts thinking along the lines of the scenario given in the defect report / requirement. Remember in such situations to put you in other person's shoes and speak accordingly. Avoid using accusing words, do not get into any arguments and do not rise to any bait a developer may throw at you. Concentrate on the issue and not on the person.

Also, while deciding the end of testing activities, it is important to bring out the impact of the open defects in the software and the implications to the business analyst / client or whoever is the logical end point contact. It is necessary to push your point through either to continue with further testing activities or to stop testing.

Develop good convincing skills!

Be factual

While reporting a defect or clarification of a requirement, be as factual as possible. Do not bring in your own suggestions / views into picture. Do not use words that describe the type of work or the person who developed the software.

For example, do not bring in words like, "badly developed software", "often crashing software", etc. Do not spell out such phrases even during interaction with the developer. Such activities will only be counter productive. This is result in people not viewing your defect reports with seriousness.

Be a good reporter of facts!

Effective listening

While discussing a defect report / requirement clarification, give a good hearing to other person's view or perspective. Understand the limitations of the software and try to find ways to resolve such issues. For example, if there exists an issue that is pertaining to display / functionality in one particular browser version, ensure that it is listed as one of the "Known issues" in the Release Notes or Limitations section or in the Read me file.

Be flexible whenever required!

Provide constructive criticism

While discussing any issues / defects / requirements clarifications with developer / business analyst do not use words that are pointing to their personal characteristics. Be very tactful in describing issues / defects and try not to point fingers at the person who developed the software or who collected the requirements for the software.

Be empathetic

Listen to the developer / the business analyst who developed / collected the requirements carefully. Try to understand the reality and limitations. Do not argue over trivial issues. Try to resolve limitations / issues in different possible ways.

Develop good rapport with other teams, it helps!

Effective follow up of issues

Many a times, defects are written and deferred to next release. At the start of next release not all of them are picked up and fixed. The status of defects that are left out from previous releases need to be discussed at the beginning of every release with the business analyst / development team. Also, any issue that has not been converted to defect needs to have a closer follow up. This needs to be documented as Open issues at the end of the testing activity.

Be good at follow-ups!

Good reviewer

Be a good reviewer and look out for inconsistencies of implementation of a particular requirement across different sections. Review all user documentation apart from testing the software. Check out for inconsistencies in the description of the software, look for glossary and an index. This enables for easy search on topics of user's choice.

Sharpen your reviewing skills!

Conclusion

As a tester you need special set of interpersonal skills more than the technical and functional skills. More importantly patience should be there. Make a start, be aware and practice.