Testing And The Two Values of Software

Feedback Testing 8 Comments

The Two Values of Software

Sure enough: If your team’s software fails to provide value now (or in the near future), something’s gone badly wrong. You don’t like your software project to end up similar to this, right?

Smoking Remainders
Smoking remainders of a ‘Biikebrennen’ — don’t let your project end like this.

As Alistair Cockburn explained in “Agile Software Development” software development can be seen as a game played in rounds — and most teams prefer to stay in the game for many rounds.

To me it’s interesting (and a bit worrying) that most of the testing techniques and approaches are focussed on whether the current version of our software…

  1. is in fact the right software and
  2. if it works correctly.

In other words, testing focusses on validation and verification, it concentrates on a relatively short period of time: the next release.

Now, Uncle Bob Martin presented the idea of the primary and secondary value of software in episode 9 (‘The Single Responsibility Principle’) of his CleanCoders video series. He presents the secondary value first (which most people believe to be more important): ‘The secondary value of software is its behavior.’ He also explains the primary, more important value as: ‘The ability of software to tolerate and facilitate such ongoing change is the primary value of software. The primary value of software is that it’s soft.’

In Alistair Cockburn’s description the order is reversed (see Agile Software Development, 2nd edition p. 37 ff), but in my opinion the order isn’t always that important: I am worried that testing doesn’t consider one of the two values of software.

To my experience, essentially all projects focus on current or near-future behaviour of software, but rarely actively work to keep the software ready to deal with future requirements. I understand that YAGNI (You ain’t gonna need it) may play a role here. But mind you: YAGNI mostly applies to actually implemented features that are not needed. It may also be valid in order to prevent going overboard with too much abstraction and flexibility. In the end, you always need to find a balance between following and ignoring the SOLID principles (a good part of the Clean Coders videos covers this in detail).

Concerning the 1st value of software (according to Uncle Bob Martin), I’m convinced that testing needs to answer questions like this:

  • Is “the ability of software to tolerate and facilitate such ongoing change” a job purely for programmers?
  • Can software testers contribute to the primary value? Should they?
    • If yes, is this part of the job or should we keep out of this business?
    • How can we as testers contribute?
  • Can other disciplines help?

What do you think? Is this topic important for testing? Should we treat it in the way Michael Bolton advises testers with respect to “Quality Assurance Business” (spoiler alert/hint: He advises us to stay out of it)?

I personally think testers should get involved: A tester is somebody who knows that things can be different, as Jerry Weinberg says.

Also, I definitely want my clients, as well as their clients, to be happy with the software I help to develop, not only today, but also in the future, even when most original developers of a software system have left the team or company.

When your project (or product life cycle) comes to an end it should stay in your memory not like the smoking remainders of a fire, but with the bright colours of a great sunset.

Bright Sunset
Bright Sunset

Tools for Testing — 1

Learning 2 Comments

I recently took the excellent Black Box Software Testing Foundation Course offered by the AST (Association for Software Testing).

The course came with a lot of extra material in addition to the primary deck of slides & videos: Articles published by a number of people, blog posts, exam guides. I used Papers, which helps to organise, well, papers. It manages meta information about the papers, such as publishing date, title and authors etc. and allows highlighting text, adding notes and more. I also liked using the iPad version of the program (there’s a way to sync your library on your computer and iPad), because I don’t always work at my desk.

The other tool I found useful is GraphViz, an extremely powerful program to describe and draw graphs. The graphs are described in a text file (there’s a complete language that describes graphs, but for many purposes you’ll only need a small set).

digraph example_path {
graph [ dpi = 150 ];
 rankdir = LR;
 fontname="DejaVu Sans";
 fontsize = 20;
 node[shape=circle,fontname="DejaVu Sans"];

 1 -> 2 -> 5 -> 6 -> 7;
 2 -> 4 -> 5;
 2 -> 3 -> 4;
 3 -> 6;
 6 -> 2;
 label = "\nBranches & Loops";
}

GraphViz comes with a command line tool dot. If in the same directory as the file that holds the description above, one can use

dot -Tpng file_name_here -O

to generate a 150 dpi PNG file, which looks like this:

An Example Path
An Example Path

GraphViz can create much more complex images (see the GraphViz Gallery for examples), however I find just a short text file and a simple terminal command covers a lot of ground and there’s no need to create ‘hand made’ images anymore.

Both programs Papers and GraphViz are available for Windows, OX S and the iPad/iPhone (GraphViz is called Instaviz on the iOS devices).

What non-typical tools do you use in testing?

© 2012-2023 Stephan Kämper — Mastodon

MENU

Navigation

%d bloggers like this: