The Sergeants of Software Development

It’s 2017, and guess what?  It seems we’re still trying to discover our identity. Still asking questions about what it means to be a tester.

It’s perhaps worth offering one possible analogy that I’ve given to my testers once or twice that, while it doesn’t match perfectly in all respects, does resonate for me.

That is, if we were to imagine a software development organisation as a military unit, testers are the sergeants. Before I break down why I think it’s a useful parallel, I’ll provide a brief explanation of what a sergeant is, and does (which, being the military, is pretty well defined).

“Sergeants typically are second in command of a troop or platoon of up to 35 soldiers, with the important responsibility for advising and assisting junior officers.

After a few years as a Sergeant promotion to either Staff or Colour Sergeant may follow. This is a senior role combining man and resource management of around 120 soldiers, or even command of a troop or platoon.” – Ranks, British Army

To give some flavour for the worth the military places on its sergeants, I Googled for some quotes;

“…the backbone of the Army is the Non-commissioned Man!” – Rudyard Kipling, “The ‘Eathen“.

“The sergeant is the Army.” – Dwight D. Eisenhower

“If I had another life, that’s what I’d be – a regimental sergeant major or a similar rank. That’s where the spirit of the armed forces is.” – Bob Ainsworth

“Battles are sometimes won by generals; wars are nearly always won by sergeants and privates.” – F. E. Adcock

“Any officer can get by on his sergeants. To be a sergeant you have to know your stuff. I’d rather be an outstanding sergeant than just another officer.” – Daniel Daly

“Most armies are in fact run by their sergeants – the officers are there just to give things a bit of tone and prevent warfare becoming a mere lower-class brawl.” – Terry Pratchett

Of course it’s easy to find some quotes that fit the bill, and easier still to assert that one’s place in things is to be the glue that holds everything together and makes it work. However, in the interests of helping explain what testing is, I will explain, expand upon, and (probably, and inevitably) ditch the metaphor.

 

Chain of command

Let’s address the place of a sergeant in the chain of command. Granted, a sergeant is subordinate to the greenest first lieutenant fresh from officer training at Sandhurst, West Point, Frunze and the like. During the training, however, the officer cadet will have been under the guidance of several sergeants and sergeant majors, a dynamic that continues when the officer graduates and is given a command. The place of the sergeant is to assist and guide the young officer, using their far superior experience.

In software development teams, in my experience at least, good project managers tend to lean pretty heavily on their test team leads for organisational and management assistance. This is typically due to the type of knowledge that the tester typically has at their command, which I’ll go into below.

When I raised this analogy on twitter, someone said “I’m not a particularly good order-taker”.  As testers are an extension of the senses of our local stakeholders, it is natural that our relationships with them are more symbiotic than rigidly hierarchical. As I imagine is the case in any structured environment, high effectiveness stems more from mutual support and respect than from slavish devotion to the chain of command.

Also, much as I imagine a sergeant has scope to bring their experience to bear in their duties, so to does (should!) a tester. The chain of the command should support and encourage, not explicitly direct or restrict. As testers, we have a mission to complete, but we decide which tactics to best employ for the situation.

Systemic knowledge

The basis on which a manager comes to appreciate the support of testers is rooted in the nature of their knowledge.

A developer’s knowledge is typically narrow but very deep. They understand completely how a particular feature is put together, but might not know much about adjacent features, or other areas of the codebase. A tester, on the other hand, has pretty broad knowledge which, while not as in depth as a developers, is still pretty comprehensive, at least from a logical perspective.

This systemic view and understanding which the act of testing gives to the testers makes acting as deputy project manager a relatively small jump for a tester. My test leads have more often than not acted as deputy team leads at one point or another.

Another area of potential cross-over of knowledge is in the area of test strategy / planning. Depending on your organisation, the production of a test plan might be the first time someone asks questions like “What languages are we supporting?” “How many concurrent users are we expecting?” “What are we releasing?”.

You can actually get pretty far through the development lifecycle without ever having to answer these questions. If your focus is to deliver functionality above all things, it might never occur to people to have answers for these questions.

Testers can be the drivers for answers because test planning is the first stage where those questions have to be answered. Opinions are divided about test plans, because “no-one reads them”, and so they are waste. But, to quote Eisenhower again, “Plans are useless, but planning is indispensable” (this quote adorns the front of my test plans to this day). The artefact might be waste, but the process of filling in the blanks most certainly is not, especially if the review involves all the relevant local stakeholders.

Being the agent for filling in these blanks, for asking the broad, important questions upon whose answers can hinge the success of a release, makes the testers valuable support – and impetus for change – to management.

“Yes, Drill Sergeant!”

“But”, I hear you cry, “I’ve seen movies and the sergeant is always a shouty asshole. In Full Metal Jacket the Drill Sergeant gets shot!” True, but the role of Drill Sergeants is different. Their job is about breaking recruits down before building them back, minimising individuality and prioritising uniformity.

In a business environment, while mentoring and training will likely be part of a tester’s role, it shouldn’t involve any breaking down of the mentee. Certainly for a tester, that individuality is what makes them valuable. The ability to apply their individual skills and experience is a big chunk of why they find bugs that others have not.

One who serves

A sergeant is, in most in the armed forces but not all, the senior non-commissioned officer (NCO) rank. The word has its origin is the Latin serviens, “one who serves”, through the French term “sergent”.

There is baggage attached to the word “servant”, little of it positive. But if we check our ego at the door for a second, a servant is one who ensures that the needs of others are met; surely a noble calling. In software development, a current answer to questions about the place of the tester in the team is that we should strive to add value where and how we can. What is that if not to serve? That is literally the embodiment of quality; adding value to those who matter.

Rather than being a mere subordinate, meeting the whims of others, someone who chooses to put the needs of others ahead of their own has all they need to be a good, even great, leader. They need only to decide to lead. Those they have helped will often willingly follow.

The servant-leader is one whose desire to help others drives them to seek leadership positions purely to enhance their breadth and power to help others. This, I imagine, is the pure ideal that drives some politicians to seek high office, only to be brought low by human self-interest, and the corrupting effects of absolute power.

Lest we forget, we serve the needs of our customers by providing tools and services so they can do what they want to do. We should perhaps not be repulsed by the word service. We are not servile. The relationship is not servitude. Helping others, at both the company-customer and team levels, is what we should be about. Let’s embrace that.

The Sergeant

So, if you’re still looking for handle for your tester identity, I think you could do worse than a sergeant. The role is about adding value and supporting others, and creatively determining how to meet your mission directives. It also has the scope to develop as much of leadership aspect as you want.

Writing this has reminded me that, despite many years of trying to figure out what my passion was, I had at one point decided that my career goal was broader and simpler that what I had been looking for; that is: to help others. To seek leadership in order to better serve.  Lead to serve.

Automation will kill coding before it kills testing

I twitch-posted this reply to a Reddit /r/QualityAssurance thread because OP was told that “everyone says” that software testing is “a temporary field”, that “automation is going to kill it in another 3-4 years” and “If you go in this field you will be unemployed after a few years and it would be very difficult for you to switch jobs”.

When “everyone says” something like that about testing, I get defensive, I admit. Maybe it’s because that, even after all this time, “everyone” still seems to know more than me. So, let’s actually see whether I can back up my quickfire reply with some cogent argument.

Firstly, I’m not worried about the “everyone says…” part. We should know by now that “everyone says” is a fallacy. Argumnetum ad populum; lots of people think it, ergo it is true. Use of this term, and others like it, should immediately set off the bullshit detectors of anyone who spends any time whatsoever reading stuff on the internet.

Now to “Automation is going to kill it in another 3-4 years”, firstly to the 3-4 year time frame. Four years is not that far away. How many of you in software development land have heard even inklings of using machine learning or AI anywhere near what you do on a daily basis? I’m willing to bet much of your time is still spent grumbling about how you’re mis-using Jira, or abusing Gerrit, or any number of other procedural wastefulness.

That’s what most modern software development is; smart people trying to do something useful while wading through procedural waste. We spend so much time looking to see where we’re putting our feet, we have very little time left to look at the killer robots on the horizon.

To the second part; automation is going to kill testing. Within a couple of generations, automation is going to impact pretty much everyone’s jobs, perhaps even render working itself obsolete (if we’re really lucky). I agree that the machines are out there; they are coming to take our jobs, but I think it’s more like 5-10, probably even 15 years before it makes much of an impact.

Before I get onto which will die first, coding or testing, let’s just quickly deal with the final point; “If you go in this field you will be unemployed after a few years and it would be very difficult for you to switch jobs.

“Unemployed after a few years”? I don’t think so. Sure, some companies have dispensed with their dedicated testing departments in the belief that, with DevOps, they can respond rapidly to customer issues and deploy fixes. I can see how that approach can work for certain business models, but certainly not for all. Would British Airways want to have to phone Rolls-Royce during a London – New York flight to push a fix because the engines timeout after 20 minutes? Probably not.

Even if the nature of software development has changed, there will still be roles for humans until the point at which AI can do everything. Arguably, testers are better positioned to move into different roles than anyone. We have good broad technical and business knowledge of the products and the users. We have good communications and analytical skills. You can’t tell me I can’t find a job with that bag full of reusable skills.

Now to the main point. Will automation kill coding before it kills testing? Firstly, I’m of the opinion that it will kill them both, and every other human endeavour, at some point. In a previous post, I posited that eventually AIs will develop to the point that humans will not have to work, and that all our needs will be met by automated systems. That development will not, of course, be without its challenges, but that is the general direction in which I believe we are headed.

But who dies first? I’m a tester, and not one who is a “failed developer” or who did any sort of computer-related degree (if I’m a failed anything, it’s a failed rocket scientist), so you can give my opinion as much credence as you like.

What I see in modern software development feels like plumbing. I apologise slightly for the inference; testers are often thought of as manual unskilled workers, and I don’t really want to disparage developers in the same way. Or plumbers for that matter.

Never the less, many applications consist of web applications built using one JavaScript library or another built on top of a web of APIs, some built by the team but more often not, all sitting on top of a stack of Iaas / SaaS, virtualised environments provided by someone else, all supported by 3rd party libraries.

The work – and, yes, the skill – is in sticking all these things together into a functional whole. Sure, there are bespoke elements here and there to stick together two components never previously stuck together, but it all still feels a bit…Lego.

If you were to supply a shelf full of documented, reusable components to an AI and ask it to make you an application….well, that doesn’t seem like too much to ask. Does the fact that the system is being made by machines mean that there are no bugs? Will AI make mistakes? Will it notice if it does? Or will all this happen and be rectified so quickly that it effectively never happened at all?

I think production errors – bugs, build problems, deployment mis-configurations – will become a thing of the past, or will be rectified so quickly we won’t even notice. “Did we build the thing right?” will no longer be a question worth asking.

“Did we build the right thing?” will become the only game in town. While humans remain a stakeholder in the production of software, even if only as an end-user, giving the machines feedback on whether they built the right thing will always be a thing (at least as long as there are humans…dun dun dun!)

Testers, with their broad, systemic, technical, and business knowledge, allied to their ability to communicate in both technical and business terms, are ideally placed to act – as we already do – as a bridge between the human and machine worlds, to continue to help translate the needs of one into the language of the other.

As AI advances, and the dynamic – the balance of power, perhaps?  -between the two worlds changes, someone will need to be there to translate. Who better than us?