I’m happy that my question “How to evaluate tester's work?” was so vividly discussed in Software Testing Club forum. I was interested how to know that this tester is a good one and the other one isn't qualified enough.
I’ve got many interesting opinions and realized that this question was rather essential for modern managers of testing/QA teams.
Each company and each manager chooses its own approach to evaluation of their testing team members. It isn’t limited by the count of found bugs . There are different interesting ways and methods. And each of them has really high practical value.
Mostly my attention was attracted by two major points:
- Evaluation shouldn’t be measured by money – penalizing or rewarding;
- Each team member may participate in the process of their co-workers’ evaluation.
There are some schemes of evaluation implementing these points.
Of course, the quality of test-plan is one of the main issues. And the quantity of valid/invalid/rejected bugs can be observed here. But this is just specific metrics that give very unreliable results because there are different situations and different circumstances in which tester may find himself during the work on his part of the project.
The feedback from colleagues is very important in this case. Some managers call it “360º review”, the others use “the peer review “. These methods are the most meaningful and give the most visible results. People working together everyday are the best sources of information. They are constantly evaluating one another's work. They communicate. They have the common goal, the project. They depend on each other as testing is usually team game. And there’s a lot of information they notice about each other’s work.
I think colleagues’ opinion is the best way to evaluate. If people can work together, fulfill the tasks, rely upon each other – they are good workers, they are a team. And the results of such interaction are positive for the project.
Easy way to plan your tests
I’m sure such notion as “test plan” is familiar to all testers. But sometimes it seems that there’s not enough information about such essential thing for the testing process. Here I’ll try to summarize the information I managed to get from different Internet sources.
First of all, test plan is the document containing all the information about the whole test process – from the project description, strategy, time schedule, criteria of test’s starting and finishing to the tool set, special equipment and skills. Also risk assessment and possible resolutions should be taken into account.
Good-quality test plan should meet the following minimal set of questions:
1. The project under testing (information about the system, application, equipment)
2. What part of application should be tested (the list of functionalities, testing subsystem)
3. The way you’re going to do testing (test strategy – types of testing and their use for testing the project)
4. Steps of testing execution (preparation and collecting all necessary information, testing, analysis of results)
If you answer to these questions in your test plan, it means that now you have a good draft of the official testing plan documentation.
But there are cases when tester simply has no extra time for preparing the documents carefully or the proper documentation isn’t an essential part of the testing process. Then the best way for quick and easy self-organization is preparing a check-list. Usually check-list is a part of the test plan, so called “features to be tested” part. But it can exist separately and be very helpful for the tester.
Here are some points to organize your quick check-list:
1. Logically separate your application into different independent modules
2. Specify available functionalities for each module
3. Prepare the lists of possible testing for each functionality in the form of the test-cases names without any additional documents or specifications.
4. Check all the points one by one.
This variant is rather convenient and saves time for fulfilling important and urgent projects. I hope this short note will help you organize your testing process in more successful way!
First of all, test plan is the document containing all the information about the whole test process – from the project description, strategy, time schedule, criteria of test’s starting and finishing to the tool set, special equipment and skills. Also risk assessment and possible resolutions should be taken into account.
Good-quality test plan should meet the following minimal set of questions:
1. The project under testing (information about the system, application, equipment)
2. What part of application should be tested (the list of functionalities, testing subsystem)
3. The way you’re going to do testing (test strategy – types of testing and their use for testing the project)
4. Steps of testing execution (preparation and collecting all necessary information, testing, analysis of results)
If you answer to these questions in your test plan, it means that now you have a good draft of the official testing plan documentation.
But there are cases when tester simply has no extra time for preparing the documents carefully or the proper documentation isn’t an essential part of the testing process. Then the best way for quick and easy self-organization is preparing a check-list. Usually check-list is a part of the test plan, so called “features to be tested” part. But it can exist separately and be very helpful for the tester.
Here are some points to organize your quick check-list:
1. Logically separate your application into different independent modules
2. Specify available functionalities for each module
3. Prepare the lists of possible testing for each functionality in the form of the test-cases names without any additional documents or specifications.
4. Check all the points one by one.
This variant is rather convenient and saves time for fulfilling important and urgent projects. I hope this short note will help you organize your testing process in more successful way!
'Blame game' between tester and programmer
A few days ago, I asked a question on the Software Testing Club forum: "Who's to blame for the bug found by the end-user: the programmer or the tester?"
Now, I'd like to summarize the results. The most significant idea is that all team members have to take the responsibility. In fact, even when white-box testing is provided, there's no opportunity to predict all possible situations of software use. There’s no way to create so many different test scenarios to describe all possible variants of software use by the deadline. However, every user working with the software creates his or her own special scenario. The more users work with the product, the more use variants they propose. So, there is a greater opportunity to find new bugs.
Perfect software cannot be written. Perfect tests should cover as many variants of software use as possible. The number of bugs found by the end-user will be reduced, but the bugs won't disappear at all, and what is the most important, no particular team member is to blame.
That's a usual working situation, and the task of the highest priority is to fix bugs and to provide a user with a better product. That's the guarantee of high quality.
Where does the tester's work end and the developer's work start?
Or
Some words about working together.
In most cases, testers find bugs and report them to developers. If you're a tester, there are situations sometimes when you know the problem cause and can suggest a pretty good solution to it. If there is a serious bug that requires special knowledge, you can talk to the developers in person to discuss the problem and find a solution faster.
If you have the skills and the project source code, you might be able to solve the problem by writing some code, but coding bug fixes is almost always the developers' prerogative. So, if you understand the nature of the bug, you describe it and provide good examples, which helps the developers find a solution faster. This kind of cooperation is a key to successful testing. Testers shouldn't try to do everything by themselves.
There's often no need to discuss each minor bug with the developers. The bug-tracking system is more helpful in this case. Just create a bug report with a detailed description and the issue should get handled by the normal process. Sometimes, though, you recognize that no delay is acceptable. So, log the bug in your tracker and than go discuss it in person with the developers. That can also help you to gain authority as a qualified specialist.
There are so many ways to communicate that team members on the same project may not have much personal contact and, as result, problem reports are often misunderstood. Success depends on how well team members communicate to achieve their common goal. Testers and developers should respect each other's opinion to help them find and fix bugs fast and effectively.
There isn't a simple answer to the question of where a tester's work ends, but communication and respect will make your work easier and more appreciated.
Some words about working together.
In most cases, testers find bugs and report them to developers. If you're a tester, there are situations sometimes when you know the problem cause and can suggest a pretty good solution to it. If there is a serious bug that requires special knowledge, you can talk to the developers in person to discuss the problem and find a solution faster.
If you have the skills and the project source code, you might be able to solve the problem by writing some code, but coding bug fixes is almost always the developers' prerogative. So, if you understand the nature of the bug, you describe it and provide good examples, which helps the developers find a solution faster. This kind of cooperation is a key to successful testing. Testers shouldn't try to do everything by themselves.
There's often no need to discuss each minor bug with the developers. The bug-tracking system is more helpful in this case. Just create a bug report with a detailed description and the issue should get handled by the normal process. Sometimes, though, you recognize that no delay is acceptable. So, log the bug in your tracker and than go discuss it in person with the developers. That can also help you to gain authority as a qualified specialist.
There are so many ways to communicate that team members on the same project may not have much personal contact and, as result, problem reports are often misunderstood. Success depends on how well team members communicate to achieve their common goal. Testers and developers should respect each other's opinion to help them find and fix bugs fast and effectively.
There isn't a simple answer to the question of where a tester's work ends, but communication and respect will make your work easier and more appreciated.
Subscribe to:
Posts (Atom)
