Breaking Benjamin, “I Will Not Bow”
Archive for the ‘Miscellany’ Category
On the front page of the September 9, 2014, Wall Street Journal, we find that GE has exited the kitchen with the sale of its appliance business:
However, on page B3 the same day, the drop quote in an article would seem to indicate otherwise:
Of course, General Electric is not buying the food company Annie’s; the headline makes clear that the General in this case is General Mills (stock symbol: GIS).
But there’s nothing in the drop-quote to indicate something is wrong within its own context. Maybe General Electric often pays premiums like that during an acquisition. Maybe the copy editor or whomever did this dropquote finished the GE story from page 1 just minutes before working on the General Mills story.
However, we’ve got to retain context when testing and proofreading.
Where does this come into play in testing?
The foremost example in my mind is when we’re doing things to trigger error conditions to make sure that an error message displays. It’s possible that the system will throw up the wrong error message and we’ll miss it. I once wrote automated tests that triggered error conditions and parsed the error message (mostly to make sure an error message applicable to the screen and operation displayed). However, I did not write it smart enough to compare the error message that displayed to the error message expected. So when the application started failing by displaying the wrong message for the occasion, the tests didn’t catch it.
So you’ve got to remember to see the forest and the trees–along with the underbrush, the soil, the other flora, and the carnivorous fauna–when you’re testing.
You’ve spent days wandering the cavernous halls of a convention center, trapped in windowless rooms, drinking too much coffee and talking yourself hoarse. Does anyone ever emerge from a conference as the organizers intended, feeling recharged with new ideas, contacts and energy?
New York City marketing executive Stefany Stanley does. Among conference organizers she is known as a savvy convention-goer, someone with a strategy for rising above the dreary rounds of networking and breakout sessions. Ms. Stanley says she has gained valuable contacts, ideas and insights from the 15 conferences she has attended in the past five years.
The article goes on with tips and tricks to maximizing your meeting other people to sell your services to or to meet people who might help you get a leg up, basically.
I must be doing it wrong; when I go to conferences, I go to attend the sessions and to learn what the speakers have to offer as to professional insight. Maybe I’ll meet someone I know off the QAternet or something, but I don’t count on it, and if I don’t, I don’t think that I’ve lost something.
Of course, I don’t go to enough conferences and conventions often enough to have my soul crushed, and I don’t think of them primarily as mass in-person sales cold calls, so I’m probably doing them wrong when I do go.
But maybe you’ll find the article useful.
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.)
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.)
Seen on Twitter:
Engineers don't let engineers design user interfaces. pic.twitter.com/XKSDUOxKHe
— John Bellomy (@cowbs) September 28, 2014
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.
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.
- 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.
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.
The banner on deals.ebay.com:
The same banner on the eBay Gold store (wait, you didn’t know eBay had a gold store? Neither did its testers!):
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.
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.
One of the recurring pratfalls in testing your integration with third party widgets shared by, and updateable by, others who use it is their test data becomes available to you sometimes.
Take, for instance, testing integration with Google maps. It’s becoming harder and harder to submit a string that returns no results. Search for asdf, for example, an old tester favorite.
Someone in testing adding Google Places has added that as test data, and it’s there for all of us to see.
Why would a user do that?
None of that stopped 26-year-old Diondre J— of Slidell, who checked into Slidell Memorial Hospital on Aug. 5 under the name of her deceased sister, Delores, Slidell Police Department spokesman Daniel Seuzeneau said Wednesday.
When hospital staff attempted to put the information into the hospital’s database, an error message informed them they might have been treating a dead person. The police were contacted, and Diondre J— was stopped in the hospital parking lot.
It’s good to see someone was on the job testing to see what would happen if you tried to enter a patient’s date of treatment after the patient’s date of death.
Because sometimes a user might do that.
Everyone hates a hater. They’re the ones who hate the sun because it’s too hot, and the breeze because it’s too cold.
The rest of us, then, can take comfort in the fact that haters may not want to get involved in as many activities as the rest of us.
But in a twist of irony, that grumpy person you know may actually be better at their job since they spend so much time on fewer activities.
It’s not true, of course.
Haters don’t hate other haters.
But the rest could hold true.
We’ve all read copy that makes us cringe. Sometimes it’s hard to put a finger on exactly what it is that makes the copy so bad. Nonetheless, its lack of appeal doesn’t go unnoticed.
Of course, writing is subjective in nature, but there are certain blunders that are universal. While poor writing doesn’t do much to engage the reader or lend authority to its publisher, it can help you gain a better understanding of what is needed to produce quality content.
It’s most applicable to content-heavy Web sites, but some are more broadly applicable to applications in general. Including #8, Grammar Matters:
Obviously, you wouldn’t use poor grammar on purpose. Unfortunately, many don’t know when they’re using poor grammar.
That’s one of the things we’re here for.
(Link via SupaTrey.)
The Australians and New Zealanders have a word, rort, that we should employ as part of our software testing lexicon.
I’m going to rort this Web site.
Feel free to drop that in your next stand-up. Bad Australian accent is optional.
So much of our written communication, including emails, texts, tweets, and online conversations are informal, but I still take pride in using full sentences, correct punctuation, and the right word for the job. It differentiates me from people who don’t, and I hope it serves me well in picking up clients and contacts.
A developer has a bit of a right-on rant about programming is stressful insanity:
Imagine joining an engineering team. You’re excited and full of ideas, probably just out of school and a world of clean, beautiful designs, awe-inspiring in their aesthetic unity of purpose, economy, and strength. You start by meeting Mary, project leader for a bridge in a major metropolitan area. Mary introduces you to Fred, after you get through the fifteen security checks installed by Dave because Dave had his sweater stolen off his desk once and Never Again. Fred only works with wood, so you ask why he’s involved because this bridge is supposed to allow rush-hour traffic full of cars full of mortal humans to cross a 200-foot drop over rapids. Don’t worry, says Mary, Fred’s going to handle the walkways. What walkways? Well Fred made a good case for walkways and they’re going to add to the bridge’s appeal. Of course, they’ll have to be built without railings, because there’s a strict no railings rule enforced by Phil, who’s not an engineer. Nobody’s sure what Phil does, but it’s definitely full of synergy and has to do with upper management, whom none of the engineers want to deal with so they just let Phil do what he wants. Sara, meanwhile, has found several hemorrhaging-edge paving techniques, and worked them all into the bridge design, so you’ll have to build around each one as the bridge progresses, since each one means different underlying support and safety concerns. Tom and Harry have been working together for years, but have an ongoing feud over whether to use metric or imperial measurements, and it’s become a case of “whoever got to that part of the design first.” This has been such a headache for the people actually screwing things together, they’ve given up and just forced, hammered, or welded their way through the day with whatever parts were handy. Also, the bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they’re still sort of holding up parts of the bridge. Nobody knows which parts, but everybody’s pretty sure they’re important parts. After the introductions are made, you are invited to come up with some new ideas, but you don’t have any because you’re a propulsion engineer and don’t know anything about bridges.
We’re not a above a bit of absurdist civil engineering metaphors to describe our predicament.
But it’s good to see a developer with a forest level view of the strange nature of software development.
(Link via tweet.)
On Quora, a recruiter explains recruiters.
Why do recruiters always contact me about jobs that are below me?
I’m a director at a major company, why do I constantly get recruiters contacting me about senior designer and design manager roles, when these are clearly below my skill set?
The beginning of the answer:
1) Recruiting is a pyramid with high turnover. By definition, most recruiters are not as skilled, which means they’re just calling anyone and everyone. Maybe you show up in a database with an old resume. Maybe they’re searching off keywords. Maybe they’ve been taught to call up the chain in hopes of getting new job orders. But you’re experiencing something a systemic fault. While it seems annoying, it works enough to keep many of those people employed.
He lists some other reasons which might be valid, but this one is the most prevalent in my experience. When they try to connect with you via LinkedIn, note how many of them look to be 23 years old. That’s another clue that they’re casting a wide, wide net, and your name is just a temporary variable in their patter.
Full disclosure: I’ve done some work for this guy before, so he definitely falls into one of his later categories. So I’ll take his word for it that not all other recruiters are nebbishes.
A slideshow of What I Learned in Engineering School presents a number of lessons for software development if you look at them the right way.
A skyscraper is a vertically cantilevered beam. The primary structural design consdieration is not resistance to vertical (gravity) loads, but resistance to lateral loads from wind and earthquakes. For this reason, tall structures function and are designed conceptually as large beams cantilevered from the ground.
Just like how we have to test software. A building is supposed to stand up, so simplistically speaking, you’d think it would have to be strong and rigid against gravity. But there are other forces at work to account for.
So with a piece of software: simplistically, it’s designed to perform a task, and simplistic testing makes sure it does that task adequately. However, when looking at it from the tester’s perspective, you have to account for other forces besides the drive to get to the software’s goal. You’ve got to account for the real world, people making mistakes, and interactions that are sometimes hard to predict in a requirements guide or on a napkin.
Work with the natural order. The locks of the Panama Canal are operated without pumps. Gravity moves millions of gallons of water from lakes to the lock chambers, where ships are raised and lowered 85 feet in passing between the Atlantic and Pacific oceans. As long as precipitation refills the lakes,the locks continue to function.
Your software will work better for your users if it conforms to their knowledge, their expectations, and their habits. Also, your processes will work better if you take into account your corporate (or organizational) environment, people, habits, and whatnot. You can’t come in and make everybody change to the better way you know just because you know it’s better. You have to take stock of what’s already going on and craft the better processes without trying to push water uphill.
At any rate, it’s worth a read with an eye to the lessons you can apply to software development.
Wayne Ariola in SD Times:
Remember: The cost of quality isn’t the price of creating quality software; it’s the penalty or risk incurred by failing to deliver quality software.
Word to your mother, who doesn’t understand why the computer thing doesn’t work any more and is afraid to touch computers because some online provider used her as a guinea pig in some new-feature experiment with bugs built right in.