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

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.

• 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.

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

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

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

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.

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.

In the Symantec alert, the message sort of indicated that it might be a test:

In the body of the e-mailed alert, however, careful readers found the words “Summary: threatcon test threatkhanh otrs” buried among several links.

Whenever you’re testing in a live environment or in an environment where databases are copied from dev or test environments into production (not a best practice, I know, but it happens too often), you must structure your test data so that it’s marked as test data somehow.

For example, on Web data collection forms that use e-mail as a uniqueish identifier, I recommend using a standard domain for your test submissions; in the past, I’ve used the company’s domain.  This way, your dev teams can (and should, but whether they will or not depends upon the caliber of your persuasion–I recommend .45) filter out the test records before the records go to the fulfillment house, e-mail vendor, or mere usage reports.

On free-text sorts of data entry, it’s best to stick with a simple line of “This is a test entry.” or something similar.  At least Mr. Khan did enter the word “test” in his data entry for Symantec; other times, developers or testers pound on the keyboards with the subtleties of bonobos.  If these strings of characters get passed onto actual users, they might look like defective behavior on the part of your application.  Worse, if you subversive QA types use gallows humor in your test entries, it might make it past the gatekeepers and onto the end user or client’s computer screen.

I’m not saying that I ever did anything like that, regularly-scheduled production testing included some feeble humor that the data aggregation and screening person filtered out before passing relevant entries onto the client.  When the data aggregation and screening duties passed on to admin staff, one of the almost plausible punchlines made it to the client.  The humor wasn’t anything that damaged the relationship with the client, but it’s better to be safe than sorry.

So treat that test data as though your client or end user was going to read it.   That way, when your tech team inevitably makes the mistake that presents test data as gospel, at least it will be good spelled.

If you use automated testing, make sure that the test data used by your scripts is clean and friendly, too.  Because if your client gets to see that information, your client is going to see it a lot.  Automated test data that indicates its source in automated testing will explain to the uninformed why he or she is seeing this test message every day at 1am.

It’s not a bad idea to earmark load testing data as well so that its origin is easily identified; a load test mistakenly sent to a production server should trip some potential Denial of Service alarms with your hosting provider.  If you’re doing it the right way, that is.

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.

I am not saying that every Flash application should be compatible back to Flash 6 (although Flash 7 would be nice); instead, Web sites that use rich media should build detection logic into their sites to inform the user of the Flash thingamabob’s compatibility; that is, if the designers had to have some widget from Flash 8 in the thing, the Web site should check to ensure that the user’s Web browser has at least Flash 8 installed. It’s not impossible, but it takes a little extra effort that’s not dedicated to the gee-whizery that warms the cockles of your Flash developers’ hearts.

That being said, what should you do to test these things, my QAhort? What I did was to create a batch file that, with a single click of the mouse, would use the silent installers to uninstall the currently installed version of Flash and then installs the version you want. Just like that.

Here’s the basics:

1. Go to Adobe’s Archived Flash players available for testing purposes page.
2. Download the Zip files to a central location, such as a mapped network drive. If you’re only going to do this on a workstation, you don’t need to do this step, but if you want to make the files available across workstations, you’ll need a central location.
3. Go to Adobe’s How to uninstall the Adobe Flash Player plug-in and ActiveX control page and download the uninstaller executable.
4. Unzip the contents of each version’s zip file. They tend to have two installers, one for the Active X control used by Internet Explorer and one for the Gecko/Firefox/Netscape version.
5. Create, in a central location, your Flash uninstaller batch file. This batch file removes Flash from your system as described on the Adobe article page. This file, uninstallflash.bat, should look something like this:
   

   
q:
cd \qa_files\Macromedia Flash
uninstall_flash_player /s


   The installer files that I mention below will call this file to clear existing versions of Flash before running the installers. The Adobe page says it’s a good idea to restart between uninstalling and reinstalling, but in most cases it will work without; however, do keep in mind the caveats about instant message clients and whatnot holding onto the ActiveX control and preventing its installation.

6. Create the individual version installation batch file. I used a single batch file for each version, but if you’re sophisticated and underutilized, you can put a menu in the batch file if you want. For example, installFlash7.bat would look something like this:
   

   
q:
cd \qa_files\Macromedia Flash
call uninstallflash.bat
z:\
cd \qa_files\Macromedia Flash\macromedia flash\Flash Player Installer Archive\fp7_archive\r61
flashplayer7r61_winax.exe /q
flashplayer7r61_win.exe /s
c:


   Again, this uses the silent installer so that you’re not bothered with the prompts associated with a normal installer. When the installers run, though, you might see some progress bars on the screen.

7. Once you’ve got the uninstallers set up, you can create shortcuts or whatnot to their locations and run them easily. You can create desktop shortcuts if you want, but I prefer to create a centrally located HTML file that has nothing but links to them and then embed that HTML file into the Active Desktops of all the workstations upon which I would use the batch files. This way, I’d have access to the latest versions of the files and would see any changes I’d made to the HTML file list of batch files. But that’s just my way.

In any case, what you have is an easy way to rapidly switch between versions of Flash–or uninstalling Flash completely–to see what your users will see when they are exposed to the creative genius of your organization’s Flash designers. And the ensuing havoc.

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

As you might know, gentle reader, I used to be a technical writer before I gave up trying to explain the inexplicable and decided to seek and destroy it instead. So I have some advice for taking screenshots effectively. Most of the advice that follows talks in terms of Windows-based computers, but if you’re in QA, you should be smart enough to apply the lessons to other platforms.

First off, you need a program that can handle bitmap images, such as Microsoft Paint (standard with a Windows install), Microsoft Word (if you have Microsoft Office installed), or a custom graphics program. I’ve always been happy with Paint Shop Pro because it’s under $100 and I’ve used it for almost a decade. However, Photoshop or what have you will work as well.

Next, there are two ways to take a screenshot. You can simply press the Print Screen key, which takes an image of the entire desktop including taskbar and whatever bits of your wallpaper might display behind the application you’re testing. This is typically too much information, so you’ll only use it occasionally. I mean, here’s a busy screenshot of my whole desktop, including windows open beneath the application I want to call out:

Click for full size.

Click for full size.

Click for full size.

Click for full size.

Click for full size.

Click for full size.

But you have proof. And you’re not crazy.

(As a footnote, if you’re testing on a Macintosh, you can do a screengrab in different ways recounted here.)