Obviously I’ve been too busy to post anything for some time… but a colleague just shared this and I wanted to pass on the funnies.
I would join Apple Computer about two years after this clip, and there was still grumbling about OpenDoc‘s demise; one of the many technologies that geeks dug, that Jobs killed. Obviously history has been kind to his decisions, but at the time, these decisions took serious balls. Jobs was many things… but lacking cojones? I seriously doubt anyone ever accused him of that.
QA folk are protective of their logins, and rightly so. We create users to test with, and expect their accounts to be in the state we left them in. It’s not convenience… it’s essential.
But Devs will ask you for a login to this server, or that server. So send them the link to the wiki page that describes how they can create their own logins, and even walk them through it if need be.
But if they still come asking for a login, try creating, and sending them a login with the username “lazydevs”. Problem solved :)
Sometimes the passive-aggressive solution is the right solution.
I am VERY surprised to learn that I made the top 10 in TestBuffet’s top 21 automation blogs of 2014! It’s especially nice to be listed among some of the blogs I read… not to mention discovering some new blogs I have yet to read. Very nice, indeed.
A reader gave me flak for writing about automation way more than about testing. Okay. Guilty. So towards making amends for this fact, I give you, Brine’s guide to writing a good bug.
A good bug includes four things:
A title is the most important part of a bug. A good title should convey all (or as much of) the information about the issue… to the point where reading the rest of the bug is unnecessary. And it should do so in as few words as possible.
I used to try to nail the title before writing anything else, but I found it just takes too much time. And I would usually end up rewriting it before submitting anyway. Write it last! I’ve found titles are much easier to write after you’ve written the bug itself.
Steps should have just enough detail. Too little and it won’t be reproducible, too much and it can get confusing. If you find yourself writing a bug that has 10+ steps, you either have a very complex bug, or overly complex steps. This can also depend greatly on the bug’s audience and the preferences of the team. Still, keep it concise.
This is the easiest part. After following your steps, what happened, and what did you expect to happen?
You might think the impact of your bug is “high” (and what QA wouldn’t), but that term isn’t very useful, and certainly wouldn’t rate a whole section in a bug! No. The Impact section is where you try to PROVE the impact of a bug. This helps the writer because attempting to prove the impact of a bug requires proper regression. It also shows the reader what you’ve tried, and provides insight into the severity of the issue, and areas to verify upon being fixed.
These questions show impact. They tell the reader just how bad, how far reaching, and/or how recoverable, the issue is.
Oh, and there’s one more thing…
If the issue is cosmetic, it had better have a screenshot attached! Screenshots and/or movies can be worth the entirety of that classic cliché, a thousand words…