Archive for November, 2013

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.

QA Music: Helpful Advice for Developers and QA

Monday, November 18th, 2013 by The Director

Developers, listen to the kind man Frank Hayes as he explains you should never set the cat on fire:

QA: Do just the opposite of what he says except for the first verse and the cat thing.


wordpress visitors