Reduce documentation – charters over test cases
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.
Pivotal Tracker for SBTM
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 Dependencies
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.
Attacking Passwords
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.
Rapid Reporter, exploratory notetaking tool
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
Capture charter velocity
When I'm managing session-based exploratory testing, I spend a lot of time measuring charter velocity. There are a couple of key dynamics I look at:
- charters executed per day
- new charters created per day (broken down by charter priority level)
I typically capture these by tester, but I often look at them as a team aggregate. While I'm interested in individual trends for coaching, for a team of more than two testers, it's more interesting from a team perspective when it comes to creating trendlines. I show an example of how I use these numbers in a recent SSQ article.
Prioritizing your exploratory tests for a given session
Today's tip comes from Christina Zaza. Tina gave an experience report recently at IWST, and in that talk she outlined some of the different ways she prioritizes her tests when she sits down to do exploratory testing:
- run the faster tests (or quick tests) first to get them out of the way
- run the higher risks tests (or tests more important to the business) first, since they will likely yield the most actionable results
- group features together to reduce context switching while testing
Use polarities when pairing
If you do pair testing on a regular basis, try this and see what happens. Take a look at the list of different test polarities and try using them when you pair. Explicitly call out in advance, "I'll approach this session from this side of the polarity, you approach it from the other." Some polarities that work particularly well for this include: doing vs. describing; or doing vs. thinking; 0r data gathering vs. data analysis; or working with the product vs. reading about the product.
Using polarities to help develop charters
When you charter your tests, see what happens when you use different test polarities to develop your test charters. For each test idea, run it past some of the different polarities. How would your testing change if you focused on individual tests vs. general lab procedures; or coverage vs. oracles; etc… I find that doing this helps me generate far more test ideas than I otherwise would. While they aren't always high priority, the ideas come. That's important for overproduction and abandonment.
Polarities when creating charters
When you charter your tests, see what happens when you include polarities explicitly in your mission. For example, look at testing vs. touring; or feature vs. feature; etc… After you've done this for a few charters, note how it changes your testing. Does it help you focus? Is it distracting? I find that doing this sometimes helps me better focus when testing. Especially if I'm chartering a shorter charter (20-30 minutes).
