Archives for category: Artistry

The Mallet is an amazing artifact that, wielded in the hands of a software tester, beats all defects and design flaws out of a program and leaves it shining, newly forged and ready for release. By virtue of its inbuilt magic, it removes user experience problems and makes the programmer’s beautiful intent accessible to users of all levels of skill. Its power is so strong that it can actually correct for environmental problems and hardware inconsistencies before they even happen. A single strike of the Mallet can remove a defect at the code level. Repeated use can turn a program into a work of art, released to its adoring audience to the sounds of cheers and showers of money and fame upon its creators.

Instead, we’re stuck with the messy and occasionally dangerous process of manual testing, automated testing, and using real human beings to get imperfect results.  Whyever would I want to do that, you ask? After all, it could actually break the software! People miss things, and human judgment is fallible. The Mallet seems like a much better way to go. Unfortunately, all tests to create such a thing have failed, and I do not possess the Magical Mallet of Quality.

Rather than relying upon the abstraction of a tester somehow creating quality and infusing it into a program through sheer force of will, it may be more effective to design competently, execute with style and grace, and release with the knowledge that your shining, beautiful product is probably going to make somebody, somewhere, a little less or more happy than they were before they used it.

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.

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.