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 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, 2^nd 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 1^st 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

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

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?

I find it interesting to keep track of where and when I run into new information relevant to software testing. This time it was an article in a German magazine for dog owners (issue 6 2012, to be precise). The topic was anthropomorphising dogs. And I think digging deeper into anthropomorphism can help us understand software development and testing better.

What is anthropomorphism?

This is the definition of anthropomorphism given on Wikipedia:

Anthropomorphism or personification is any attribution of human characteristics (or characteristics assumed to belong only to humans) to other animals, non-living things, phenomena, material states, objects or abstract concepts, such as organisations, governments, spirits or deities. (http://en.wikipedia.org/wiki/Anthropomorphism)

Why is it worth thinking about?

The German magazine article mentioned Adam Waytz as the author of a study and that way I found “Social Cognition Unbound: Insights Into Anthropomorphism and Dehumanization” by Waytz et al. (citation see end of this article).

The authors of the paper (details see below) say that “computers … can seem to have minds of their own” and mention that people “…curse at unresponsive computers…” (at least I have). If similar situations happened to you, maybe while testing software, then anthropomorphism affects your work.

I’m convinced that this topic requires more than a single post. This post is an introduction to the topic.

A brief summary of the paper

The authors discuss reasons for anthropomorphism as well as dehumanization and present three “primary factors——elicited agent knowledge, sociality motivation, and effectance motivation” which determine whether someone is likely to anthropomorphise or not.

Let’s look at the three factors:

Elicited Agent Knowledge

Anthropocentric knowledge is accessible and/or applicable.

Social Motivation

This is the need to be accepted, part of society and to connect to others.

Effectance Motivation

The motivation derived from understanding, explaining and (being able to) change or influence the environment.

Some ways this affects software testing

I will not go into much detail in this introductory post, but will instead list some of the behaviours that can be explained through this model:

1. Effectance motivation and scripted testing
   I will not add to the discussion of the pros and cons of scripted testing, but instead introduce a possible explanation why testing and testers are not well respected in environments where scripted testing is used.
   When a rather strict execution of scripted test cases is demanded, the testers can’t influence their environment much. It’s about following scripts, manually operating the system under test and checking whether given conditions are met or not. In some cases changing scripts is not allowed, just following them. To others this looks like manually executing source code, something a computer is much more suited for. In other words: Testers work like computers, they’re perceived less human-like than they are.
   That way effectance motivation is inhibited, leading to dehumanising of the testers (at least to a certain degree).
2. Test versus development teams—and what they perceive of each other
   I’ve worked in an environment where testers and developers were separate from each other. The most important communication was though the artefacts we were exchanging: Installed software on the test system, defect reports in a bug tracking system and may be the source code.
   We couldn’t see each other as the humans we are, it was (mostly) artefacts, the ‘other side’ didn’t even look remotely human. Thus neither side felt much respect for each other.
3. System complexity
   The tester assumes the system is more complex than it is or has an intention that’s not there.
   Software systems, at least today, do not have a human intent. If a system under test is subject to anthropomorphism the tester assumes the system is more complex (or complicated) than it actually is and therefore puts more effort into testing. This can lead to new ways of testing or new test ideas and therefore improve the testing.

Leaving thoughts

This post introduced the idea that anthropomorphism affects software testing and described some of the effects. As mentioned above, I think there’s much more to discover for testing, so stay tuned for more posts about the topic!

Do you have examples of anthropomorphism in software testing? Please share them.

Cited paper

Waytz, Adam, N. Epley and J. T. Cacioppo. 2010. Social cognition unbound: Psychological insights into anthropomorphism and dehumanization. Current Directions in Psychological Science. 19: 58-62.

However, I got the idea to pick a personal word of the year from my wife. This idea goes at least back to a blog post by Ali Edwards. The notion (as I understand it) is to pick one word to guide you thought that year. To me this is an interesting change to the more traditional new years resolutions, since it conveys the idea of having a guidance, or vision rather than setting (usually) unreachable high aims.

It seems to me that a personal word of the year helps to move into a chosen direction. In a way it’s very much like a good vision for Scrum (and other!) software development teams — vision condensed into a single word. For all your small and bigger assignments you can quickly check, if what you’re attempting matches the idea of your chosen word, and then consciously decide if or how to proceed.

My word of the year 2013 is:

My word of the year 2013: Explore

Do you pick a word of the year for 2013? Which one?

Uses of Twitter

First of all: Why discuss ways to use Twitter as a tester?

Well, almost all software is used in ways not anticipated by its creators. There are a lot of possibilities for a user to interact with the software — not caring about the system creators intentions.

And this is something a tester should practice: Find new ways to use given things.

I learned about a few more uses of Twitter at the conference and thus suggested the topic “How do you use Twitter (or other social networks)” for the Open Space session at the Agile Testing Days 2011 in Potsdam.

Thankfully enough people were interested in this, so here’s the result of this session in just one shot:

In the following sections I’ll comment on the items in the same order as we collected them on the flip chart.

Uses of Twitter

1. Collect Haikus

   For a start I put up this one, still impressed by Liz Keogh’s Keynote about Hypnosis & Haikus.

   To generalise, I think Twitter can be used to share & collect about everything — given an account or hash tag to group it in some way.

2. “Learn stuff” & “Solve problems”

   This one boils down to ask a question using relevant hash tags (e.g. #Ruby, #testing, #quality) and getting help quickly. At other times you get very interesting input you didn’t knew you needed before actually getting it.

3. “Stay connected to people”

   In my opinion staying connected to people I met/meet at conferences (or local gatherings) is extremely valuable. According to Neal Ford’s article Twitter Matters: Keeping Up with Weak Social Links, closely related people (family, friends or colleagues we see every day) often have the same information sources as we do, so their information isn’t new to us, while people we don’t know at all, tend not to share enough common interests, so their information isn’t as relevant to us. However, people we don’t meet too often (say once a year) have the most relevant and new (for us) information to share.

4. “Virtually attend conferences”

   I haven’t done this (yet), but I imagine it to be fun. One of these conferences is the “ALE Bathtub Conf”, which you can attend in the bathtub, because no one would notice. See Bathtub Conferences

5. “Mine opinions about products”

   This is an interesting one I hadn’t thought of before, but was immediately obvious when explained: Search tweets about a product and attributes people typically use when tweeting about it: #great, #FTW, #fantastic, but also #FAIL, #WTF, #isitjustme.

6. “Inspiration”

   Read what others think about a topic and follow shared links… This can yield entirely unexpected results/connections between topics.

7. “Making friends”

   Sometimes the Good Thing ‘just’ happens. An example Lisa Crispin shared with us: She tweeted about being stuck at home without a plan for the weekend (since the original plan to go to a conference in London fell victim to the Ejafjällajökull eruption in 2010). She read a tweet by someone from England who could not fly home due to the volcano, tweeting from a bookstore in Denver, CO. Result: They met, did some sightseeing and became friends.

8. “Production monitoring”

   Someone mentioned they’d monitor performance of their web application, by monitoring the tweet rate about certain words (I assume company-name, #slow, #down could be a start…) The more tweets (per time unit) they’d see, the slower the web application would perform.

   To me, that’s fascinating, even though it’s more a (very good) heuristic, rather than a definite measure: Your users might come from a single time zone, so a performance drop during the night isn’t noticed immediately, or there is a problem — but no increase in the number of tweets because of another significant issue, e.g. a network outage in the wider area.

9. “Get customer/tech support”

   Some companies are very good at listening to tweets about their product, and answer with helpful tips and/or explanations.

10. “Support for personal/professional growth”

    This seems to be similar to “Learn stuff” & “Solve problems”.

11. “Find a new job/project”

    This happened to me: After the end of a recent project I tweeted about my availability, got contacted, had a short interview and found a great new project. Excellent!

12. “Overload of tweets”

    Obviously this entry isn’t a use of twitter, but rather a (possible) problem: There are only so many tweets you can read per day. Tweeting about almost everything in your life might result in people unfollowing you.

13. “Get to know people”

    By following people, you get to know (a certain aspect of) them: How/What they think about a topic, how they react, whether they’re looking for someone to join for dinner at a conference.

14. “Twitter: For friends or colleagues”

    We also briefly discussed the use of different accounts for different purposes or groups of people: friends, colleagues, profession, (programming) languages… Depending on the number of tweets about a certain topic it can be worthwhile to create an account for it: This way you can filter out (or focus on) this particular topic.

15. “Entaggle”

    This last but not least entry is about the “other social networks” part of the sessions title. Entaggle was created by Elizabeth Hendrickson after a discussion about the value and sense (or lack thereof) of certificates for developers in general and testers in particular. On Entaggle you’d create a profile, be tagged and tag others using tags you (or others) create. That way a network of trust/respect is created.

    The reasoning behind this: People seem to trust the opinion of a real (and probably well-known) person more than an anonymous certification handed out by some institution or company. Opinions of real people matter, especially if you can get in touch with these people and ask for more information (or reasons for a tag they used).

If you’re using Twitter in yet another way, I’d like to hear about it.

At the Agile Testing Days: Alternatives to Certifications, Part 2

In At the Agile Testing Days: Alternatives to Certifications I explained my view on some of the possibilities that were discussed at in a session of the “Open Space” at the Agile Testing Days. (Also see Elisabeth Hendrickson’s summary of this session).
This time I’ll list and comment the other mentioned ideas.

One of the question we’re dealing with is still: What are ways to demonstrate your testing knowledge other than certificates? As in the previous post I’ll discuss suggestions made in this session.

“Create a Portfolio of Work”

The idea is to demonstrate you care about your craft and demonstrate your work. However you’re likely limited in what you are allowed to report: As far as defect reports are concerned many companies will not allow to publish lists of defects you found.
To work around this, how about Participation in open source projects as mentioned in the previous post? This information can be shared.

Stack Overflow

Stack Overflow is “a collaboratively edited question and answer site for programmers – regardless of platform or language. It’s 100% free, no registration required.”¹. Read the About on the site.

Like participating in Open Source projects, Stack Overflow allows you to demonstrate problem solving (and finding) skills. A drawback I see, is the level of detail in the questions as well as the answers. Even though users rate each other, thus creating some level of reputation, it can be too hard to understand for non-technical people as hiring managers and project agents.

BBST Course through AST

Black Box Software Testing (BBST) is a four weeks (approx. 12 hours per week) course offered by the Association for Software Testing.
Compared to the 4 days for the training and exam of the ISTQB foundation, the course offers a greater technical depth and more practical work.

We Vouch For

We vouch for is expired at the time of this writing, see this tweet by Brian Marick. It was meant to, well, vouch for others. In case you like to resurrect it, here’s “Brian Marick’s “:http://twitter.com/marick tweet about where to find the source code.

Social Networks like Linked In, Xing

These social networks which are targeted at business anyway can help finding a new contract or job. Both of them allow users to accept (or ignore) requests to connect to another user, creating (sub) networks of users who trust each other².

Other ideas mentioned

“Degrees” were also mentioned in this session. Since I don’t know whether this is about a specific (university) degree in testing or testing as a main sub topic in, say, computer science or software engineering, so I can’t elaborate about this.

The “Miagi-Do School of Testing” was also mentioned and Markus Gärtner (@mgaertne on Twitter) referred to it in his presentation at the Agile Testing Days. Since there’s no “official web site” for Miagi-Do, finding the place is part of the challenge³.

“Create Open Source Online Courses for ISTQB” ins’t actually suggesting an alternative to the ISTQB certification — however, it was mentioned in the brainstorming. Providing open source (or creative commons) material and courses requires some funding, though.

“Testipedia” was another topic noted on the stickies, yet little is easily found on the web (apart from, well testipedia, but that probably wasn’t the subject).

¹ Citing stackoverflow.com

² …enough to link their profiles to each other. Whether or not this measures a level of trust reasonably or even indicates the experience or knowledge in a certain field is another question.

³ according to a black-belt Miagi-Do tester.

At the Agile Testing Days: Alternatives to Certifications

A session of the Open Space Day (facilitated by Brett L. Schuchert) at the Agile Testing Days dealt with alternatives to certifications. Elisabeth Hendrickson tweeted a link to the summary of this session already.

Here’s a short summary of my favourite parts. In order to stay in sync. with the printed & online conference program I’ll start counting the conference days at 0.

Day 0 – Tutorial “Software Testing Reloaded” with Matt Heusser & Pete Walen

Just as the full title “Software Testing Reloaded – So you wanna actually DO something? We’ve got just the workshop for you. Now with even less PowerPoint!” promised, there was only very little PowerPoint and a whole lot of testing & questioning.

I especially liked the way Pete & Matt presented the examples & exercises as well as the reasoning behind them.

Electronic Dice

There were a lot of games and actual testing. All was very hands on, well explained and debriefed at the end. To give just one example: We tested electronic dice, in order to give an estimation about how long testing would take and to come up with a recommendation whether these dice were ready to be used.

Questions like “Can we ship it now?”, “Is there a pattern/problem there?” and “What actually are the requirements?” were covered.

I also won a price, so my point of view might be biased.

How to Reduce the Cost of Software Testing

Day 1

• Get them in(volved) by Arie van Bennekum
  I found it super interesting to listen to one of the creators of the Agile Manifesto, especially since he pointed out that many of the principles and values have been around before the manifesto was written.
• Myths About Agile Testing, De-Bunked by Janet Gregory & Lisa Crispin
  Lisa & Janet debunked myths as ‘Testing is dead’, ‘Testers must be able to code’ and ‘Agile = Faster’. Excellent story and fun presentation.
• Consensus Talks – 7 10-minute-talks (including mine)
  The format of 10-minute talks, all back-to-back and no break included was the one I missed in the previous Agile Testing Days. This way a whole lot of ground is covered in a short time and it’s a great opportunity to explore new techniques in presenting without doing too much harm and/or presenting on conferences for the first time.
• Self Coaching by Lasse Koskela
  Lasse explained how to coach yourself. After explaining how the human brain works he talked about how to step ‘out of the box’ (your personal point of view) in order to better understand what others actually say and to stay honest to yourself at the same time. Deep knowledge, very well explained indeed.
• The MIATPP Award Night 2012
  Lisa Crispin won the MIATPP Award. Congratulations!

Day 2

• Test Lab by James Lyndsay & Bart Knaack
  This year I went to the “Test Lab” and tested a small LEGO Mindstorm robot, that could move around on a coloured sheet of paper and react, depending which colour its camera would detect. The task: Find out what the specification of the robot is and find defects in its implementation.
  Very interesting: We had to come up with a hypothesis of how the robot was supposed to work as well as finding defects. I really enjoyed the way Bart & James gave feedback and asked the right questions.
• “Reinventing software quality” – Gojko Adzic
  

  Breaking News: Unicorns Exist

  Gojko made the point that in agile testing we might (still) not focus on the right thing: To build the right software. Instead we concentrate on finding bugs and building the software in the right way. He illustrated this with one of his books:  He found a defect and then spent a while searching & listing more problems and ended up with a good number of them, definitely enough to make you worry about the quality of the book. However, the publisher explained that essentially all reviews were very positive! So: When people keep paying for your product or service, worrying about defects may not be that important.

Day 3

• “Fast Feedback Teams” – Ola Ellnestam
  explained the importance and value of fast feedback. And he’s right: In many projects feedback could be gathered a lot earlier and be used to improve what features are built (as well as how they’re built). Other talks at least touched this topic as well. And while I wholeheartedly agree about this, I’m also a bit worried that we (as software creators) might forget about (or even ignore) slow changing aspects (for more about this see my previous post ‘Slow Feedback Cycles‘).
• “Exceptions, Assumptions and Ambiguity: Finding the truth behind the Story” by David Evans
  

  UK Explained

  David explained how natural language is ambiguous, unclear and sometimes hard to understand. His examples included part of Jabberwocky (in several natural languages), music lyrics and last but not least programming. Also, I like his short introduction of the Cotswolds.

• “It’s the Economy, Stupid! Learn the fundamentals about the one and only argument which will drag your management into agile practices” by Lucius Bobikiewicz
  Lucius talked about economic reasons of letting teams focus on 1 (one!) project/product, as opposed to working on multiple projects/products at the same time. It didn’t surprise me much, that letting teams finish one thing and then progress with the next is economically favourable. But  I was very surprised how much of a difference it made in the example he presented. These are the main advantages of the 1-project-only team Lucius presented:
  1. The time between the 1st project start and the first paid project (usually at the end of the project) is much smaller, meaning that significantly less money is needed to fund the upfront costs.
  2. Given the limited period of time in which a software can be sold, the product can likely be launched at the optimal time, whereas multi-product-teams may enter the market later and therefore always lag in selling.
  3. Since the overhead of context switching is minimised, the team can work on more projects/products per time unit. This advantage depends on the amount of time needed per context switch and the time the projects take .

  The economic point of view Lucius presented was a surprising and welcome detour form the other sessions which were much more focused about technology and/or ‘doing the right thing and doing it right’.

Every morning of the conference days 1-3 Lisa Crispin organised a Lean Coffee in one of the hotel bars. In small groups we discussed topics people were interested in. In order to cover some topics we limited the time for each topic to an initial 8 minutes and then added another 4 minutes depending on a quick vote. I find this is a very fun way to find and discuss topics. Thank you Lisa for organising them!

As a leaving thought: The chair persons were given (foldable) chairs as a present — ‘chairs for the chairs’. Super funny, if a tad bit unpractical to get home via train or airplane.

A big “Thank you!” to José, Uwe and Madelaine as well as the other organisers that made the Agile Testing Days such a great and enjoyable conference.