Who owns keyboard testing?

by Michael S. Kaplan, published on 2012/05/02 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/05/02/10299780.aspx

Our story thus far:

It was almost 4½ years ago that I wrote some basic rules.

Rules for developers.

Rules for developers about keyboards.

I was even faux pompous enough to refer to them as my Michael's Keyboard Laws for Developers. :-)

The first law: VK_A is not always 'A'.

The second law: Not every keyboard contains every VK_* value.

The third law: Not every keyboard contains every character.

The fourth law: Not every individual keystroke is relevant.

The fifth law: <CTRL>+<C> and <CTRL>+<ALT>+C will stop each other from doing their jobs, and <CTRL>+<ALT>+C is the same thing as <ALTGR>+<C>

Now after that last law, law #5, a question comes up.

After the rules and regulations about development and how it impacts and is impacted by keyboards is laid out in Michael's Five Commandments, I mean.

It is a question near and dear to the heart of most SDE/Ts and STEs....

Who owns keyboard testing?

 Now that is a complicated question!

The short answser is simple!

It depends!

The detailed answer is that it depends on the kind of testing you are referring to.

The breakdown is simple:

• Testing relating to a feature's application of the five laws is entirely owned by the testers of the feature itself. This is a common sense requirement based on the fact that keyboards are generic but the needs and capabilities of a feature are quite specific, and testing of these issues can't scale past a specific feature team (just as the fixing of those bugs can't scale past the developers on the team.

• Test expertise on how keyboards work so that those feature teams will fully understand how to do their job is owned by a more central "International Test" team. Their responsibilities can include training, test breakout reviews, and centralized bug bash management.

• Testing of unique hardware-related issues is owned by the people who support the hardware. This also applies to the keyboard type and subtype specific issues (e.g. 106 key Japanese keyboard), since realistically such testing requires actual physical hardware, and no one can expect every feature team to have every piece of hardware, or a general "international test" team to understand the ins and outs of every piece of hardware.

• Testing of whether a keyboard layout meets the requirement of its underlying spec or standard is owned by the test team of whatever team is creating keyboard, supported by both the person providing the keyboard and/or the government/standards body that has compliance issues surrounding the layout.,

it is possible that if you are one of those types of testers that you may feel that this breakdown is unfair - particularly if it relates to an unanticipated test resource requirements.

Unfortunately, no other breakout makes much sense, and other schemes will lead to incomplete coverage, and (by the First Software Tester's Axiom) will lead to bugs.

Unless what you really want is to have bugs.

Maybe I should send some email to your manager? :-)

go to newer or older post, or back to index or month or day