QA and the Motivational

February 11th, 2015 by The Director

I go to a dojo filled with positive, encouraging, uplifting people, from the kyoshi to the black belts to the other students. You want to talk about imposter syndrome, and I’ll explain how I feel when surrounded by nice people.

At any rate, members of the dojo often post motivational images to, well, motivate each other. And immediately, my mind works to find the condition where the assertion is not true. I must subvert it.

Like:

Your excuses get you 0% closer to your goals. Unless you’re writing a book about your excuses, I think.

I don’t know how my story will end, but nowhere in my text will it ever read… “I gave up.”

I think:

That, my friends, is the essence of the QA mindset: When presented with a proposition, you find some way to subvert or suborn it. Remember that the contradiction of All are…. is not Nothing is…. but Some are not….. (See also the Aristotelian Square of Opposition.)

Plan your tests accordingly.

Oh, Yes, Grammar Matters

February 10th, 2015 by The Director

Grammar Rules in Real Estate

Real-estate agents, better take out that red pen.

An analysis of listings priced at $1 million and up shows that “perfect” listings—written in full sentences without spelling or grammatical errors—sell three days faster and are 10% more likely to sell for more than their list price than listings overall.

On the flip side, listings riddled with technical errors—misspellings, incorrect homonyms, incomplete sentences, among others—log the most median days on the market before selling and have the lowest percentage of homes that sell over list price. The analysis, conducted by Redfin, a national real-estate brokerage, and Grammarly, an online proofreading application, examined spelling errors and other grammatical red flags in 106,850 luxury listings in 52 metro areas in 2013.

Think it applies only to real estate and not your product interface? Are you willing to take that gamble?

You’d better make sure your Web labels, error messages, and helpful text are grammatically correct, or you won’t be able to quantify how many people don’t use your software because they thought it was written by third graders. Because they won’t be your users.

(Yes, I know the story is nine months old, but I’m between contracts right now and have a little time to catch up on my newspapers for the last year.)

QA Music – I Want My….

February 9th, 2015 by The Director

“Mr. MTV” by Nothing More

Now That’s A Tech Blog I Would Read

February 5th, 2015 by The Director

IT Droll

Alas, ITDroll.com is not droll musings on the computer industry after all, apparently.

Why Would They Call It A ‘Hot’ Key If Nobody Stole It?

February 4th, 2015 by The Director

Over at Medium, they discuss how the intersection of Polish typing custom, Microsoft Windows custom, and user interface colluded to create a defect: The curious case of the disappearing Polish S:

A few weeks ago, someone reported this to us at Medium:

“I just started an article in Polish. I can type in every letter, except Ś. When I press the key for Ś, the letter just doesn’t appear. It only happens on Medium.”

This was odd. We don’t really special-case any language in any way, and even if we did… out of 32 Polish characters, why would this random one be the only one causing problems?

Turns out, it wasn’t so random. This is a story of how four incidental ingredients spanning decades (if not centuries) came together to cause the most curious of bugs, and how we fixed it.

It’s hard to test for the conditions to recreate this bug unless you’re Polish. It’s also a humbling example of how we’re going to miss things because of our (as yet) limited omniscience.

(Link via IDisposable tweet.)

Book Report: The Programmer’s Book of Rules by George Ledin, Jr., and Victor Ledin (1979)

February 3rd, 2015 by The Director

Book coverThis book is forty-five years old. I realize I’m doing some of Quality Frog‘s schtick here, reading old computer books to glean the lost knowledge of the ancients, but bear with me.

This book really does contain a set of rules for programmers to follow: The left pages have the rules in large font, and the right pages have the rules explained in a paragraph or two. The book focuses not only on programming best practices, but also on software development best practices, and these are much more applicable to modern programming than the pre-object oriented programming lessons.

For example, first and foremost are the rules about making sure your program answers the users’ needs. Rules like:

  1. Fit your program to your users’ needs.
  2. Aim your program at the widest circle of users
  3. Explain to your user how to use the program
  4. Make it easy for the user to run the program

Other rules cover interface design, such as Display results with pertinent messages which are just as relevant now as it was when the interface designed displayed only green or amber text.

Even the discussion of loops, variables, and breaking your program into sections has a sort of relevance because it discusses these things philosophically, at a high level, in a way that programming how-to books and online language tutorials do not.

It’s a quick read or browse; although it’s roughly 220 pages (which is still slim by modern, $60 computer book standards), it’s really less than that since the text is not densely packed on the pages as described above, and it’s worth the time for the insights not only into the crystallized rules but also in the recognition of some software development problems and goals predate the Internet, which I am pretty sure some of our younger co-workers don’t know.

Books mentioned in this review:

QA Music: Song for the End of a Contract

February 2nd, 2015 by The Director

“Fly By Night”, Rush

I just ended a twenty-six month contract, and I’m excited to start something new. Which is TBD, but still exciting.

Like Every Michelin Commercial Ever

January 27th, 2015 by The Director

Job posting:

A developer's job in an auto garage?

Can improved automobile tyres really make the world a better place? Should we trust developers the one to change the tyres?

To be honest, probably better than me: the last time I changed a tire, I cross-threaded two of the lug nuts and then snapped one of them off (with only a lug wrench, sir; I was motivated to remove that bolt). BECAUSE I BREAK THINGS.

QA Music: An Old New Song

January 26th, 2015 by The Director

Howard Jones “New Song”. Which is thirty-one years old, but never mind that.

Full disclosure: The mime in chains following the rock star around inspired me to get into QA.

Your Web Site’s Undergarments Are Showing

January 22nd, 2015 by The Director

Keep in mind your invisible meta tags display when a user shares the link in various social media forms:

I see London, I see France, I see your Web site's wrongminded meta data

In this case, I think we can agree it’s a QA fail.

Waiting for One of Two Things To Appear on a Page in Java Selenium

January 20th, 2015 by The Director

I’ve been working on a Java Selenium test automation project, teaching myself Java and Selenium WebDriver along the way.

I ran into a problem that I didn’t see solved on the Internet elsewhere, but my skill at searching StackOverflow is not that good.

The problem is conducting an operation that might yield one of two results, such as success or an error message. Say you’ve got an registration form or something that can succeed if you put the right data in it or will fail if you put the wrong data in it. If the user successfully registers, a welcome page displays. If the user fails, an error message displays. And, given this is the Web, it might take some time for one or the other to display. And the implicit waits didn’t look like they’d handle branching logic.

So here’s what I did:


public int waitForOne(WebDriver driver, Logger log,
                      String lookFor1, String lookFor2){
  WebDriverWait wait = new WebDriverWait(driver, 1);
	
   for (Integer iterator = 1; iterator < 60; iterator++){
     try{
         WebElement element = 
            wait.until(ExpectedConditions.elementToBeClickable(By.id(lookFor1)));
         return 1;
        }catch (Exception e){
				
      }  // try 1
      try{
          WebElement element = 
             wait.until(ExpectedConditions.elementToBeClickable(By.id(lookFor2)));
          return 2;
         }catch (Exception e){
      } //try 2
  } //for loop
}// waitForOne

You could even create a longer list of events to wait for one of them to occur by passing in an array of strings and then using a For-Each loop to run through the list.

This sample looks for a Web element by its ID, but you could change it to use another By parameter, such as CSS Selector (cssSelector). Or, if you're feeling dangerous, you could pass in the By parameter as a string and parse it in the method to determine whether to use ID, CSS Selector, or a mix therein. But that's outside the simplicity of this example.

Also note that the For loop that limits the waiting for a total of sixty iterations, which in this case will max out at 120 seconds (at 1 second per attempt for 2 items a maximum of 60 times). You could pass the max in as a parameter when calling this method if you want. That's especially important if you're using a list of possible elements to look for. If you're passing in five elements, suddenly you're at a maximum time of five minutes if it times out completely. You might not want your tests to wait that long, especially if you're using the check multiple times per test.

I'm sure there are more elegant solutions for this. Let's hear them. Because, frankly, I'm not very good at searching StackOverflow, and I'd prefer if you'd just correct my foolishness here in the comments.

QA Music: I Am Machine

January 19th, 2015 by The Director

It’s been a while since we’ve had some Three Days’ Grace, so here is “I Am Machine”:

It’s been a while since we’ve had anything, actually. Perhaps I should post something.

QA Music – The Wrong Side of the SDLC

October 6th, 2014 by The Director

Five Finger Death Punch, “The Wrong Side of Heaven”:

I’ve Tested Those Applications

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

September 29th, 2014 by The Director

Within Temptation, “Iron”:

QA Music: Tired on a Monday Morning

September 22nd, 2014 by The Director

Stone Sour, “Tired”:

QA Music: Like a Tester

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

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

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

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