I’ve only been a software tester for about a year and yet there are lots of lessons that I learned during that time. I want to share this to all my co-software testers, testers-to-be, and maybe to all people who are into software development. To discuss this more constructively, I’m going to use the lines I’ve read in the book: Lessons Learned in Software Testing by Cem Kaner et. Al. This contains a LOT of lessons but I’ve choose to pick ones that I personally experienced and hand-picked. So let’s get started!
- You are the headlights of the project – It was described on this book that a project is like a road trip. Some of these are simple and routine, like going to supermarket in broad daylight. But most projects nowadays are like driving a truck off-road, in the mountains and at night. As a tester, it is our job to light the way for these projects. We’re the ones who will going to trace where the project is, what are the things will going to run over and how close the project on a bad edge. This can be done through thorough testing, bug reports, documentations and other tasks like these which the testers technically do all the time. It can be excruciating indeed, but always be reminded that road trips are worth enjoying.
- Confusion is a test tool – When you feel confused, that could be telling you something important. I personally experienced this and it really works wonders. The primary suspects for this confusion would be the vague specifications or perhaps there is really an issue existing in the system. If it is on the specifications, ask this to your superior to clear any ambiguities. If it’s a system issue, then it is an SOP to raise a ticket for this bug.
- You are what you write – Bug reports are the primary work product of most testers. These documents shape your readers’ perception of you. Of course, the better reports, the better reputation. When I create bug logs or even documentations, I always try to see that it will be comprehensible to my readers – even IF they are mentally tired, so there will be no redundant communication between us. Let the document do the talking.
- Make your bug report an effective sales tool– this is one of the awesome lessons I’ve learned. Whether you think of it this way or not, our bug reports are sales tools, it’s designed to convince people to give up precious resources in order to obtain a benefit that you propose. Before, I’ve got tons of trivial issues that left pending and unfixed. So what I did was I tried to sell these bugs to them. For example, there’s an issue with our input field not having its focus set on the first editable field. I tried to tell them that if I were the user, an extra click just to get the focus on the first field would be already a hassle. And as a result, they’ve fixed the issue. But don’t overdo bug selling that it already reaches to the point that you’re already forcing somebody to fix it. You’ll drive yourself on the wrong edge.
- Uncorner your corner cases – Efficient testing often involves extreme values. The idea behind testing at the extremes is that if the program can survive these, it can probably survive less extreme results. For example, if an input form says “Input an amount between 1-100.”. You can try to input around 100 or 1. Maybe 100, 100.01, 150, 1, .50, -10. These extreme inputs usually cause errors and if it happens in your testing, report this to the developers. However, too-much extreme values such as “abcd1248375932xyz” for that form will have the high probability that it won’t be entertained. Make sure that if you use extreme values, it really makes sense as an end-user of the system.
- A failure is a symptom of an error, not the error itself – When you see a failure, you’re looking at a misbehaviour of the program, not at the underlying error in the code. The failure might be minor (mouse droppings, for example), but the underlying problem might be much more serious (wild pointer, for example). If these kinds of minor issues have hit you again in other parts of the system, it might be not as minor as it was perceived to be. To verify this, you can do follow-up testing to find more symptoms or perhaps where possibly this issue might happening too which will make this bug more critical and sellable.
- Never use the Bug-Tracking system to monitor Programmers’ performance – Though I did practiced it since I started testing, this is worth noting. If somebody, a manager or perhaps a tester tries to use the bug-tracking tool to report a programmer having his tickets takes forever to fix and having many open tickets, the rest of the programmers will respond defensively to the system. Arguments will start, like bugs aren’t bugs, there are duplicate tickets, intermittent bugs or perhaps shoot the blame back to the tester or management being incompetent. So to avoid this, never use bug-tracking tool as a sole barometer for the performance of a programmer and do our jobs as a tester precisely to make every ticket really worth fixing.
Though these lessons are just a matter of the universe for a tester, it is important that we should learn from every lesson that we encounter for it will be one of the greatest factor on becoming a great tester. Happy Testing!
Related Article: Tips for Effective Software Testing
One thought on “Lessons Learned in Software Testing”
What you describe #5 is boundary testing. This involves min-mid-max-(min-1)-(max+1) but don’t forget zero (0). Whilst data driven techniques are quite easy to implement the broadest form of coverage can be achieved through scenario based testing. BUT don’t forget that its not just about positive scenarios, the negative ones must be considered as well. In the context of Agile testing, each story is accompanied by a test (TDD) that is used to exercise that deliverable, when combined testing needs to also be merged which means consolidation without coverage loss.