I’ve found many people to care for a high unit test coverage. It tells you something about how well your code is tested. Or does it?

Unit tests typically test the smallest piece of code. It is an excellent strategy to write your tests in conjunction with the production code. The tests help you shape the interfaces and help explore the problem domain.

Big question is: does the business/product owner care? What do those tests tell him (or her) about the actual functionality delivered? Fairly little really, if any at all. This boils down to the next question: why care about unit test coverage then?

 Read more

Agile is a mindset.  It comes with certain behaviour and a certain culture.  As with many things most people and organisations have to go through some serious change before they can actually be successful within an Agile setting. Change is hard, and it takes time.  I strongly believe that it helps when you simply understand what you’re trying to achieve.

‘Agile’ is no buzzword or a complex management theory, it’s natural behaviour for millions of people;  It’s not for managers.  It’s for everyone and it’s easy to understand as long as you acknowledge that ‘being Agile’ has nothing to do with the process you follow or the tools you use.  ‘Being Agile’ is about culture, behaviour and mindset.

This post intends to reword the Agile Manifesto in a way that makes its meaning obvious.  Understanding something,  doesn’t mean you’re immediately capable of doing it, but it’s a very good first step and it will help you on your way.

 Read more

Architecture refers to a very broad concept that creates a lot of confusion in the IT world. Why is it that such a common term is so vague? In this article we will give you an explanation for it.  Read more

A number of my colleagues and myself recently decided to share our knowledge regarding “performance” on this medium. You are now reading the first blog in a series in which I present a test-driven approach to ensuring proper performance when we deliver our project.

Test driven

First of all note that “test-driven” is (or should be common in the java coding world. It is, however, applied to the unit-test level only: one writes a unit test that shows a particular feature is not (properly) implemented yet. The test result is “red”. Then one writes the code that “fixes” the test, so now the test succeeds and shows “green”. Finally, one looks at the code and “refactors” the code to ensure aspects like maintainability and readability are met. This software development approach is known as “test driven development” and is sometimes also referred to as “red-green-refactor”. Read more

Lately I am doing a lot of coding with Play! 2.0 in my spare time and I must say it is a really nice framework that makes web application development easier. I am also trying to figure out if I can do all the stuff with a Play! 2.0 project like I can do with a Java EE project. An important aspect for me is adding the project in Jenkins. Since there is not a Jenkins plugin (yet) that supports Play! 2.0 does not mean that it is not possible!

 Read more

There are not a lot of companies who publish any of the source code online. And why would they: documentation takes time, you need to package it some way and the only thing that can happen is that somebody secretly becomes rich from your work. Worse yet, the company may loose face when security bugs are discovered.

In the meantime, we developers know all know to look at open source involvement when we look at hiring. We know that if you publish code online you are willing to be open for suggestions and criticism from the outside world. Further more, if you are able to get patches accepted, you know how to work with a team you have not worked with yet and how difficult it can be to do it right. Working openly will set you open to opinion, and if you think your code is good, why should you not?

 Read more

Browsing through the log files of any production system, you will be amazed on how many messages are logged on the Error level. It is not uncommon to find hundreds to thousands of error messages per day! When you point these out to developers or system administrators, the usual reply I get is: “Oh, that is normal”. Let me tell you: it is not normal. Any diagnostics message that is logged on the Error level, is an indication of a failure in the system. When a error log message references a situation that is not erroneous, that is an error in itself and they may  blind you for any real errors that are logged.

The fun part is that the application log is a very good indicator of the system’s maturity.
 Read more

Couple of weeks ago I realised something. As an Agile tester it’s really hard to communicate bugs! Testers are known for bringing bad news, but it is not easy to do it correctly. Specially when you’re in a Scrum Team and the heat is really on with bugs or issues flying all around.

 Read more

In 2009 Steward Reid predicted that within 10 years 70% of all software development would be done with some form of Agile methodology.  Due to the growing need for ‘’hands’’ this would result in having to employ also the less qualified testers on these projects. The first point he made is absolutely valid, the second point is only valid looking at it as a commercial opportunity (you don’t need hands if you work with qualified people), maybe he only said it to comfort the people who fear loosing their jobs because of this shift. It’s obvious that now Agile is becoming main stream there is a growing demand for qualified testers. Read more

Last week I joined the QA&TEST conference in the beautiful town of Bilbao. In this post I’ll give an impression of some of the presentations I attended to and the idea’s I picked up. Most valuable sessions I attended were “Pushing the Boundaries of User Experience” by Julien Harty and “Automated Reliability Testing via hardware interfaces” by Bryan Bakker. Read about it in more detail in the article.

 Read more