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.

Many of us are comfortable testing from a use case. It's familiar. Most of us are trained and experienced in thinking about a problem starting from an actor, who takes action, and ends up somewhere. It's the classic "Given... When... Then..." way of thinking about a problem. You start from point zero, then advance to the destination. Lately I've found it helpful to instead start from the destination, and then work backwards from there to think of all the different ways I could end up there.

For example, let's say I'm on a search results page. Here are all the ways I might have gotten there:

• I go to the search field on the homepage, enter search criteria, I land on the search results page


• I enter a URL someone sent me which takes me to the search results page


• I click on a link with a hard-coded search request that takes me to a search results page


• I click the back button on my browser which takes me to a search results page


• etc...

This technique is sometimes helpful when the piece of functionality I'm testing has preconceived notions about what defaults it can assume based on how the programmer thinks I got there. They were likely thinking of the one or two use cases they had available - not the 8 or 9 other ways you can get there.

For example, most features on search results page (like sorting, filtering, etc...) assume you've entered search criteria. In some cases, that's just not true. Sometimes you can get to a results page without entering anything. If your search criteria isn't pre-populated in the search field for you, in those cases you can get some really odd behaviors. This can become even more interesting when you're dealing with features that perform calculations, or where the issues resulting from the false assumptions aren't immediately visible.

The next time you run across a feature that looks like it might be making some assumptions based on state, work backwards from that point to think of all the other ways you might be able to get there. Do all of those paths lead to the necessary conditions for the defaults to be populated? If not, what possible problems might that cause?

Test strategy typically deals with what you plan to do. If you think of test problem space as a physical space, as surface area, then a test strategy helps define the map of what you plan to cover.

If you think about it as positive space/negative space, or figure/ground if you prefer, then I had always considered the things you plan to do representing positive space, and the things you plan not to do representing negative space.  But a recent post on Catherine Powell's always-good ABAKAS blog added a new dimension for me: things you hadn't considered. These are the things that don't make it to your map because you didn't think of them.

The takeaway for me was that by documenting what you plan to cover and what you don't, the things you didn't think of are really the negative space. As Powell says, this makes our assumptions (end by extensions, the things we missed) visible for validation. This adds value at all phases of a project, either helping avoid problems early on through helping understand strategy decisions during a post mortem.

This is the review I stumbled upon. Not a fresh news, but all up to date, brought carefully in one place. The fragment is quoted below.

VBScript and JScript are extremely lightweight ActiveX Scripting languages. ActiveX Scripting Engines may be used in a variety of Microsoft environments: Windows Scripting Host, HyperText Applications, HyperText Components and scripting for Internet Explorer, and classic Active Server Pages. There are other ActiveX Scripting languages, such as ActivePerl and ActivePython, but these tend to be complete languages in contrast to the minimal logic layer that VBScript and JScript provide. In fact, VBS/JS must use ActiveX/COM components to accomplish anything other than trivial tasks. This optimization results in some noteworthy shortcomings in both languages.

VBScript Strengths

• The De Facto Standard


• By Reference Parameters


• Formatting Functions


• Data Conversion


• Date/Time Support


• Built-In Iterator Support


• Constants


• "With" Blocks

Okay, it's actually The Pencil. The Pencil Project powered by Mozilla.

What is that?

The Pencil Project's unique mission is to build a free and opensource tool for making diagrams and GUI prototyping that everyone can use.

Top features:

•Built-in stencils for diagraming and prototyping
•Multi-page document with background page
•Inter-page linkings!
•On-screen text editing with rich-text supports
•Exporting to HTML, PNG, Openoffice.org document, Word document and PDF.
•Undo/redo supports
•Installing user-defined stencils and templates
•Standard drawing operations: aligning, z-ordering, scaling, rotating...
•Cross-platforms
•Adding external objects
•Personal Collection
•Clipart Browser
•Object snapping
•Sketchy Stencil
•And much more...

Licensing and Versions:

Pencil will always be free as it is released under the GPL version 2 and is available for virtually all platforms that Firefox 3 can run. The first version of Pencil is tested against GNU/Linux 2.6 (Fedora, Ubuntu and Arch) with GTK+, Windows XP and Windows Vista/7.

And here's what I created as a trial in a few minutes.