You can get a fair feeling for any software system’s quality by putting in just two hours. Here’s how.

Continue reading

Do you have a long list of bugs? You definitely want to have a zero bug policy, but now you have all sorts of minors, majors, and criticals. You’re not really sure how to get to zero bugs (were you ever there to begin with?). You have spikes where you fix the bugs and your graphs show a steep downward drop, only for them to turn upwards again and reach new heights. Just maintaining the list of bugs is a full time job! To add insult to injury, when a team member finally gets around to looking at a bug, they usually find that it’s outdated, not reproducible or part of some long forgotten removed functionality.

There has to be a better way! How can you shift the focus from managing bugs to ensuring quality? Here’s a system that’s easy to start using, and rewarding when you follow it.Continue reading

In modern software development there are three development practices that everyone should strive to apply:

• Automated testing
• Pair or mob programming
• TDD, test driven development

After many years of using and researching these practices in the development community there is no longer any question whether these engineering practices bring value or not – they do. It’s not a matter of opinion, it’s a matter of fact. We know that now.

Continue reading

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.

On high level I am following 3 main principles:

1. Testing is a creative activity.
2. What can be automated should be automated.
3. Quality is everyone’s responsibility.

Continue reading

På Agila Sverige 2012 höll jag min första ignite i form av en Majakovski- och Bob Dylan-inspirerad Spoken World performance om hur vi på Polopoly skapade kvalitet genom extremt fokus på automatiserade tester och en stoppa-bandet-kultur. Förra veckan fyllde konsultbolaget Adaptiv 5 år och firade genom att låte en utvald skara Agila Sverige-talare reprisera sina

Idag fick jag gästa SweNug och prata om testbarhet för utvecklare. Presentationen finns på Slideshare.

Continue reading

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

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. Interview with Peter Antman

(related article: Good and Bad Technical Debt – and how TDD helps)
(Translations: Russian)

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>

Now you need to ask yourselves some tough questions.

Continue reading

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. And here’s the slides: Build Quality In: Stop

I ended my talk on the SoapUI user gathering MeetUI singing the stop the line song. Now it has ended up on youtube. Here’s the text: 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 Becuse you’re mine,

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.

Here’s the eBook collecting my articles on building the quality in by stoping the line: Stop The Line – Why it’s crucial to include a human touch to your automated processes

Finding a bug in your application actually means you have at least two kinds of problems: symptoms and process issues. To deal with quality in a sustainable way, you have to fix both!

Continue reading

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

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

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.

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.