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?
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…
- is in fact the right software and
- 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.
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?
I find it surprising and sometimes frustrating that people appear to read the title of a blog post without reading the rest of it—or simply misrepresent what I’ve written. In the post you refer to, I make it abundantly clear how I believe testers can contribute to (what you seem to call) primary value, and what I believe limits that (testers don’t write the code, nor design the product, nor determine the schedule, nor the budget…).
You then follow your questions with “I personally think that testers should get involved”, implying that I suggest that testers should not be involved. In this sense, your “spoiler alert” isn’t a spoiler alert at all, unless “spoiler alert” means “misrepresentation alert”.
Thank you for the comment and feedback.
I apologise for apparently having been unclear in my blog post. I will be as explicit as I can in my response, as well as my explanation of how I understand your comment and the mentioned blog post (even at the risk of coming across as direct).
I guess that you think that I didn’t read and/or understand the blog post. You didn’t say that explicitly, what you said is ‘that people appear to read the title of a blog post without reading the rest of it—or simply misrepresent what I’ve written’. However, I have the impression that ‘people’ includes me.
Let me explain what I’ve read in and understood form your blog post. It starts with this statement:
My understanding is, that the main part explains what testers can and cannot contribute to a product or project (and I agree with it): Testers can, for example, contribute information to assist decision makers in making the right and well informed decisions. Testers cannot assure the quality of the work of others. The blog post ends with:
I have to say I still understand from the post, that you advise testers to stay out of the quality assurance business.
I did not mean to imply that you’re suggesting that testers should not be involved in testing the two values of software (as mentioned by Uncle Bob Martin and Alistair Cockburn). If I did, please accept my apologies.
Maybe this wording is better (or maybe I shouldn’t have included the reference at all):
I now also see that your blog post says ‘get out of’, while I wrote ‘stay out of’. — Would you advise a tester to also ‘stay out of’ the quality assurance business, in case he/she isn’t already in it?
In any case, thank you for helping me to think about the topic even more.
Thank you, Stephan, for a thoughtful reply to my rather cranky one.
I think you’re suggesting that some testers have a limited notion of the quality of the product, and that they tend to focus on capability, reliability, performance, and so forth. That’s my impression too
Testing is all about identifying things that might threaten the value of the product—anything that threatens the product’s value.
“The ability of software to tolerate and facilitate such ongoing change”, to me, covers several dimensions of the quality of a product. In the heuristic test strategy model, we call out those dimensions explicitly, under the overarching dimension of development-related characteristics of the product. That dimension is about answering this question: How well can we create, test, and modify it? The subcategories include:
Supportability: How economical will it be to provide support to users of the product?
Testability: How effectively can the product be tested?
Maintainability: How economical is it to build, fix or enhance the product?
Portability: How economical will it be to port or reuse the technology elsewhere?
Localizability: How economical will it be to adapt the product for other places?
It seems to me that you’re asking whether testers should include these dimensions of quality in their observation, evaluation, and reporting of the product, or whether they should not. I agree with you and Bob Martin: these are important dimensions of product quality, just as capability, reliability, and performance are, If testers observe problems in development-related quality criteria, to me that’s reportable information. (As a tester, I’d try to be careful not to cross the line into dictating what programmers should do, unless I’ve got both experience and authority to back that up; that is, if my actual skill in development is greater than theirs, and I’m the development manager.)
Testers report on capability or reliability problems, but that’s that quality assistance, rather than quality assurance. If testers report development-related problems, to me, that too is quality assistance, not quality assurance. I think referring to my blog post muddies the issue, even in your new version. It’s not a good parallel, in my view.
As for your last question: get out; stay out, unless it’s a) your own work over which you’re assuring quality, and/or b) you have actual authority over the product and the people making it.
Again, thank you for your reply.
—Michael B.
Hi Michael,
you wrote:
No worries, you’re welcome.
I find the heuristic test strategy model adds very interesting and important points.
Thanks for coming back & adding to the topic!
Stephan