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.

Defaulting input values is supposed to simplify the workflow for a user. Yet sometimes an application has a problem accepting its own suggestion. We wrote about that. Another piece that is always worth exploring is input dependencies.

See, if an application

• has a functionality that responds on your selection by updating dependent controls (enable/disable, reload list items, change default value);


• sets defaults in accordance to each other;


• sets defaults in accordance to date, time, and regional settings;


• has a functionality that remembers user input and uses it as defaults, either on client or server side;


• has a "storage" for customizable defaults on the client side (registry, files, etc.);

...end explore if it can be messed up.

Today's tip comes from Santhosh Tuppad. In his blog post "Password – Flaws / Risks / Design suggestions and more" Santhosh demonstrates the power of heuristic-based testing approach combined with tool-assisted tricks.

What you'll find is a friendly walk-through, comprehensive test and UX report, references for further learning, and "is there a problem"  sample questions, - all in one. 

A must read.

Today's tip is about Rapid Reporter, a tool created by a tester (Shmuel Gershon) for testers (especially those, who practice Session Based Test Management of Exploratory Testing, SBTM).

If you do exploratory testing, try the tool and let us (or the author) know how did it go.  Otherwise, at least try doing exploratory testing...

 

RapidReporterUserGuidePic