Archive for the ‘Clean Tricks’ Category

There Must Be Fifty Ways To Scroll Your Window

Thursday, July 2nd, 2015 by The Director

Recently, I had to test an animation in a Web browser that occurred when the user scrolled down the Web page, so I had to figure out as many ways to scroll the viewable area of the page to ensure the animation worked with each.

With apologies to Paul Simon, there must be fifty ways to scroll your window. Here are a few:

Press the down arrow, Barrow.
Press the arrow up, Hup.
Page up and page down, clown.
And move the view around.

You can push Home, Gome.
Roll the mouse wheel, Lucille.
Press the End key, Lee.
And it moves magic’ly.

Mobile tap and drag, Dag.
Tap and give it a flick, Rick.

Tap on the SPACE, Ace.
Make sure it’s in its place.

Click the mouse wheel and get the scroll icon, Ryan.
Keep hitting Tab, Gab.
Slide the vertical bar, Dar.
Maybe we’re carrying the joke on too far.

At any rate, keep in mind these dozen ways to scroll the view if you’ve got JavaScript animation to account for.

Also, thanks to @mrpjones and @kinofrost on Twitter; they get co-songwriting credits and will get to share the royalties when this baby charts.

The Parable of the Deer

Friday, March 27th, 2015 by The Director

So I’m coming back from an errand early one morning, and I turn onto the farm road where I live. I live out in the country, you see, and the farm road is a long, straight road that rolls over hills and creeks between fences, woods, and pastures. As I’m driving down the farm road, I think to myself, Although it’s technically day time, on cloudy days, deer are often active later than normal. I remember a particular stretch of the road just before the creek, where a cow pasture faces woods and where I’ve seen deer before. Then, as the relative elevation of the road changes in relation to the pasture, I see a single deer in the middle of the pasture against the backdrop of the hills beyond, and I slow my truck to ten miles an hour. Where are your buddies? I ask him, because does and fawns travel together in family groups.

Two deer dart across the road, and two others turn from the fence they were about to hop and retreat into the pasture. If I’d been traveling normal speed, I very well might have hit one of them.

I know the general behavior of deer; I know the lay of the land and the geography of deer crossings; and I just might have seen the deer in my peripheral vision, outside my focus but enough to trigger additional caution until I did see it consciously. That’s how I knew the deer were there.

And that’s how I found that bug. I know the general behavior of computers, applications, and interfaces; I know something of the domain or problem this program is trying to solve; and I have wide peripheral vision when testing, the ability to see things wrong in the corner of my eye and retry my actions with focus on the problem area.

In Other Words in Other Places

Wednesday, June 25th, 2014 by The Director

Now on StickyMinds: Picture Imperfect: Methods for Testing How Your App Handles Images.

It’s a list of dirty tricks but without the snark.

The Draw Test

Tuesday, November 26th, 2013 by The Director

In North American football, the offense sometimes runs a draw play, which is a delayed handoff that gets the moving parts of the defense to act before the offense turns the ball over to its running back:

The idea behind a draw play is to attack aggressive, pass-rushing defenses by “drawing” them downfield. This creates larger gaps between defenders and thereby allows the offense to effectively run the ball. Draw plays are often run out of the shotgun formation, but can also be run when the quarterback is under center. These types of draw plays are sometimes referred to as “delayed handoffs”. The running back will most often run straight downfield through the “A-Gap” (the space between the center and the offensive guard), although there are more complicated variations.

Now, in our deadline-driven software development world, we often find ourselves typing and clicking as fast as we can to get as much test coverage as we can in our allotted time. In a way, we’re playing to software that’s trained to be aggressive linebackers, running toward our software’s operations as fast as possible. Kinda like I started charging into this metaphor too quickly and find myself off-balance, unable to elegantly segue to my point.

Within applications, you can sometimes find defects by delaying actions. If your software integrates with other software or services asynchronously, the expectations of the code might not match how fast–or slow–a user might interact with the software.

For example, a shopping cart piece of e-commerce with distinct units might mark those units as Hold, Wait For Payment if a user adds it to the shopping cart and starts the payment process. If the hold has a timeout associated with it–an expectation that, if the user does not complete the payment within five minutes (or two minutes, or twenty minutes) that the payment has been abandoned and the system should remove the hold. However, in the case of paying with PayPal, the PayPal window itself can linger for that duration and more, ready to accept your login and confirmation of payment, at which time PayPal will send a payment received message to your system. For an item whose hold might have been relinquished and might not be available any more. How will you know unless you hold onto that ball for a a couple of seconds and let all the integrated software make their plays?

Another example: Financial software that uses two stages of authentication. The first time you log in from a browser, it prompts you for your user name and then directs you to a security question; after you answer that correctly, it prompts you for your password. If you log in and don’t do anything for ten minutes, your session times out. But what happens if it takes you longer than ten minutes to answer your security question? What happens if you answer the security question but don’t enter a password in those ten minutes?

The draw test is a valid line of testing because your users don’t live to fill out your forms. In their real lives, they’re called to meetings, go to lunch, minimize the browser window when a co-worker comes in, or otherwise temporarily delay their activity in a fashion that might put their next actions beyond your software’s expectations. If you take a little time, you can identify the places where your system might allow this and to make sure your software handles delayed action on your user’s part elegantly.

Somebody’s Mama Made The Never Happen

Friday, September 20th, 2013 by The Director

Long-named US woman celebrates government climb-down:

A US woman has won a battle to have her full name put on her driving licence.

Janice “Lokelani” Keihanaikukauakahihuliheekahaunaele’s name is so long – containing 36 letters and 19 syllables – that it would not fit on the documentation.

What is the lesson here?

The obvious lesson, of course, is that you need to consider names other than Mike Smith when building your applications. Of course, we’re pretty much past that now given our more worldly software development culture (people who build and alter government computer systems not included, of course).

But you’ve got to test those long strings going into the system, and you’ve got to test those long strings coming out of the system.

If you’re displaying someone’s name, does the name lie over other design elements on the page or, urk, the mobile app? If it’s printing out somewhere, is there room on the page or in the PDF for it?

You’ll never know until you try. Your developers will never know until you try, either, because they won’t try it themselves.

(Link via Tweet.)

Decoding the Credit Card Number

Monday, January 9th, 2012 by The Director

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.

Your Placeholder Text Leaks Out

Friday, March 25th, 2011 by The Director

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.

The Worst I Ever Got Was A Shower Caddy

Friday, January 7th, 2011 by The Director

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.

Banish Lorem Ipsum

Tuesday, September 21st, 2010 by The Director

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

Testing E-mail Addresses The Right Way

Wednesday, March 25th, 2009 by The Director

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

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

Designers Lose One Excuse

Tuesday, July 15th, 2008 by The Director

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.

Reminder: Test Month Fields with September

Monday, April 28th, 2008 by The Director

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.

Keeping Your Test Data Clean

Monday, September 24th, 2007 by The Director

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.


Opening the Raincoat on Flash Version Testing

Wednesday, September 5th, 2007 by The Director

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.


Screenshots: A Primer

Tuesday, July 17th, 2007 by The Director

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.


wordpress visitors