Leverage required fields for key information
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.
Leveraging integrated tools
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.
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.
Gift Cards for Testing Payment Processing
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.
Start from the abstract and move the the specific
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.
Work backwards from a destination
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 and Things You Hadn’t Considered
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.
Review: VBScript vs. JScript
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
Sketching with a pencil
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.
