Tag Archives: quality

Testing is a topic covered with mysteries and misunderstandings. Some people believe that testing is simply a verification of a specification. Others rely on a false assumption that everything can be automated and there is no need involving test engineer into anything else than writing automated scripts. Many think that quality is a responsibility of only a few folks in the company and should not bother the rest.

My views are different to the ones stated above, as my expectations on testing are alike to other engineering disciplines, for example, programming.

In the first week of March I attended two Spotify unconferences about Continuous Deliver and Quality (which I also had the pleasure to facilitate). I am amazed on how many we were (people had flown in from a lot of other places), the energy in the room, the quality of the discussions, and the massive number of practical initiatives that where suggested and started.

One reoccurring theme was the importance of a stop-the-line culture and what that actually means. I have to admit I was quite active in those discussion, and also held a short lightning talk about the broken windows syndrome. My this simple formula when it comes to bugs is this:

You write tests to create a product without defects

When a test fails you fix the underlying problem

A bug found outside testing is just an unwritten test that would have failed

Failing tests are always fixed

Therefore: a zero bug policy is the only thing that works in the long run

In May this year I was interviewed at the SmartBear MeetUI user conference in Stockholm about my background as a journalist, Linux and open source, software development in general and testing more specifically. Here’s a post containing the video and interviews with the other speakers at the conference.

Are you in a software development team, trying to be agile? Next time the team gets together, ask:

How do we feel about the quality of our code?

Everyone rates it on a scale of 1-5, where 5 means “It’s great, I’m proud of it!” and 1 means “Total crap”. Compare. If you see mostly 4s and 5s, and nothing under 3, then never mind the rest of this article.

If you see great variation, like some 5s and some 1s, then you need to explore this. Are the different ratings for different parts of the code? If so, why is the quality so different? Are the different ratings for the same code? If so, what do the different individuals actually mean by quality?

Most likely, however, you will see a bunch of 2s or worse, and very few 4s and 5s. The term for this is Technical Debt, although for the purpose of this article I’ll simply call it Crappy Code.

Congratulations, you have just revealed a serious problem! You have even quantified it. And it took you only a minute. Anyone can do this, you don’t have to be Agile Coach or Scrum Master. Go ahead, make it crystal clear – graph the results on a whiteboard, put it up on the wall. Visualizing a problem is a big step towards solving it!

Don’t worry, you aren’t alone, this is a very common problem. <rant>However, it’s also a very stupid, unnecessary problem so I’m baffled by why it is so common.</rant>

Sisyphus, artistry, cult of quality, weaving, broken windows and all the other stuff you have to care about if you want to build high quality software. Here’s my speech on how we did it at Atex Polopoly, held at the SmartBear MeetUI user conference May 23 2013.

What is quality? Why do it energize us so much? Can we measure it? In a new Smartbear blogpost I trace the philosophical history of quality, and what that might mean for us.

Socrates started his quest to find out what knowledge is by taking on the lurking trap of the relativists, Protagoras and Heraclitus. Both meant that the world was in constant flux and that the only thing we could know was the sensations we get through our perceptions, or as Protagoras formulated it: “Man is the measure of all things.”

We recognize this stance from today’s definition of quality in business settings: Quality is the extent to which a product or service meets and/or exceeds a customer’s expectation. Quality is relative to the need of a user and is expressed as the right combination of price and quality. High quality, per se, is not desirable. Man is the measure.

I keep a close watch on these tests of mine
I keep my Jenkins open all the time
I see a defect coming down the line
Because you’re mine, I stop the line

A zero bug policy is the only valid way to look at quality, just like there should never be any broken windows in your neighbourhood. Here is the third part of my three-part series on building the quality in on the SmartBear blog.

Think of old bicycles in cities. A bike is left tied up on the sidewalk for a while. Someone steals the ringing bell. Left in that shape in the same place for long enough the bike will magically fall apart, as if rotting.

In 1982, the social scientists James Q. Wilson and George L. Kelling formulated a sociological theory from observations like these called “The Broken Windows.” A landscape, they meant, signals the type of social norms prevalent in the local society. A broken window left broken says: “it’s okay to break windows.” A broken bicycle sends the same signal.

If you don’t dare to stop the line, continuous integration might be waste. Here is the second part of my three-part series on building the quality in on the SmartBear blog.

In the first post of this series, I wrote about Toyoda Sakichi, the founder of the Toyota industries, who invented a loom that would automatically stop when a thread broke in the 1920. He thereby also invented the concept of “stop-the-line” to build quality in.

Incremental compile with visual feedback is a small step toward the automaticity of the Sakichi loom. Beyond that, we still have these longish feedback cycles, be it manually running unit tests or waiting on the automatic build or system tests run by our continuous integration (CI) system.

We in the software industry are still far behind when it comes to automated quality checks. Toyoda Sakichi for example invented the automated loom with stop the line capability almost 100 years ago. I write more about that in my first blog in a three-part series on building the quality in on the SmartBear blog.

It may seem old school, but every now and then I’ll start pristine Emacs and hack away on a piece of Java. I mainly do this for small stuff, since starting or setting up Eclipse takes a little bit too long for such minor projects. Even so, I don’t do this as often as I used to.

Why? I guess you know the answer: Nowadays, even the thought of not having instant feedback on syntactical and semantical correctness makes me shudder. It’s like coding in the dark. Incremental compilation is one of those great innovations that have increased the quality of our work.

Code quality. It has been haunting me for so long I forgot when I started to think about it. Do other people think about it? For sure. Do everyone? Certainly not.

I was doing RUP and before that some waterfall process from DoD. Before that I was programming Fortran. Now, what has been my single most important recommendation for reaching code quality?

Peer code review.

But enough. It just struck me how much I do not miss code reviews.

I’ll tell you why and I’ll tell you what is the replacement, because there should be one.

I had completely forgotten about code reviews until I ran into a colleague from the past and suddenly remembered a code review in particular.

It was humiliating. First of all, it was boring to print the code on paper and then spend hours reading it. Secondly, I had to face the fact that a lot of the code was copied but not used. I put a big X across the whole page of dead code. Humiliation became a fact when everyone saw it on the meeting.

It was so boring that despite we were caring about code quality and believed in code review, it was hard to make it happen.

Code review is dead – long live the new code review: pair programming!

There are today two very important practices for code and design quality, one of them is pair programming and the other one is test driven design.

Pair programming is code review because there is somebody looking at the code as you type. If you write code that is either hard to understand or breaks some design rule, it is spotted before you have put down hours into it.
It easier to change something before you get emotionally attached to it.

The old code review also had another downside, the reviewers became attached to the flaws they found. Imagine building up arguments for a position on the design of the code that you think needs to be fixed. You come to the review meeting and the design is already changed. Would you not be tempted to tell everyone what you had found, despite being useless information? I would.

Pair programming is also a setting where two people help each other to solve a problem. A code review is a meeting were a group of people discuss a single persons efforts, the one that was the last to touch the code. I hated it when it was me.

Bye, bye peer code review. Will you rest in peace and not be awaken ever again.