QA Hates You

If you work with credit card processing, this graphic will explain how the credit card is derived.

You can use it to better create test data or whatnot.

As careful as you are, well, no, strike that: as careful as the non-QA elements in your organization are, some of your test data and placeholder text are going to leak out into the real world.

You have to choices: Encourage your careless team members (and your QA staff) to use relatively innocuous placeholders, or expose your users to lorem ipsum ad nauseum.

Other testers recount their experiences with finding themselves in test data found in production:

• James Bach has a vanity license plate with TESTER on it and got a ticket as a result. Word is that this used to happen a lot with plates with NO PLATE or NONE on them, too, since the cops wrote this on tickets given to those cars and HQ added an extra fine for not having a plate.
• As an overcorrection, Eusebiu Blindu (aka testalways) found that his hosting provider blocks the keyword test in certain circumstances.

As you can well guess, I insist upon testing in production whenever possible, and when I was working for an interactive agency, I entered the contests as Brian Tester with an e-mail address with the interactive agency’s domain and with the agency’s address. As a result, I, I mean Brian Tester won the consolation prizes in several of the CPG client’s giveaways. This meant coupon packs and the occasional free sample. The biggest prize I ever got was a shower caddy, a piece of plastic you could doublestick-tape to your shower to hold the client’s product bottles and useless for anything else.

Ha, ha!

These amusing anecdotes aside, what can one do to try to prevent this?

• If possible, remove your test data. If you can delete your test record as part of the test, do it. In many cases, though, you don’t have a delete function or direct access to the database to delete.
• Standardize your test data for production. Use the same surname or address whenever you test, for example. This provides a key to use to identify and scrub that test data whenever your organization needs to do that test data. You could use your company’s address, for example. If you can’t find a single field you can be sure is 100% unique and that users will not actually input, use a composite built of several fields.
• Understand where the data goes. A lot of times, other companies and organizations are getting dumps of your application’s data for other purposes, such as contest administration. Even if your team knows to scrub for your data, these other organizations might not. And suddenly, you’re on the top 10 most wanted list, Bob Tester. Sorry.
• Communicate with data consumers. Once you know where the data is going, you can tell them about the standard form for your test data and warn them to scrub it or handle it.
• Document your test data. As part of any data schema or spec document that should get passed onto other data consumers, especially the ones about whom you won’t know or with whom you will not communicate, include details about your test data standard. Include it in code comments. Stick that note everywhere as a warning.

Following those steps, if you can, might help prevent the problems that happen when some program takes your test data seriously.

In case you’re looking for a little Hamlet test of your own or need fill copy for a design, you can use Fillerati to create long strings from various literary texts.

(Link seen in the Twitterverse. Sorry, I forgot who betweeted it.)

Joe Strazzere offers a list of tests for e-mail addresses.

Go, learn, and do. Don’t make me find them for you.

As you know, readers, I’m a fan of paying attention to the status bar in Internet Explorer, ever vigilant for the icon that indicates a scripting error on the page. The QA people at GoDaddy explain how you can do the same in Safari 3.x, almost, which means your team’s designers and hipster developer have one less excuse not to notice these things before you do.

Of course, it does not address the reason, which is the inherent self-righteous sloth these people exhibit, but that’s another matter entirely.

A posting at DailyWTF reminds us that we should always test month edit boxes with September, especially when the user can enter 09:

See, Javascript supports octal numbers. Any number starting with a zero is octal, even if it can’t be an actual octal number. In certain languages, like Perl, trying to use a non-octal number as an octal number results in an error. In other languages, like Javascript, it silently fails.

This problem can also occur when the user selects the month from a drop-down list and converts it to a number for database purposes, so you should always test with September at least once in your testing.

There are many things one can learn from  this story:

Symantec Corp.’s early-warning system gave its enterprise customers a brief scare late Friday when it erroneously sent an alert that said an Internet-crippling attack was in progress.

However, the one I want to tease out is this lesson: always keep your junk data clean and readable and clearly defined as test data.

(more…)

The cool kids like to use Adobe Flash to build rich Web applications because if you build it in Flash, you don’t have to worry about compatibility with Web browsers. Oh, who am I kidding, they like to use Flash because it offers a bunch of effects out of the box and it does some right purty things with animation and pictures. It allows them to put forms and data submission stuff right into the flash really fast, too, often without any data validation, but that’s another story.

No, today’s lamentation is about how those cool kids build Flash animations or applications using the latest version of Adobe Flash love to use the latest gimcracks and whatnot and how people who have a previous version of the Flash player installed with their browsers sometimes don’t get to see and marvel at the genius of your design team. Sometimes, they will see nothing at all, which is very, very bad. And you know, some browsers/computers ship without Flash installed in the default browser, right? So what happens when that user tries to hit the page, he gets no message and no warning, which means he thinks the site is defective. Because it is.

(more…)

Screenshots are the QAer’s best friend, gentle reader. Appended to a defect report or printed on a color plotter at 20″ by 30″ so you can wave them two-handedly in front of the developer, they can prove conclusively that something very wrong happened with the application. Because otherwise the developers will fix something and claim it was never broken in the first place, or the humidity within the office will change, altering the flow of electrons through the network cable, producing different results when you try to recreate it, or something. It’s always something.

So, at any rate, a good screenshot adds a lot of value to a defect report or other communication.

(more…)