When we submit defects, we often include a core set of data that's included on every ticket. For most organizations, this will include the submitter, the environment where the issues was discovered, the steps to reproduce, and often some sort of attachment showing or demonstrating the issue. In many cases, this core information can be captured and filled out automatically. Some defect tracking tools provide features that provide this functionality, but even if they don't a lot of times you can write a really simple script to populate a lot of this information for you. At a minimum, if your team has an expectation for some of these aspects to be filled out for all tickets, consider making those fields required to help ensure that each one is at least touched/reviewed before the tester clicks submit.

This tip was part of a brainstorm developed at the September 2011 Indianapolis Workshop on Software Testing on the topic of "Documenting for Testing." The attendees of that workshop (and participants in the brainstorm) included: Charlie Audritsh, Scott Barber, Rick Grey, Michael Kelly, Natalie Mego, Charles Penn, Margie Weaver, and Tina Zaza.

We touched on this one before with this tip from Dave Christiansen, however the topic came up again at last month's IWST. Depending on the tools you use, you might consider attaching automated scripts to your defects. If you can find a bug, and then quickly record a simple script that recreates it, attach that and send it along with the defect report.

This tip was part of a brainstorm developed at the September 2011 Indianapolis Workshop on Software Testing on the topic of "Documenting for Testing." The attendees of that workshop (and participants in the brainstorm) included: Charlie Audritsh, Scott Barber, Rick Grey, Michael Kelly, Natalie Mego, Charles Penn, Margie Weaver, and Tina Zaza.

Let's say you're testing a text field and you need a value for first name. Your first inclination might be to test with the value:

TomTheReallyLongNamedGuyWhoHasFunkyCharactersInHisName12345!@#$%^&*()_+-=

There's nothing wrong with that. It's a fine test value. However, if that value ends up finding what you think might be an issue, then work backwards from the issue uncovered to try to find a more specific test value that both highlights the issue and is also a more realistic value a user might input.

For example, let's say the issue uncovered is that the length of the name entered overwrites the available space on certains screens - then just use a really long name and ditch the special characters. Or let's say it's a hyphen that makes the application choke. Then ditch the length and do a simple hyphenated name.

I found really cool web page capture program over the holiday call FireShot. FireShot is a simple tool that lets you capture and annotate web pages. I needed something that would capture more than a simple screenshot since I couldn't size the page small enough to fit it into one image. This was perfect. Snap the shot, mark it up, send it off. Simple - and it's just a browser plugin. Check it out.

For those of you who do web testing, Support Details is a handy little utility for when you report issues. It automatically pulls down information related to the browser you're using, and it allows you to either download that info (csv, pdf) or email it to someone who can look into the issue. Since I have several computers and each has a couple of browsers (all constantly doing their own automatic updates) this is really nice for when I submit something that I suspect might be browser specific.