Software Quality Days Recap

I returned from the conference yesterday late at night. I left with mixed feelings and still am not 100% sure what I should think of the conference.

There were some good talks (all three keynotes and 2 regular talks), but most of the talks were too flat.

What I mean by that: The speakers talked about their topics only superficially, didn’t really go deep enough to create AHA moments. Everything felt like a rehash of things you already heard somewhere.

Strong accents of foreign speakers and Austrian dialect (when the talk was given in German, which was optional) made understanding the speakers quite hard sometimes.

Others gave tool-centric talks—for their own tools of course.

There were very few (2 I believe) talks where I could learn something new.

The best talk, by far, was given by a woman. The only woman who gave a talk. :disappointed: She is a psychologist and talked about motivation and leadership. This was a great talk. Very energizing.

The topic was indeed software quality. “Discussions” (talks) mostly revolved around whether you should automate everything or that people never ever should automate everything and every possible point in between…

There is so much to be said about these topics, you could go sooo deep. But noone did.

But enough rambling. I had a brief chat with one exhibitor at the conference. He was from the International Requirements Engineering Board (IREB). The IREB offers courses and certifications on requirements management. While you can take course on that, he also told me that you can get the course material you would need for the advanced levels for free. On their website as a download:

IREB downloads

Be aware that a few of the documents are just available as German versions, though. The „CPRE Advanced Level Requirements Modeling - Handbook“ is available in English, for example. And many more. If you want to brush up some knowledge regarding requirements management, take a look and browse their catalogue.

I also found an interesting tool vendor: CQSE from Munich in Germany. They offer TeamScale, a tool for measuring and improving your code quality. The important things they do (differently from others) is Test Gap analysis and Test Impact analysis. This is about how to test more effectively and efficiently.

Let me tell you in advance, this is no tool for small companies. You will face several hundred dollars per month in costs. You can try it out for free, but it surely is not for everyone.

What should I test (conclusion)

Alright. While I did only receive two replies (😢), I had interesting conversations with people about my question.

The gist is: I did not make it clear enough what I wanted you to focus on.

Here’s the question again:

[…] this event tells the speakers-subsystem to play sound file xyz.mp3. Because that is the correct one for the next stop.

Your task is to write (a) test(s) for the speaker-subsystem. It is critical that the right file is played, because there are lots of people on the bus that have bad vision. If this is your task, please tell me: What do you test for?

Here’s a possible answer I was looking for:

I tell the speaker-subsystem to play sound file xyz.mp3 and I verify that this sound file was played. We assert that no other file was played and that our file was played correctly.

The idea is to think in simple, small steps. The system had one job: Play a given sound file. Our test had one goal: Verify that this happened.

Try not to make it harder than it has to be.

If that does not make sense to you or if there are more questions, let me know.

Yours,

Holger

What should I test (continued)

Yesterday I wrote about a bus.

I am a bit disappointed that I haven't received any answers. Perhaps you felt like it was too easy? Or perhaps you just did not have the time to write an answer. Or my question was too hard? I thought I explained everything in detail and that it should be fairly easy, but I might be wrong in thinking that.

I do need you feedback on this. A single sentence would be enough. If you do get any value from these emails (simple entertainment would count as a value), please take the time to respond.

I'll be in touch again on Monday. Let's see where we go from there 😉

Yours,

Holger

What should I test

I recently did a survey among the developer-team of a client. I asked several points regarding their knowledge in software engineering generally, and experience regarding software quality specifically. This was done to be able to prepare my workshops for this client. Of course, I wouldn't want to talk about things they are already experts in.

The topic > 95% of the developers mentioned they would like to get guidance on and learn more about was: Testing. It didn't come to me as a surprise, because I worked with the team the last three months and I saw the code base.

Of course testing is a topic with many smaller subtopics. This team feels confident in being able to generally write a test. But they struggle in knowing what to test. This is an important distinction to make.

In my experience it gets easier to know what to test, when the system under test (SUT) is deliberately small. If you have a single class that does one thing, then it could be a bit easier to say what to test, then for a class that does 4 or more things.

Think about it: Imagine a bus (the thing that drives on streets and eats humans).

When you design software for the bus, you have to think about lots of things. The doors shouldn't close, when there is somebody just enterering/exiting the vehicle. The display that shows the next stops and the final destination needs to be updated after you just left a stop and head for the next one. The switches for the lights (inside and out) should work as expected. And millions of other things. I am no bus expert, if you haven't noticed yet…

Now think about one single component of the bus and its software: The sub-system that "reads" the name of the next stop. I will simplify again. If you know buses please cut me some slack (and please do tell me what I got wrong!).

All this subsystem does is to play the correct audio file that is "connected" to the next stop. It doesn't do this on it's own. It is synchronized with the display. So I imagine, there is an event that tells the display to update (and passes the data for the next stop). And this event tells the speakers-subsystem to play sound file xyz.wav. Because that is the correct one for the next stop.

Your task is to write (a) test(s) for the speaker-subsystem. It is critical that the right file is played, because there are lots of people on the bus that have bad vision. If this is your task, please tell me: What do you test for?

I am awaiting your replies.

How to start

Quality is a big topic. We established that already in the last year.

In talking with other people and getting responses from different teams, I noticed that it might be hard for people to find out where their processes could be improved.

I created a small survey you can take for yourself: https://holgerfrohloff.wufoo.com/forms/m140eib41rss2t4/

This evaluation might show you, where you could improve, or which topics should be addressed to improve your quality assurance.

If you have questions regarding this, reach out.