I used to do tech support for a number of years for various companies. What I liked about Tech Support is that I got to listen to customers and how they use the software/hardware and some of the interesting projects that they had. The difficulties that they came around with and I got to help them with the issues. It was a good feeling to be able to help them out.
There’s a long list of pros and cons I could go through, but what ultimately got me into QA is the feeling of helplessness of not being anything to do about bugs that critically affected the customer where they could not function any more, and passing that information above and sitting waiting while trying to appease the customer as they lose data and/or revenue month by month or in some cases year by year.
So when I got into QA, I used a lot of my tech support skills and understanding in order to try to write up bugs. The most of what I could think that the Engineers need is data. Accurate concise data about the bug.
What does that entail?
1) steps to repro ( as short as possible hopefully can reproduce the issue in 1 to 7 steps )
2) platform, os, configuration
3) possibly video, crash logs, etc.
4) sample file if applicable
5) accurate title of the issue ( so that they could read the title and understand what’s going on with the bug )
6) the proper identification on how critical the bug is (crasher/hanger versus enhancement)
7) accurate categorization
The most important thing that was in my mind was to give the best amount of data I can. Make it short so that they can easily read it quickly, make it accurate to reproduce so that dev doesn’t spend a lot of time to try to reproduce the issue. Why do I go through the trouble? Because the more data I give them that’s short and sweet; I hope the more likely they know what the problem is and hopefully be able to fix it quickly rather than having to go back to me and ask me more questions. It’s hard to do something like this all the time, but I try. My target audience is the engineers however I do try to keep in mind that there are some other people that do read the bugs such as QA, Tech Support, etc.
At the end of the day, the question I have left in my mind is… should a major bug such that it causes a hang (causing data huge amounts of data loss to a large variety of customers) with steps to repro sit idle for 3 years, or should I raise a ruckus about it? Doing it from Tech Support didn’t seem as helpful as if I was from QA. At the very least I get a response quicker and can respond back faster rather than having a middle man in between. ( What lingers in my mind is questions remains is should a QA person be silenced for “complaining” about the product when that’s his/her job? I don’t know the answer to that question. )
After all… shouldn’t the product be catered to the customer to some degree? I would think that crashing and hanging bugs that caused data loss and happens often based on the number of customers hitting the issue should raise alarm. At least in QA, I have a chance to curve that before Tech Support gets hit.
Oh. And as an end user… I really really hate crashing. If you really want to know why I hate it, imagine trying to program a recursive program on mac os 8. That’s what I did in high school.
