Thursday 21 March 2013

The self actualisation of testing

Testing is boring. That is a view held by many folks. It is a repetetive, mindless activity of following a series of highly scripted instructions. And yet a lot of people love it, and devote whole careers and huge chunks of their personal time discussing, promoting and generally enjoying being involved in it, myself included. How is it that bright individuals can find such a level of interest in a subject which to most other people outside of the profession consider to be dull beyond belief and not worthy of wasting their considerable talents on? Many testers reading this may be thinking that this is an old argument - the testing world has moved on to the extent that even banks are adopting Context Driven Testing. I'm in the happy position to be able to agree that things have moved on (thousands aren't), but I personally find it interesting to look at how things are changing and, more importantly, why?

I believe that they key to that conundrum becomes apparent when we start to examine the principles and studies of that most interesting subject of psychological and management science - motivation. Looking at the subject of software testing from the perspective of motivational theory then I find that it not only highlights why certain individuals are drawn to testing as a field of expertise, but also why the adoption of certain approaches to development and testing help to attract great people into testing roles.

Principles of Motivation

Before looking specifically at testing, it is worth presenting a brief potted history of some management and motivational ideas which I'm going to refer to later.

Scientific Management - In the 1900s a bloke called Frederick Winslow Taylor developed theories of management which were to become the 'Scientific Management' approach. Taylors theories focussed around taking knowledge out of workers and into centralised documentation and tightly controlled processes. Taylor believed that it was possible to define 'industry best practices' around the tasks performed by most workers and, by getting all workers to follow these, a more efficient process would result. Whilst subsequently criticised, Taylors theories now form the foundation for certain management schools, many of which have their roots in manufacturing, such as Lean, Total Quality Management and Six Sigma.

Maslow - Most folks who have studied psychology or humanities subjects will be familiar with Abraham Maslow and his motivational pyramid - the "Hierarchy of Needs". The hierarchy of needs is a model of humanistic psychology based on the principle that humans are conscious decision making individuals who will work towards self fulfilment if no other obstacles are present. The model outlines 5 layers in which various levels of motivation form a hierarchical pyramid from the the most fundamental "Physiological" needs such as food, drink and air at the bottom progressing up through "safety" factors via emotional fulfilment and "love" to the more rich motivational targets of "esteem" and the pinnacle of "self actualisation".

Maslow's humanistic school of psychology worked on the principle that humans are driven toward self actualisation, but obstacles at the lower levels of the pyramid will take priority. The hierarchy is based on the individual as a whole and so applies to all levels of life. Many folks working in the field of IT will be in the very fortunate position that the relevance of Maslow's hierarchy in their working context is really limited the top two tiers of the pyramid, esteem and self-actualisation. Given a stable environment and having met the more fundamental needs of the lower levels of the motivational pyramid, individuals will naturally be inclined towards lifestyle and work, where they are able to feel a sense of self esteem and personal achievement.

Herzberg - More specific to the field of motivation in the workplace are the theories of Frederick Herzberg. Based on studies of individuals in industry Herzberg concluded in the 1950's that the factors that acted as motivators for individuals to work to their best potential in the workplace were actually different to the factors which caused them to register high levels of dissatisfaction. Most of the reported reasons for dissatisfaction in Herzberg studies came about due to the absence of what Herzberg called 'Hygeine factors' which were not related specifically to the work itself, such as a safe and comfortable environment, company policies, supervision structures and relationships with peers. Salary also comes under this category. The greatest motivators that caused individuals to gain satisfaction from their work were fundamentally different and based more around the intrinsic elements of the work itself such as the nature of the work, the possiblity for personal development and the levels of autonomy enjoyed.

Principles applied

It is interesting to consider the application of the very different ideas on motivation to the field of software testing. One approach to the management of testing is to consider the activities of testers very much the same way as the activities one might see on a production line. Software is deliverered, tests must be prepared and executed, results recorded and bugs raised. The operation of testing can be broken down into the manipulation and processing of a predictable set of artifacts and actions. One could take the view that all of this activity is essentially predetermined, and many do, to the extent of predicting the number of bugs that will be raised by a phase of testing and monitoring of the variance of bug counts around this target as a measure of progress. If taking this view of the testing process then a scientific management based approach, or a derivative thereof, to the execution of the process is a relevant approach. The result is likely to be a focus on efficiency of throughput of the artifacts of testing and the adherence of the testing operation to the processing of these artifacts with a high level of monitoring in place, which is what we've seen in many organisations. This is not to say that this approach is wrong, it is simply the result of taking a certain view of the development process and adopting a management style to match, I would refer to this idea as inappropriate rather than incorrect.

When considering testing instead in the context of Herzberg's findings on motivational factors, one could argue that the role of scripted test execution is missing any of the significant motivational factors that Herzberg identified. Whilst it is possible to supply sufficient hygeine factors to avoid high levels of dissatisfaction - good pay, nice environment and clear supervisory structures, such a role lacks any level of autonomy or empowerment and the nature of the work can be mundane and without cognitive challenge. In terms of scope for improvement then building in a hierarchy of supervision will clearly allow for some possibility of promotion, however the motivation for self improvement here is not towards the improvement of testing ability itself but towards supervision, or sometimes test automation and the development of programming skills that is inherent in that activity.

So how does testing engage and motivate the smart folks that write the articles I read, present at the conferences I attend and generally make testing a good place to be? My feeling is that that these folks have created a testing role where Herzberg's motivational factors are inherent in their testing activity.

  • Processes of collaborative specification give us environments where testers are included in early requirements analysis and decision making.
  • Acceptance test driven development pushes testers to understand the business users to establish appropriate criteria for new features.
  • Exploratory testing techniques furnish us with roles where testers are responsible for the interactive design, execution and reporting of their own testing activity - every action demands attention as the decision to take that action has been recently made by the person performing the action.

In each case the move has been towards increasing the levels of Herzberg's motivational factors in the testers role. 

One criticism of Herzberg's approach is that motivation does not necessarily lead to greater productivity at work. In a testing context you could argue that motivating people in testing is no guarantee that they are doing it better. I'd counter this by arguing that Herzberg's motivation factors primarily motivate through engagement with the work. Engagement and interest are critical factors in successful testing due to the concentration and awareness required during testing. The absence of these critical factors during testing can lead to mistakes, irrespective of the effectiveness of the defined activity. (As a relevant aside - I recently accidentally gave my daughter, who has a serious milk allergy, cows milk to drink. Surely there can be few greater motivators than the health of your child, yet I still gave her milk. Why? I was preparing drinks as I do every night, day in, day out in the same way. I worked out afterwards that I must have done this two thousand times, plenty enough to no longer be engaged when doing it - now we make it more fun by getting the kids to play a game reminding me to 'check' the milk each night, I'm more engaged with the activity and hopefully less likely to make another mistake).

My other argument would be this. In increasing the motivational factors in testing, we are not only making the job more interesting for those involved in it, but also making testing a more attractive career for people to move into. Attracting higher quality, brighter folks into testing teams will surely result in better testing by those teams. I'm incredibly lucky to have the calibre of people that I have in my team, and am convinced that these folks would not be attracted to the job unless it was interesting. We do it because we like it, and if improving motivation in testing means that we get folks like the ones in the 'blogroll of fame' linked in this site, or the amazing line up of folks speaking at the TestBash this week, then I am all for it.

References

Theories of motivation
Herzberg's Motivator Hygeine Theory
Scientific Management

 

 

 

 

 

 

Phil Kirkham said...

Maybe a bit of confirmation bias - you're mixing with the context testers who's approach resonates with you.

It could well be that the 'factory' testers get very excited and animated ( see Linkedin Discussions ! ) about applying order and making the chaos that is s/w engineering be more systematic and methodical and repeatable. Bringing order to the world is what gives their lives purpose and meaning...

Adam Knight said...

Phil,

Yes there is certainly a risk of confirmation bias whenever I write, in this case, however, I think that I've covered your example in the post. As you say it yourself the motivation here is "about applying order". Given a hierarchical, metric driven process, the motivation is towards achieving controlling and supervisory roles and I'd suggest the folks that you mention on LinkedIn are motivated more by the structures of controlling and monitoring the testing process rather than improving the actual testing itself, as I've suggested above. But then that's probably my confirmation bias talking ;)

Thanks, as always, for reading and commenting.

Adam

Alaric Snell-Pym said...

I'd say that as soon as you start to find testing boring, then it's a sign that you need to step up the level of automation.

Case in point. Sitting entering test cases by hand is fun at first, but soon becomes boring. Especially when you have to redo them after every change to see what the consequences of that change were. And there's scope to accidentally miss one if you do them by hand.

So, we of course write scripted tests. We can run the entire suite with the press of a button. Those repeated runs no longer remain such a burden, and we no longer run the risk of failing to be consistent between runs.

But then writing all those test scripts to try and cover every different interesting case in our software starts to get boring. Especially when you add a new feature that interacts with many other features in the system, so lots of existing test suites need expanding to cover all the new interactions. And we start to run the risk, as more and more features are added, of not being as thorough in handling each of them as we can be; a new kind of inconsistency can creep in, at a higher level of abstraction, along with a more abstracted level of boredom.

So then you switch to using automated state-space exploration tools (such as https://github.com/DRMacIver/hypothesis) where, rather than explicitly listing lots of things to test, we instead describe the interface of our software and then define a model of what outputs we expect from what inputs; the system will then automatically generate test cases covering the range of possible inputs, and check the corresponding outputs (the one I linked to even does some clever magic, when it finds a failing test, to narrow down the simplest case that reproduces failure - something else that can become boring for a tester).

And so now, instead, we spend our time writing computer-readable specifications for our functionality, rather than test cases.

I'm not sure what we do next once THAT becomes boring, as I have yet to reach that stage myself. But there will be something!

There's plenty of work for people who have an interest in testing, but find actually doing it boring, to go out and build more and more abstract test tools. The tool I mentioned above is extending into relatively fresh ground in the field, testing sequences of state-changing operations and trying to find minimal sequences of operations that lead to a failure (see http://www.drmaciver.com/2013/03/stateful-testing-with-hypothesis/) and to find better ways of focussing test cases around "interesting cases" (adding a bit of white-box testing to the otherwise rather black-box-oriented approach of testing from a specification) - see http://www.drmaciver.com/2013/03/another-new-hypothesis-feature-flags/ - plenty to keep you busy! :-)

Whatsapp Button works on Mobile Device only

Start typing and press Enter to search