Six tips to get your software developers testing

The inspiration behind this article comes after reading a book recommended to me called Bringing Out the Best in People: How to Apply the Astonishing Power of Positive Reinforcement. The author encourages managers to use systematic, scientifically based management methods to bring out the best in people at work. This body of knowledge is called behaviour analysis; and the application of these scientific findings to the workplace are called performance management and precision management.

The first part of this article is to use behaviour analysis to help pinpoint why developers do not test (or, if you like, do not test well). The second part of this article is to recommend some ways that you can get better results out of your testing given your new knowledge on the behaviour of testing.

Behaviour analysis

For those new to this scientific field, the first concept to understand is the relationship between the antecedent, behaviour, and consequence. An antecedent precedes an event and sets the stage. The behaviour is what you want to manage (in our case, testing). And finally, the consequence, which is what happens after the behaviour.

Some basic examples are; you feel hungry, you eat lunch, you are no longer hungry. The car is overdue for a service, you get it serviced, you are no longer worried it’s overdue. Email arrives in your inbox, you read it, it gets thrown in junk as spam.

I think you get the idea. The next concept to understand is a PIC/NIC analysis, and this is where it starts to get fascinating. The PIC/NIC analysis is a simple method for systematically analysing the antecedents and consequences influencing a behaviour. But first, we need to cover off some terms used to classify consequences:

• Positive or negative. This dimension answers the question, “is the performer likely to experience the consequence as positive or negative?”
• Immediate or future. Here we want to know, “does the consequence occur as the behaviour is happening, immediately thereafter, or after some time has passed in the future?”
• Certain or uncertain. This dimension expresses the probability that the performer will actually experience the consequence.

When you classify any consequence, it will have a three letter combination. For example, a PIC (positive-immediate-certain) is a combination that says this consequence will result in something good right now. Opposed to a NFU (negative-future-uncertain) that says something bad might happen…maybe.

Before we do a PIC/NIC analysis for testing, let’s start with an easier one that we all understand. This is the beginner example that is used in the book.

Problem behaviour: not buckling up a seat belt

Many people do not put a seat belt on, why? Well, let’s ask ourselves the question, these are the antecedents:

• think they don’t work;
• can’t reach easily;
• just going on a short trip; or
• they are in a hurry.

You could probably list some more antecedents, but this is a solid list. The next step is to list the consequences of not wearing a seat belt:

Given there are some pretty severe negative consequences for not wearing a seat belt, those consequences tend to be future and uncertain. On the other hand, the positive consequences tend to be immediate and certain. Interesting …

Desired behaviour: buckling up a seat belt

Many people actually wear a seat belt, why? Again, let’s start with the antecedents:

• someone asked you to put it on;
• saw an accident;
• got a ticket;
• saw a police officer; or
• generally doing the right thing.

These are all reasons why you might put on a seat belt. So what are the consequences for doing this:

Again, this is a pretty solid list (maybe you could add some more), but what is interesting is that the positive consequences tend to be future and uncertain. The negative consequences are immediate and certain.

And the main point is:

This analysis points out the difficulty in changing any behaviour. The present behaviour or habit (usually what you don’t want) is receiving positive, immediate, and certain consequences (PICs), and the desired behaviour gets negative, immediate, and certain consequences (NICs). So what we want this performer to do (wear a seat belt when riding in a car) is associated with immediate punishment and the possibility of future benefits. What we don’t want this performer to do (ride in a car without wearing a seat belt) is associated with immediate positive reinforcement and the uncertain possibility of some future, possibly serious injury. [1]

Problem behaviour: software developers not testing

Now that you have gone through a PIC/NIC analysis for something familiar like not wearing a seat belt, it’s time to look at another problem behaviour, why don’t software developers test? Let’s start with the antecedents:

• peers do it that way;
• no feedback on coverage;
• performance appraisal does not address testing
• squad has emphasis on burn down charts; or
• got in trouble for not delivering on time.

Can you think of any other antecedents? Keep these in the back of your mind because to create lasting change, it is the pairing of antecedents and consequences, but we will discuss this more later. Next, what are the consequences of not testing:

As predicted, PIC’s are associated with the problem behaviour and the negative consequences for the developer are most likely in the future and uncertain.

Desired behaviour: software developers testing

There are developers in the world that do test! What are the antecedents to this behaviour (that we so very much want):

• testing boards with green or red;
• leads said “be careful”;
• performance appraisal has quality as a category;
• got into trouble for producing low quality last month;
• received training; or
• peer code review.

Yes, this is a good list, and we will expand on them in the next section, but before we get into some handy tips for pinpointing, let’s round this out with the consequences of testing:

Given this list of consequences, our desired behaviour is dominated by NIC’s and clearly highlights that negative reinforces tend to be immediate and certain. And our desired consequences, that are positive, tend to be future and uncertain.

This is what a PIC/NIC analysis is about. It highlights to us that a problem behaviour is receiving positive, immediate, and certain consequences (PIC’s). And our desired behaviour is receiving negative, immediate, and certain consequences (NIC’s).

6 tips to get your software developers testing

Now you are equipped with this new knowledge and an understanding of a PIC/NIC analysis, it is time to make some changes to improve your developer’s testing. The process of pinpointing (and making improvements) is about specifying results and behaviours. Pinpointing means being specific about a result you want, and then being very specific about the behaviours required to achieve that result.

1. Immediate feedback using CI/CD

Continuous Integration / Continuous Delivery (CI/CD) is good practice you can lean on. Basically, each time a developer commits code (or at some interval), the CI/CD can run to ensure that tests are passing. It is also possible to add other tools into the pipeline. For example, in a GitLab pipeline, you can add extra tools like code coverage, performance checking, and code standards so that things are checked immediately and for certain. To go that one step further, consider ways that the individual gets some positive feedback … like a Slack message saying good job! Or, use a visual graph to show how well the individual or team is doing.

2. Using checklists and a definition of done

As part of your way of working, being it Agile, Kanban, DevOps, or some beautiful hybrid methodology, you should be using checklists. A checklist is basically like a shopping list. At each point in your way of working where you want things to be done, put a checklist. In the Agile world, these are called definitions of done. For those readers interested in this topic, take a look at this article I wrote on what is the difference between scrum and kanban. Another way to think of a checklist is like a gate, all the acceptance criteria must be met (like testing and documentation) before developers are allowed to proceed. Like tip #1 above, this will make testing immediate and certain. Then it is up to you to make it a PIC.

3. Include testing in your estimations

The oldest excuse in the book for not testing is that there simply was not enough time. So, how do we create time? Or at least make developers feel that there is enough time available? One possible answer is to include testing in your estimations. There are many ways to estimate software, one approach is to use allocation factors where you can put a certain percentage of time aside, for example, a testing allocation. Do your developers currently include testing in their estimations? I would ask them if I was you. This could remove some NICs that are plaguing your problem behaviour.

4. Grandma’s Law

In Chapter 7, of Bringing Out the Best in People, there were a lot of interesting points made around capturing the discretionary effort of people. One that I found fascinating was Grandma’s Law.

Psychologist David Premack discovered in his research that when people are given a choice of things to do, whatever they consistently choose can be used as a reinforcer for the behaviors not chosen. His discovery is called the Premack principle. This has been more simply translated by Dr. Ogden Lindsley, who called it “Grandma’s Law.” Grandma’s Law states, “if you eat your vegetables, you can have dessert.” Eating vegetables is a low-frequency choice for most children. Eating dessert is a high-frequency choice. When the high-frequency choice is made contingent on the low-frequency choice, children not only eat more vegetables, but they may learn over time to like them. [1]

So, if developing is a high frequency choice and testing is a low frequency choice, does that mean we should bring back Test-Driven Development (TDD)? Maybe there is another angle that could be taken here to create a desired result. Hmmm … bring back the old school 🤔

5. Have a codebot write tests

There is no doubt that testing takes significant time. There is also little doubt that it is a relatively boring job to do. So why can’t we automate it? The answer is that we can. A codebot can write both the development target and the testing target. This has a number of positive effects. Firstly, it frees up the developer from these tasks and gets them onto other, more complex development. Secondly, the codebot written tests ensure that developers don’t accidentally break their code. In a way, the codebot is used as TDD to make sure its code is working and is ready for a CI/CD pipeline.

6. Celebrate the wins

The last tip is an important one, make it positive and celebrate the wins! The power of positive reinforcement is huge and can change the results of a project. So, do what humans like to do, celebrate the win. The trick with this step is finding out how people like to do this. Some people are private and do not like public attention, while others like to be called out in the morning stand-up. Get to know your team and put some positive energy out there! 😎

Summary

Software testing is one of the most important parts of building great software. Yet, all too often developers seem to forget this when working on an application, but if we asked them how important is testing? They would answer very important. There has to be some psychological reason for this.

When we apply a PIC/NIC analysis on software testing we can see that it reveals some answers and when you stop and think about it, it does make sense. So, what we can do is use this to pinpoint behaviours and use results to shape a better outcome. That is pretty cool because you can do this for any problem behaviour. Can you think of another?

I encourage you to read the book, as there is a lot more included than what was discussed here. I have given 6 tips to help get your software developers testing. Drop us a line if you would like to include any more.

[1] Daniels, Aubrey C.; Daniels, Aubrey C.. Bringing Out the Best in People: How to Apply the Astonishing Power of Positive Reinforcement, Third Edition (p. 45). McGraw-Hill Education. Kindle Edition.

Written by Eban Escott

Founder of Codebots

Dr Eban Escott received his Doctorate from UQ (2013) in Model-Driven Engineering and his Masters from QUT (2004) in Artificial Intelligence. He is an advocate of using models as first class artefacts in software engineering and creating not just technologies, but methodologies that enhance the quality of life for software engineers.