Skip to main content
 
in
  • The Wellington City Council (WCC) wanted to deliver quality outcomes without breaking the bank. Find out how Planit’s fast and flexible resources helped WCC achieve this goal.

this is a test Who We Are Landing Page

Amplify
DoT
 
       

INSIGHTS / Articles

The Motivation to Test

 5 Nov 2018 
INSIGHTS / Articles

The Motivation to Test

 5 Nov 2018 

Amongst the myriad of technologies we interact with on a daily basis, there is always a person or team at the core of the process ensuring each interaction is fit for purpose via test. What inspires the motivation of engineers to do so effectively? And how do we tap into this motivation to ensure we are always seeking continuous improvement?

To understand our motivational challenge, first it is useful to consider some social science theory.

Most management courses wheel out Maslow’s Hierarchy of Needs as a first port of call on the subject of motivation and it has certainly stood the test of time. Maslow suggests that we need to start with resolving our Basic Needs before we can build our Psychological & Self-fulfillment Needs on top. In other words, we need to sort out the basics in our life before we can be expected to be able to achieve higher aims.

Figure 1: Maslow's Hierarchy of Needs

Figure 1: Maslow's Hierarchy of Needs

There are plenty of critics for Maslow’s hypothesis, but this is largely due to the difficulty in getting any two people to agree on motivational theory and further to that, social sciences are impossible to prove definitively. All of which is completely understandable given the variables in all of our lives from personal to professional successes and difficulties.

Much of the issue taken with Maslow is the lack of complexity alongside the absence of social interaction and collaboration which, when considered in our current age of social media and collaboration tools such as Slack, means we need to dig a little deeper.

Although he didn’t acknowledge it at the time, American psychologist Frederick Herzberg hit the jackpot way back in 1964 for our peek at motivation by basing his two-factor theory (sometimes known as Motivation-Hygiene Theory) research towards engineers. Whilst this is often cited as a criticism of the theory, and we should be conscious of potential confirmation-bias, it applies effectively in our industry.

Herzberg argued that not only did employees require direct Motivators (e.g. recognition, responsibility, personal growth) to be satisfied, but further that Hygiene factors (e.g. salary, working conditions, co-worker relations) are implicitly likely only to demotivate, i.e. your salary, amongst other things, is not likely to provide motivation, but is implicit in demotivating you should you deem it insufficient.

Figure 2: Herzberg's Two-Factor Theory

Figure 2: Herzberg's Two-Factor Theory

That last point is understandably contentious and doesn’t fit all job roles. If, for example, you are a salesperson whose salary is part-derived from commission, clearly Pay is going to be a factor in your implicit motivation. However, as eluded to earlier, for our purposes the basis of Herzberg’s research fits quite nicely. It is also absurd to assume people in engineering roles don’t need to be adequately compensated for their highly skilled input, but it certainly isn’t the be all and end all of what makes us tick.

Towards the ticking sound

Anyone who has been around an engineering project that has gone well (and possibly even on time!) will attest to the positive feel-good environment and the immediate uplift in further efforts required from the team for the next phase. The trend towards Agile and DevOps practises leverages heavily on the proposals of Herzberg by encouraging self-organising teams that are accountable within themselves above all else, and Herzberg got there many years earlier.

Experience also shows us that teams which get their cohesion and interoperability right outperform other teams. Experiments of splitting a working team to try and create multiple effective teams often fail, all supporting the two-factor approach.

In the above, we’ve started to answer our first question, that of what can inspire our teams to achieve their best. Moving away from autocratic management, in particular micro-management, is a great starting point.

Whilst great employees are always looking to self-improve, management have a huge role to play in allowing the best built-in traits of teams to flourish; leadership is largely about assisting everyone to be a little bit better. At the core of successful testing are great engineers with a focus on quality.

Whether that engineer is a developer looking at his own code, a specialist test engineer or a team running true in a truly DevOps continuous release cycle, that motivation to provide the best and be accountable (and duly rewarded) is key. Agile, with its end-of-sprint celebrations and demonstrations, allow a great opportunity to see this in action. Often the most conservative team member can be seen to come out of their shell simply based on the appreciation of their peers.

Testers are often considered to take delight in finding a show-stopping defect, even though the potential fallout could result in a delay to the project. This is conjecture however, especially when seen through the eyes of Herzberg again. Rather it is simply pride in doing a job well, and if our hypothesis is to be believed, the great defect provides an amazing source of motivation to keep doing their role effectively.

Again, building a team with a basis of cohesion and trust will mitigate any fallout, since there will be appreciation that everyone in the team needs to be in this together. Those in a position of managing teams therefore need to promote such a culture at all times. Further, in counterpoint, testers need to be considerate to developers when raising and championing defects. Developers are similarly proud and motivated of their work, and testing their efforts can be considered destructive if an honest and open environment is not maintained.

The lines blur even further as development practises evolve. For example, the creation of the SDET (Software Development Engineer in Test) role in recent years shows the blurring of lines between the two activities alongside the desire for progressive automation in development projects. These roles alter the perception and motivations from both sides of the development realm, and alongside the huge potential for either testers with development skills or developers with testing skills, those entering the space require a new challenge to be relevant.

Maintaining relevance

We now move towards the motivation to continually improve ourselves and our processes, not only for personal development, but also to maintain relevance in the business sense. We’ve all heard and probably used some valid reasons, from being tired after work to family commitments and everything in-between.

A work-life balance is essential and modern working practises largely support the endeavour, but we cannot discount that sometimes we all just need to put in some of our own time to keep developing. However, there is definitely space to approach this delicate task within our teams. To not do so would only leave us at risk of becoming irrelevant and send us further down a spiral of motivational loss.

Thus, teams can promote building activities within their structures. Simply having a team which considers all members to be of value will help. In this way the individual strengths of people can be used whilst allowing them to develop skills not yet obtained in a collaborative and conducive environment.

For example, a tester who has some intermediate scripting ability can attempt to transfer that knowledge into another coding language and fix minor bugs, or conversely a developer creating unit tests within their code can peer-review his approach with a tester to ensure a robust approach is taken. Although these seem obvious, experience shows it seldom happens, sometimes due to a lack of willingness from parts of the team or quite simply time constraints.

However, the bigger picture of the effectiveness of the team in the future should be carefully considered against a moveable milestone in the near-term. Occasionally there is even the option of Innovation Days which require the business to carve out some time to ensure their teams are always looking to improve and learn skills.

Even events such as Hackathons, in which people are asked to give up some of their own time and work in a very progressive and free environment towards a common, ambitious goal in a short timeframe, offer a window into allowing a positive frame in which to realise genuine motivation. Teams able to find participants for this type of events inevitably are teams which succeed often.

Summarily…

…there is no magic bullet to motivation, and as discussed, there is great difficulty in gaining consensus given the variabilities in human nature. However, if we are considerate to the findings of others and approach our roles with the right levels of compassion, understanding, rigor and firmness, we are more likely to keep our teams motivated and delivering towards our needs.

In that way Maslow, even with all his critics, was on the money with Self-Actualisation being within reach on top of the pile. Here at Planit, we strive towards all these elements in our activities, be it our training or our consulting services, our thought-leadership incorporates and considers the multi-dimensional approach required for success.

Deliver Quality Quicker

At Planit, we give our clients a competitive edge by providing them with the right advice, expert skills, and technical solutions they need to assure success for their key projects. As your independent quality partner, you gain a fresh set of eyes, an honest account of your systems and processes, and expert solutions and recommendations for your challenges.
 
Find out how we can help you get the most out of your digital platforms and core business systems to deliver quality quicker.

 

Find out more

Get updates

Get the latest articles, reports, and job alerts.