Yes, I know, credibility is essential in any role. I agree. However, I do think that it is more important for a software tester than many other professions because some of our products are hard to verify, and the importance of our professional point of view to the management. Credibility is a crucial factor in creating a name for yourself. Our reputation as testers is one of the most valuable characteristics we should aspire to and mishandling it might damage other characteristics we might have, like technical ability and accountability, in the eyes of our peers.
Let's take for example a close profession, programming. If the programmers need to develop a button or a flow, you can check the system and see if there is a button or not, if a new transaction is available etc. They might be buggy, but still, they are there, or at least the code can be reviewed. A programmer has visible products.
Testers, on the other hand, has only some visible products, even less in agile. The testing itself is usually something performed solo. It is hard to know how well they are done in the short term. The subject of these tests might work even after lousy testing, or no testing, and get feedback only in the production stage.
While I know most of us will not take advantage of this situation and skip tests we were supposed to do, it is important to notice that should we decide by goodwill to skip some tests (due to risk management and time constraints) - we must inform that to the team/manager. Otherwise, finding a bug in a skipped test might raise an eyebrow once; in the case of two incidences, it will raise suspicion. An accurate description of what we did is also one of the essential aspects of reporting - what was tested and how (besides the results of course).
Once we had some tests that we needed to do quite urgently. I discussed the tests with the team and made sure everyone knew their tasks. One of the roles of the tester was to press a few URLs and check data is entering the DB. After the tests were done, I gathered the results. I asked that tester if he completed his tasks including the above one and he confirmed that he did and I reported on a successful session. However, then I got a call from an accountable programmer who told me there was no data in the DB. I called the tester for a private discussion, and when I confronted him with the facts, he told me that he thought the test was useless (which it wasn't) and skipped it, without bothering to inform me. Needless to say, I couldn't trust him anymore.
Another way to create credibility is to hold back your natural and understood desire to inform everyone immediately that you found a significant bug or incredibly complicated one that only you could have found. Wait, breathe, and make sure that the anomaly is indeed a bug ("reality check"), that it can be reproduced, isolated, impact understood, and even the cause if possible (see here Bugs opening procedure (presentation)). Then you can go and inform the relevant people about the bug.
A fellow tester felt that anything that he finds should be immediately broadcasted in the company. Besides the fact that programmers disliked this negative buzz, it seemed that most of the times the alerts were premature and a total waste of time. They were mostly false positives and never reproduced to this day. Soon the dislike was turned to a lack of appreciation.
It is also tempting to describe old bugs or system behavior in meetings that discuss product quality. First, we must make sure that we are correct. So many issues are handled by us daily that we might get it wrong. Better say that you suspect it happens before and after the meeting, you will check it.
I once worked with an incredible tester, that was very credible. When he said in a meeting something like: no, the system doesn't do that, instead, it does something else (and describes the real behavior) it would end any discussion because we all took his words as Irrefutable facts. True, he was also very technical, but the accuracy of his statements was always very very high.
From: Lesson Learned in Software Testing, lesson 84:
Your credibility is fundamental to your influence. If you make the bugs you report seem more serious than they really are, you’ll lose influence.
I can understand the temptation of declaring we finished a task ahead of time, that we found a showstopper or remembering past events that might influence current goals. It might get us a short-term appreciation. However, if we want to be considered as real pros and have an excellent reputation, it is the accuracy of what we do that counts in the long and more critical term.
Comments
Post a Comment