For getting a testing project/job/contract we have not to forget that, to get it, the most important thing is not the testing skill.
Most of the time people interviewing you are not testers or not testers with the same ideas like you about testing.
The things that will matter more can be:
And there is a huge list of items that come before the actual testing skills, and this should not be frustrating as it its an unwritten rule in every area.
Participating in EWT again made me re-think of impossible problems. I don’t think a tester should spend too much time figuring out what a functionality should be or trying to guess the expected behavior. A tester should though recognize an impossible problem or to clarify the requirements.
First of all we need to determine the oracle, the set of references that tell us that something is a bug or not. And for this we need to clarify the requirements for things that are documented and for things that are not documented.
What is actually metrics? Is basically a form of control and monitoring. You need some results to trick the employees somehow, give the sensation of some sort of advancement. As I stated before I don’t believe too much in this.
In a lot of companies the main objective for a tester is to become “leeead” (long “e”), because the work seems super relative to everyone. Of course this sole motivation makes an annoying environment eventually and the lack of interest will eventually kick in.
Sometimes fake objectives are drawn to look nice, which of course are never followed.
Since automation looks cool in name the tendency is to fill 100 % with tasks related to this. Its more easier of course to measure it. No one cares if the tests are made shallow covering a small basic scenario only. Till of course major failures, complains from customers etc…
But I have to add this document as a start point to use metrics http://www.kaner.com/pdfs/metrics2004.pdf
Since this is a hot subject on the software-testing mailing list I though I put some lines about it.
First of all I myself have little clue on how a good metric for testing should be. I know this causes a lot of problems in testing.
I am not saying not using a metric at all should be the solution because its impossible in an organization. There is the need for a formal one at least.
But let’s not focus extremely too much on it because let’s face it:
And there are many other situations when using metrics for employee evaluation that are completely un- useful.
Usually the general view is the one deciding and for the most part is the best. Enforcing metrics will increase the chances for sabotage among employees or give false results.
I don’t have a valuable solution for this but it would help differentiating testing metrics to development metrics. Because:
Things that a tester does in addition to testing can be measured: installing an environment, reporting, presence at work. But is not relevant to the main job itself.
Also what should not be done (!!!) is rewarding testers by completely absurd criterias like:
Although those above have some relevance it should not be considered a major factor because this means that testing in that organization is not taken seriously and doesn’t have a real chance to improve.
Metrics are indeed hard but if you use a group of sub-metrics and a good impartial general view you can tell what tester is more productive than the rest after some period.
It’s more like evaluating a person who is a better friend: is it the one who goes with you the most of the time to beer? Could be – but is hardly a good criteria; it could be a sub-metric though that can influence it.
If you like this trick you can use it in your own page by placing the following code in your body section:
Similarly we have the view testing. Its not “click click” only, because you can reduce by this principle every activity to a “manual” operation.
Note: If you accessed directly http://www.testalways.com you will not see the first part of this post so try to click on the title of the post, see if anything changes.