Archive for September, 2014

I’ve Tested Those Applications

Tuesday, September 30th, 2014 by The Director

Seen on Twitter:

I’ve tested applications like that, where the Web pages are filled with tabs full of edit boxes crammed into the space with inscrutable labels that, I’m assured, the users know what they mean.

Well, maybe.

Sometimes, these interface designs come straight off of some crowded paper form that a worker would fill out with pen, checking boxes and putting tic marks or numbers in boxes. On paper, this is as quick as moving your eye, moving the pen, and pressing down. With a screen, it’s a little different, as it involves tabbing or moving the mouse and clicking and then typing something, scanning the form, moving the mouse, clicking, typing some more, and so on.

Other times, these interface designs pretty directly capture what the worker saw in a mainframe application or in a terminal window connecting to a mainframe application. With Windows or Web-safe colors instead of amber text on a black background that the worker. A lot of needless tabbing because interfaces could not easily branch. If you check this box, then these blank spaces become relevant. No, paper couldn’t do that and mainframes couldn’t do that, so the new Windows or Web application won’t do that. Because the users are used to it.

However:

  • The workers (“users”) today aren’t the users of tomorrow; if you’re not designing the interface right because it’s good enough for the grizzled greybeard who’s been around forever, you’re not appreciating how much easier you could make the process for n00bs. That is, probably most of the users. Especially if you’re writing software for a company that’s okay with this sort of interface. I imagine it has a lot of turnover and a lot of people getting trained to do it the hard way just because it’s always been done.
     
  • Notice that we use the term “users” a lot in relation to people who work with the software we build. That’s defining them in terms of their relationship with our software, but their main jobs are doing something else. If your software design captures workers and traps them into being users too much, it drags on their productivity. Computer software should make their jobs easier and more streamlined, not slower than working with pen and paper. Sure, you can say that the data collection for analysis on the back-end is the driver for the software, but that doesn’t mean you should ignore other efficiencies you can introduce with a good (or at least better than this) design.

I read somewhere recently about hiring tester with test skills rather than domain knowledge, and sure, that’s the right balance, however, domain knowledge is what allows you to spot these sorts of problems. You might be hired because you’re a good tester, but you ought to study up on the industry whose software you’re testing. Me, I’ve been known to refresh myself on the basics of chemistry to better test chemical modeling software and to grok at least a little bit of the workflow of a warehouse when testing order fulfillment software.

Because otherwise you’re only logging the defects qua defects like “The Tare Weight edit box allows alpha characters” and not the higher level concerns about why you’d expect a worker would enter the total shipping weight before the number of items to ship.

Domain knowledge gives you the insight about the worker’s starting point in your software and what he wants to do to get done with your software. And that will give you the possible paths for his interaction without having to make all the possibilities available on one screen in tiny print.

QA Music: Iron

Monday, September 29th, 2014 by The Director

Within Temptation, “Iron”:

QA Music: Tired on a Monday Morning

Monday, September 22nd, 2014 by The Director

Stone Sour, “Tired”:

QA Music: Like a Tester

Monday, September 15th, 2014 by The Director

Like a Storm, “Love the Way You Hate Me”:

Is that a didgeridoo in a rock song? Yes.

An Inadvertent Password Review

Wednesday, September 10th, 2014 by The Director

So I’m at a presentation last week, and the presenter’s got his little tablet plugged into the projector. He wanders off and starts talking to someone, and his tablet shuts off automatically after a bit.

So he goes to the tablet and looks down at it. He starts it back up, and he types his password to unlock it, and….

Because it’s a tablet, the keyboard displays onscreen and shows his key taps.

As does the projector.

So we all saw his password. On one hand, it was a strong password. On the other hand, we all saw it.

Don’t do that.

It Shouldn’t Be Any Different

Friday, September 5th, 2014 by The Director

The banner on deals.ebay.com:

The banner rightly sized

The same banner on the eBay Gold store (wait, you didn’t know eBay had a gold store? Neither did its testers!):

The banner incorrectly sized

Now, why would the height of the banner be different on one page?

Because they’re different, no matter how much the same they seem.

One of the tricks of testing is recognizing how things differ in your applications and Web sites. Although the pages and features try to share code and styling whenever possible, they diverge more than it appears. As you test across features, you’ll get a sense of where different code does the same things, so you’ll learn where to test similar workflows whenever something changes.

That includes checking the styling of different pages within your site when a CSS file changes.

The Tails of Lower Cased Gs Are The Brown M&Ms of Web Design

Thursday, September 4th, 2014 by The Director

Whenever I see the bottom of lower cased Gs cut off in edit boxes and drop-down lists:

Stepping on the tails of lower cased Gs

I know to look very closely at design elements of a Web page because the designer has not.

(The story of brown M&Ms explained here.)

Where I Use Loops In Automated Tests

Wednesday, September 3rd, 2014 by The Director

Jim Holmes threw down the gauntlet on Twitter:

However, don’t is such a challenge to QA.

I use loops in my automated tests for the following things:

When running the same sort of test with different data.

When I want to test the same operation with different sets of data, I use a loop to jam the different set of strings into the same form.

incrementor=1
until(incrementor == number_of_rows)
  item = util.get_hash_from_spreadsheet(spreadsheet,incrementor)
  form.add(browser, item, log, filename)
  incrementor = incrementor +1
 end

When adding a large number of records for testing purposes.

I know, with just the right database management toolset, knowledge of the database, and proper tuned queries, I could go directly to the database to add a bunch of records if I want to see what happens when a user is working on a posting with a large number of comments attached to it. I want to see how it reacts when I add another comment or when I delete the posting or a comment.

So I just run a script with it:

incrementor = 0
while(incrementor < 100)
  post.go_to_post(browser,post_id, log, filename)
  countbefore = comment.get_comment_count(util,browser,post_id,urlstring)
  comment_text= "Comment left at "+(Time.now.strftime("%m%d%y%H%M%S"))
  comment.add_comment_on_want_detail(browser, post_id, comment_text, log, filename)
  countafter = comment.get_comment_count(util,browser,post_id, urlstring)
  incrementor = incrementor + 1
end

Sure, we can quibble about whether this is an automated test or just a script; however, the script is testing the site's ability to handle 100 comments in a row, ainna? So it's a test and not a set-up script.

When testing data loads.

I've got a client who runs different programs for banks, and individual programs are targeted to individual bank branches. This means the client runs a spreadsheet through a data load process, and I have to test to ensure that the bank branches are exposed.

So I take a spreadsheet from the data load and run it through the automated interface tester.

incrementor = 1
until(incrementor == number_of_rows)
  branch = util.get_branch_from_spreadsheet(spreadsheet,incrementor)
  form.search(browser, branch, log, filename)
  incrementor = incrementor +1
end

So although you might have good reasons to not use loops in certain instances, loops do prove useful in automated tests.

Just remember, there's always an awful lot of sometimes in never.

The Benefits of the QA Outlook

Tuesday, September 2nd, 2014 by The Director

A Perfect Dose of Pessimism:

Listen up Pollyannas of the world: A dose of pessimism may do you good.

Experts say pessimism can at times be beneficial to a person’s physical and mental well-being. Some studies have found that having a more negative outlook of the future may result in a longer and healthier life. Pessimism and optimism are opposite ends of a spectrum of personality traits, and people generally fall somewhere in between.

“All too often in the literature and in the public conversation, we want people to be more than 90% optimistic,” said Dilip Jeste, a professor of psychiatry and neuroscience at the University of California San Diego. “That’s not good. It is much better to have a balanced perspective and have some pessimistic streak in your personality in order to succeed.”

The sidebar lists four different types of pessimism. Which one is QA’s perspective? Number 5, the classified one.

QA Music: Dangerous

Monday, September 1st, 2014 by The Director

Not Roxette. Shaman’s Harvest:


wordpress visitors