I’ve built a few Arduino based projects over the last twelve months, including an MQTT based test throughput  counter and a ‘Buildosaurus’ glowing RGB model dinosaur to indicate product build health. The most complex so far is an IR remote control platform to solve an accessibility problem. I’ve used 16×2 LCD displays in several of my projects, but for the remote control power is constrained as I want to run it from a 9v cell.

Driving the display itself is not a big problem; quiescent current is the enemy. In my prototype I used an NPN transistor to manage power for the display circuit and this worked perfectly well. For the final build I went with a white on blue HD4470 compatible display – same interface therefore a straight swap. However, I wired it all up and I just see random characters displayed, nice!

I found that if I ground the R/W pin then all is fine, which is weird because the pin is already grounded via my transistor. Anyhow, not a viable solution since a connection to ground will bypass the power management. OK, this display shares the same interface, but behaves slightly differently. A while later – having changed obvious components just in case they were faulty – I stop looking at the circuit and take a look at my code:

//Power up LCD and initialize.
digitalWrite(lcdPin,HIGH);
lcd.begin(16,2);
lcd.clear();

Seems fine to me: turn on the display (via a transistor), initialize it and start using it. I started to wonder, what if the display is not quite powered up when I call lcd.begin() ? I add a 100ms delay before the begin() call and all works fine. I’ve convinced myself why the fix works, but is the defect a hardware or software one ?

Here’s a photo of the remote, in case you were wondering what it looks like…

“The executive who decides whether or not you will be allowed to release your product, will not be looking at your product code to make that decision. They will be looking at your defect numbers and your test pass rates.”
This is how I started a conference call last week, as part of a session to encourage more focus on test.
In a truly Agile team there are no dedicated testers or developers. Everyone is a software engineer and everyone shares responsibility for the quality of what is produced.
In an ideal world everyone would harbour a deep desire to ensure testing has been done fully, before even considering the possibility of coding more features. Sadly, in reality it is all too tempting to charge ahead with the next feature on the list. Because it is so hard to know when you are ‘done’ testing and so easy to see the features you’ve not started yet.

So I find myself trying to raise the profile of the business of testing, why we do it, and how our process ties into it. Software engineers find it easy to understand all the features that need to be written to meet the requirements. What is needed is a gentle reminder that the gateway to release is controlled by someone who will not try the product, they will not read the code, or even the documentation. The measures that they use to determine fitness for release are defect trends and test passes. They look to see that the rate of high severity defects being raised has dropped off, and that the tests are, if not 100% passing, then very close to it.

In a traditional team, one or two key people needed to worry about that and direct their fixed teams accordingly.  Part of being an Agile team is making sure that everyone understands these metrics and takes their share of responsibility to prioritise test in their planning.

Shortly after my conference call, one of the local component leads told me that another team had let him know they would not be developing the feature he wanted until the next sprint, because their plan was full with testing in the current sprint.  What’s more, he understood and accepted that this took priority over his request. So, for the moment at least, the message is getting through.

I’ve been having some thoughts about how we could measure the effectiveness of an agile test process.

One of the measures I think could work is ‘Time to defect’ (TTD). That is the time between a coder injecting a bug into the system and the time the official defect reporting the problem arrives back on their desk. The lower the TTD the better.

A low TTD has many benefits, not only does it indicate that the testers are finding defects quickly, but it also gives the coders the chance to fix the problem when the code is still fresh in their minds.

(more…)