Following up on yesterday's tip on leveraging integrated tools, another aspect to keep in mind when you look at information moving "across tools" from one team to another, is to make sure key information is captured by required fields.

That comes with the caution to be careful of going to far. Don't make every field required. Then people will just end up using copy paste and you'll start to see redundant and nonsensical data. A better approach is to get that dataset as small as possible, and reduce the burden on moving info from one team to another.

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.

For many teams (especially large teams), the team often has a suite of tools in place to help facilitate the development process. It could be Microsoft Visual Studio, Rational Team Concert, or even the Atlassian suite of products. Regardless of the tools in place, if there's an integration across the tools and your team isn't using that integration effectively then you might want to take a look at how you can better leverage all the features you've already paid for.

This tip, stemming from a frustration on the part of an IWST tester who constantly has to manually re-enter data from one tool to another, points to a problem in cross-team workflows. If these tools were not in place, perhaps it wouldn't be that big of a deal. However, since the company has already paid for these tools, it's really frustrating when the testing team can't take advantage to the features simply because people haven't been educated on the implications to other teams of how they use the tools.

If you have these tools in place, pull together a small cross-functional team to look at how people are using the tools. And don't just talk about what you think is happening - really look at what's happening on projects. Based on that, see if there are opportunities to better leverage the integrated features of the platform, and roll out changes supported by training and helping people understand the value gained by the changes.

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.

If you're looking to shave some time off of your test documentation tasks, take a look at working some charters into your test plan so you have fewer scripted test cases to write. Charters are simple to document - you start with defining a mission, an anticipated length, and if you'd like a bit more structure you can include a bullet-list of coverage items so you're sure the person who executes the charter hits all the critical parts. Contrast that with a typical Microsoft Word test case template which includes columns for step, expected result, screenshots, data, setup tasks, comments, etc... It's just a lot of work, for (many times) very little return. If you have not tried using charters before, check em' out.

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.

Rick Grey and I stumbled on this tip on accident, but it turns out that Pivotal Tracker is quite possibly one of the best tools available for session-based test management. Pivotal Tracker is freemium, and provides a dirt-simple interface and workflow for managing stories. We've used it now for a number of projects, and I've really grown to like this tool as a management platform for testing.

When you use the stories as charters, it becomes an awesomely powerful charter management tool. You can do force ranking of charters so people can pull from the top, assign tags for coverage, track issues and comments on charters, and a number of other cool tricks. The tool also allows for export to CSV for access in the test managers most powerful reporting tool - Excel.

If you do session-based test management - check it out.

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.

Do you have to test payment processing? Need to see what happens when I card is declined for being over the available credit limit? Try using a pre-paid VISA gift card. You can likely pick one up near you for $25, and it's easy to go over that limit and see what happens when the card is declined. It's also an easy way to use a "real" card without releasing your personal account information into the wild.

Since we're on the topic, if you're not also familiar with the test accounts that have been setup for each vendor, check those out as well. Your particular payment gateway may also have additional test numbers available.