In this post, I will try to elaborate why is often expected from me as a tester to create meaningful application error messages.
So, you are using some web application, and you get something like this( thanks to Evil Tester):
And that error message does not tell you anything about your action or input. At least they put disclaimer: “That is all we know”.
While I am testing application, I find a lot of such not informative error messages. Why I find them and developers not? Because I know how to make reasonable scenarios that trigger those errors. And to come up with such scenarios and test data is not something of interest of regular developer. In my experience they find this very boring and not creative job. But I think that finding alternative flows by exploring api that you use is very creative and important job.
Developers just have different meaning for definition of DONE. Or they are just lazy.
First line of defense is that user will never do that. But you took BBST Bug advocacy, and you have already uncornered your test scenarios making it more probable in real life.
After I talk to project leader and provide him information about low quality error messages, I put extra work on my shoulders. Karlo, as you already found those error messages, you will create meaningful error messages.
The problem here is that I can only provide error messages for scenarios that I covered. But low level mechanics of the application, which includes inter module cooperation based on api contracts, this is developer responsibility.
In this blog post I would like to share my excitement how I improved my shoes tying craft and what does this skill have in common with software testing.
Some time ago I bought my new adidas special shoes, and I was very happy. But not for very long time. Shoelaces kept untying on and on. I was very unhappy with that fact. What is going on!?
I Googled: “My shoelaces keep untying” and I found following TED video.
I was taught how to tie shoelaces the easiest way, which was not the right way for shoes with nylon laces.
I was impressed with shoelaces physics, how simple change in one step can significantly change the outcome.
This blog post is a working example how we should always question our software testing skill. If we have been doing software testing in same way as we were taught at the beginning, maybe is time to question our software testing skill.
In this post I will present g+ share issue that I experience when I tried to share one of my blog post from the blogger tool. This post is inspired by genuine Ben Simo blog Is there a problem here?
Video speaks for itself.
What is important here is to note that this video is not enough for issue report. Why? Because developer can only see the issue manifestation. This video could only entertain the audience. But it does not contain information to replicate the issue.
BBST RIMGEA gives what are the ingredients of excellent bug report.
For example, R stand for replicate. I have not replicated the issue from the video. I did not do any analysis during the issue (for example using Chrome development tools). And using that video, developer can not replicate the issue.
Dear tester, if you only submit manifestation of the issue in your bug report, you are not good tester.