I had trouble finding a decent definition of “craftsmanship.”

So far, the best I’ve got is “the work of a craftsman.” That is not exactly useful, when I want to apply the idea of craftsmanship to testing. So, here goes: what is craftsmanship? I have experience with a few other disciplines that helps me to think about it here.

One of those areas is the art of silversmithing. If I were looking at a piece of jewelry to determine its level of craftsmanship, I would look at the joins: are its soldered joins even and well made? Are there gaps? Are its cold connections flush and well polished, or will they snag and come undone? Is the silver clean and bright, and is its finish consistent and intentional? Is the backplate warped, has the wire been damaged, are the prongs symmetrical, does the stone rattle in its setting?  Is the metal of good quality, is the stone beautiful? Are the materials that went into the jewel worth the work that was done to them?

All of that relates to the quality of the piece without saying what it is, but quality is not all of craftsmanship.

If I have a spectacular gemstone, and put it in a poor setting, I have not completed an example of good craftsmanship. If I have a spectacular piece of metalwork, and place a “blah” gemstone in it, the result is the same. Even if I have both an excellent stone and an excellent setting, and they do not complement one another but clash, I still have not created a piece with exemplary craftsmanship. Thus, craftsmanship also has a component of design. If it has not been designed well, it cannot perform its function.

If I have a piece of jewelry with a stunning design, excellent components, high quality of construction, and such enormous weight that it is not wearable for more than a few minutes without discomfort, I still have not satisfied the demands of craftsmanship. In order for me to consider it a good piece, it must perform its function.

The first two components are indispensable to the third. In order to perform its function, a piece must be designed well and created well.

So, is craftsmanship the combination of well-thought design, quality of construction, and performance of its function, or is there more to it than that?

If I’ve nailed the definition down, craftsmanship in software would start at the design level. The product would need to be designed, coded, and tested, all with craftsmanship in mind. The designers, coders, and testers would all need to work with their utmost level of skill in order to deliver a product that is well designed to perform its function, that is created in order to perform that function well, and that actually does perform out in the real world.

But what does that mean, for a tester?

I cannot guarantee that the design will optimize the product to perform its function, but if I have a hand in that design, I can push it in the right direction. I cannot guarantee that the coders have used all their skill to create a program that does its thing, but I can test it to make sure it actually does it, under a variety of circumstances.

Is craftsmanship any different from quality assurance?

I think it is, so I’ve missed something in the definition.

Looks like I need to think a little more on this.

I am not a fan of conflict across departments. You know the kind – the DBAs don’t like the software developers, the developers don’t like QA, QA wrangles constantly with the project managers. All that kind of conflict manages to accomplish is spreading strife and interfering with a process that, from my point of view, doesn’t need any more interference.

Where I work, QA does wrangle constantly with the project managers. We have different ideas of what “quality” means. We have different ideas on how long, exactly things will take (and the software developers are different again.)

In the interest of fostering communication across departments, I am going to do a little cross-department snooping: I’m going to shadow with the product owners, find out how they do what they do and why, and see if I can’t feed it back into the QA process.

This ought to be interesting.

One of the biggest things I have learned as a visual artist is that a character intended to capture hearts and minds must have iconic features.

These are things like Zelda’s cut of dress and wearing of the Triforce; Batman’s pointy-eared helmet and black cape;  Storm’s white hair, glowing eyes, and winglike cape; Superman’s color scheme and external underpants (the artist may not have intended it that way, but that’s how a lot of people read it, which makes it an icon anyway).   These are the things that survive if the character is drawn by a four-year-old. They are shorthand for the characters themselves, and enormously helpful in recognition as well as determining personality. A character who steps too closely on another character’s iconic features is going to read as a parody (Tingle) or get lost in the mix (how many Super$NOUNs are there?), losing individuality in the process. If I draw a character with a leather skirt, a ferocious pose, and a chakram, she will likely be taken as Xena fan-art whether she is or not.

What are the iconic features of a piece of software?

At first glance, it seems that the function of the software is its main feature. Software that allows you to play a game where you run and jump, kill enemies, and collect items, for instance, has those four features right up front. However, those features are not iconic. Any number of platforming games allow you to do that. Instead, the iconic features might be an upgrade that gives the player a unique ability, excellent graphics or music, huge and difficult boss enemies, or a creative assortment of weapons. Multiple games may share iconic features, but will do them in different ways – Zelda and Castlevania both have excellent music, but their styles are radically different.

That’s all great as far as design. In visual design, I plan out a character’s appearance, refine their iconic features, and try to figure out what their features say about them before the character ever hits the page. In software design, it would be reasonable to say “We are going to do X, and we are going to do it better than anyone else.” At my company, we do it all the time. That is the start of an iconic feature, but I am not a software designer. I am a software tester.

How is this relevant to testing?

As a tester, my job is to protect the brand. Iconic features feed directly into the brand – my company’s software will be remembered for what it does differently. I can help to ensure the quality of the software by making sure its iconic features are present and beneficial. If there’s something we do differently than our competitors, it really needs to work and work well. Negative features are not what we want associated with our products. For example, related to hardware rather than software, is the XBox’s Red Ring of Death.  That may have been unintentional, but it has gotten irrevocably attached to the console. It’s our responsibility as testers to make sure that our iconic features are actually good things, and that we don’t have unintentional icons.

We can do that by approaching the software from a user’s point of view. What part of the software is going to be the most important? Will it be the neat weapon upgrades in a piece of game software? Will it be the custom data manipulation in a piece of reporting software? What about the error handling in a piece of automation software?

What part of the software will be the most memorable? Is it the smoothness of the UI, the ease of customizing its features, or the obnoxious way the filters work?

Any of those things can become iconic, and sometimes what the creator intended is not what the audience picks out. By thinking as a user, not a developer, we can pick out iconic features and make sure they’re actually awesome.

Act of erasing
A black and white memory
Transient panda

(…Memory, thoughts, recorded stuff
Black and white (ink and paper, panda colors)
Maybe a sad panda?)

All of this came out of a tiny panda eraser, souvenir of the W-A-T conference. The haiku was written as a pair, collaborative discussion over every word, theme, and phrase.

“If you have something you’re weak in, partner with someone who is strong in it.”

ETA: Transient Panda would be, according to the bass player of the group, a great name for a band.

In the world of testing, we use words.

These words are things like “Load testing, penetration testing, functional testing.” These words mean things, but not the same things to all people all the time.

If I say “I need to load test this product,” and mean that I want to see if it can hit a certain performance goal, and a coworker thinks that I mean I am going to load it until it breaks and see where the break point is, we are likely to have an argument about the best way to do it and whether it even needs to be done. Here’s the thing: that word “Load Testing” can mean both of those things in different products, or even the same product.

How do we come up with definitions that work for us? Maybe we don’t use the same word to mean three things. “Context” is another big one; I can talk about the context of a program, meaning the environment in which it runs; the context of a discussion, meaning what cultural or immediate environmental issues have invluenced it; the context of a bug, meaning what I had to do to make it happen. All of these rely on environmental cues, but.. get this.. you have to pull the meaning from the context.

Maybe instead of saying I am going to load test a product, I should say that I am going to verify that the product meets its performance goals. That removes the destructive connotation of the load-it-til-it-breaks kind of load testing. Maybe my coworker should refer to destructive load testing, and make it very clear that when zie’s finished, that product is going to be down or at least misbehaving.

Either of those or both would be good options, but neither is as short or snappy or convenient as just saying “I’m starting load testing today.”

There comes an additional layer of confusion when technical and nontechnical members of the team refer to a single thing using different words, or worse yet, use a single word to refer to multiple things. To me, a “spec” is a series of statements telling the developers what they will be doing with a product. However, coworkers on the team, but not the technical side, have referred to the program itself as a spec. This has led to enormous confusion.

How do technical team members communicate to nontechnical the difference between the map and the territory?

If they tell me I am receiving a spec today, and I got it two weeks ago, I am going to be understandably confused, and the product owner will be understandably upset when I ask for clarification, thinking that I’ve had the product for two weeks and have not tested it.

Communication problems are the root of the great majority of interpersonal issues I deal with, and they could be solved so much more easily if we would slow down and use the right words. While the meanings of words are not absolute and users of language must be sensitive to context, neither should words be used for things they are certainly not.