I love Hannibal TV series. It's something you don't want to watch while in delicate mental state or eating, but other than that I think it's finally something that meets the level of quality that the legacy of Hannibal Lecter deserves and raises the bar (almost) to the height where it was after Silence of the Lambs.
Speaking of quality, in one the latest episodes of Hannibal Dr. Lecter stated: "It's the distinction that adds an expectation of quality." This is something that attracted my attention to the extent of writing this blog post.
The context is a dinner Dr. Lecter (psychologist) serves to his colleague Dr. Sutcliffe (neurologist). The full dialog from the episode goes as follows (ripped from Subtitleseeker):
Dr. Lecter: The Jamón Ibérico.
Dr. Sutcliffe: Still love your little rare treats, don't you, Hannibal? The more expensive and difficult they are to obtain, the better?
Dr. Lecter: It's the distinction that adds an expectation of quality.
Dr. Sutcliffe: Not always.
Dr. Lecter: Well, for Iberico, only a few thousand are selected each year. But is the pig, once fattened and slaughtered and air-cured, really superior to any other pig? Or is it simply a matter of reputation preceding product?
Dr. Sutcliffe: It's irrelevant. If the meat-eater thinks it's superior, then belief determines value.
Dr. Lecter: A case of psychology overriding neurology.
The major suspense revolves around the suspicion that Dr. Lecter might be serving human being to his colleague. But my focus was on the quality-bit of this discussion. Of course... :)
 |
| Jamón Ibérico |
I find it fascinating to look at this phenomenon in our line of work, software development and testing. Expectations towards software products' quality are rarely affected by their distinction. Majority of software development is duplication. Either you duplicate entire products or you duplicate parts of them. Some parts and algorithms may be distinctive, but not in a sense that they add an expectation of quality.
Majority of professional software is built to fit the purpose. The quality is built to acceptable level, at best. As I learned in BBST Foundations 2.0 course, testers live and breathe tradeoffs. People don't walk the extra mile to make something unique, because it doesn't pay off. "It's unprofessional to produce over-quality", some say. We have come to accept that software is just software and it doesn't have to represent the highest quality.
This makes me sad.
When it comes to Jamón Ibérico, Kobe beef or Westvleteren 12 it's the refinement that separates them from the rest, that gives them distinction. People take very good care of these products and making them. Care beyond serious. They bring quality to the level that it's hard to improve. I have rarely or perhaps never seen that in software development and testing industry. Excluding video games...
Last week I was at Nordic Testing Days (blog post coming up ;) and got to meet wonderful people. With some of them we discussed about this subject and we came to a conclusion; People making video games may not have the latest methodologies and techniques in use, but they more than offset that with care and love towards video games. They make it their personal responsibility to refine the game to a state that it becomes distinctive. They want to create something unique. Of course there are video games that are not developed like this, but the ones that matter are. And always have been.
 |
| I <3 BF4 |
I expect a lot from these games, gaming companies and people. I expect refinement. I expect display of love towards video games. I expect the pride that only the people who create something distinctive can carry.
I expect quality.
Couple of my last posts have missed quotes. Let's fix that. Apart from the quotes from Hannibal, I didn't find anything that would fit this post. So I tried to come up with something witty myself:
"When you love what you do, you refine the history that your future is built on." -Sami Söderblom
Your truly,
[VUS] pr0mille
Not too sure what you are getting at here? If you have breakfast cereal or a pizza are you expecting it to be of the highest quality?
ReplyDeleteI dont know of many people who's passion in life is car insurance so are you expecting them to sweat blood and tears when working on a back office app that processes car insurance claims?
Phil: I thought that Sami's point in the game comparison was that instead of thinking what was ordered and delivering that and just that you could also try to make your product something you are actually proud of.
ReplyDeleteBesides, the car insurance claims app probably has a lot of users who use it as a tool to work every day. If your application is great, it certainly makes its users a lot happier and thus they feel that they have received a quality product.
I believe people should strive to create something unique and brilliant regardless of how "boring" the use case is. This is true especially when something is tailor-made to a company and the users have no say in what they can use as a tool. If they only have one choice then the software provider who does that one distinction can create a whole lot of happy users.
Isn't that then a discussion with the stakeholders about what their definition of quality is? Otherwise we're on that slippery slope again about Testers being the gatekeepers of quality and defining what it is
ReplyDeleteor I might be reading too much into this post - if the customer wants to serve cheap hamburger then dont try and convince them that Kobe beef is a better option?
Good question, Phil. I think that test management in itself is always risk management. Let's look it at another angle. Sorry if I'm babbling and stealing Sami's page but this is an interesting subject.
DeleteThere's the _action_ of testing, where you actually try out things and then there's the _process_ of testing. When running the process of testing you always make decisions on which parts you perform the action of testing. Therefore you also make decisions on which parts you _don't_ perform the action of testing and concluding the risks accordingly.
Therefore the test process in itself is defining the quality. That's the service we can provide, a straight-on assessment on software quality.
The stakeholders aren't test professionals, that's why they hire people who know what they are doing and present the risks accordingly. Might be that they are presuming they are being offered the best possible alternative (hey, they're paying for it, aren't they? They expect quality) or they just don't know how to measure it.
Thus a true testing professional shouldn't in my opinion silently just perform the tasks asked of him ("run these 120 cases and then we're done") but actually be interested in the things the cases aren't covering. Just simply by asking: "okay, we'll do this - but have you thought about this?"
Usually just a thought raised up to the stakeholders about a risk could end up drastically improving the end quality of a product. It might sound really obvious but many times the stakeholders approve gos and no-gos without actually knowing anything else about the system except the ratio of pass/fails.
How about if sometimes we would report the worst case scenario? "If this module fails, you will run out of money. Do you really want to rush testing on that? Are you willing to take this risk?" As a testing professional, you need to bring all the data the stakeholders need in order to make a qualified decision. That is how you help stakeholders define quality.
TL;DR: I think the recap is this: if all the people in a software project would actually care about the end product, be proud of it, then I think a lot better software would be built. It's an ideal, sure, but it's really something to strive towards.
Go ahead, Tuomas. Babble away! :)
DeleteYou raised a very important point; Testers' right to make decisions. To effectively practice testing we need to constantly learn, interpret results and to some extent make decisions based on them. Whether to release a product or not should not be one of them, but how to focus testing, steer activities, pass judgment in order to grow suspicions... very much so.
Hi guys,
ReplyDeleteAnd thanks for the comments! This is exactly the kind discussion I wanted to provoke with this somewhat vague post. :)
Tuomas got to the core of it; We should be proud of what we do. That's how we get our reputation as people who build quality. No matter if we're testers, developers, project managers, whatnot. And no matter if we're making cheap hamburgers or Kobe beef. If the customer wants a cheap hamburger and nothing else, you should make it as good as possible within the constraints of context. That elevates "want" to "need".
I have a claim; Bad quality happens, not because we fail to understand what customer wants, but because we fail to understand what customer needs. We fail because we're lazy, ignorant, over-effective, etc. or just because we don't want to understand.
Sami
We should concentrate more on the reputation, the expectation of quality. That is valuable. If people know that we always deliver that +1, that we strive for excellence no matter how trivial the product or task at hand, they'll expect good things from us in the future. They start to trust us. And I cannot stress the value of trust enough. It gives us freedom to do things the way how we like them to be done, perform well and furthermore build trust.
ReplyDeleteAnd that is pretty awesome.
AND performing the best you can feels great! Why go for average when you can do so much better. Pata negra rules...
ReplyDeleteIt really does! But some people don't want that. They'd rather be miserable. I fail to understand that kind of thinking, but there's a lot of that in our industry too.
DeleteAnother undying quote:
"Be a yardstick of quality. Some people aren't used to an environment where excellence is expected." -Steve Jobs