Why Software Testing is So Important

It isn't about being diligent. It's because we've forgotten what we knew.

Bizarro World Software Development

Anyone reading public discussions about software development might not even know that the main objective is the production of executables. One could be forgiven for having the impression that the sole objective of software development is unit testing.

Articles about coding practices are few and occasional; articles about testing strategies are legion. And they tend to be either strangely exuberant (a happy team sitting in each others’ laps and writing tests) or scolding (anything other than 100% code coverage is slipshod and undisciplined).

It didn’t use to be like this. We used to focus on development, and while we did enough testing of our own work we knew, and knew clearly, that this was just the beginning, that a team of dedicated SDETs would do the real testing, based on a functional specification and unprejudiced by knowledge of the code.

Nomenclature

BlackBox Testing: testing an executable using a functional specification as a guide, without knowledge of the code or the implementation design, based on behaviour and tested in the user interface (EXE) or a test harness (DLL).

WhiteBox Testing: same as BlackBox but with knowledge of the code and thereby prejudiced. Generally done by developers and perfunctory, not recommended for conclusive testing

Unit Testing: testing code functions directly, passing them sample data sets, usually done by the developer and mistakenly regarded as conclusive, often credited with magical powers and regarded by many as defining entry point documentation. See Test-Driven Development

Traditional Testing

Traditional software testing is BlackBox. The developer either writes or is given a functional specification, implements it, tests it enough to know that basic functionality is sound and likely edge cases work, then delivers it to BlackBox testers, one or more, who specialize in testing. In ideal cases, a developer and SDET work closely together and do as much as possible to bypass the bug database and triage tedium.

Admittedly in past times, many companies did not do enough of this. Since my work often went live on servers within hours of bug discovery, it was important to test thoroughly and I spent half my day in my tester’s office sometimes. We worked together well.

But some companies regarded testing as a box to check and nothing more.

Test-Driven Development

Arguing with my manager in 2008 about writing unit tests for my release-ready application, too small to be decomposed into units, the conversation got crazier and crazier and it went into lunacy territory when he mentioned a new thing called “test-driven development.”

The first thing that came into my mind was that despite the most diligent planning anyone has ever done, we learn things during development that we hadn’t anticipated in design, so tests written before this would either be incomplete or require constant revisiting, which is a waste of time compared to writing them after implementation is finished. Not catastrophically so, but backwards.

But TDD has come to dominate the industry despite this, and now testing has replaced development itself as the core of … software development. I’ve already written about this elsewhere and won’t repeat it here:

https://hackernoon.com/software-development-is-not-about-unit-tests-r77132y7

but in discussions in reaction to this and other articles, I’ve learned that things are a lot, lot worse than I thought.

Why Johnny Can’t Code

Long before the personal computer revolution, the few companies developing software had already noticed that some programmers were much more productive than others and produced superior code. It wasn’t any difference in intelligence, it wasn’t faster typing, it wasn’t longer hours. Research showed that the key to this superior performance was the ability to enter periods of prolonged and unbroken concentration, which was called Flow. See the Resources for more on this, or read my other article:

https://medium.com/swlh/the-magnificence-of-flow-c5fad8da35a1

The reason Microsoft was such a great place to work until it grew so much was that this recognition was woven into their corporate culture; we had private offices and minimal interruptions.

It didn’t last. Maximizing shareholder value meant doubling or quadrupling office occupancy, we were called to more and more meetings.

The important point here is that being able to concentrate is essential to doing good work.

Because Johnny Can’t Concentrate

I like working alone. I like closing the door to my unshared office, turning out the lights, putting on the headphones playing brooding ambient music, focusing in and coding for hours. I can do weeks of work and have everything work with few or no bugs when everything is done. I can concentrate.

Concentration has gone out of style in software.

The reason you’re so obsessed with testing is because you can’t concentrate, so you can’t write good code.

You start your day with an utterly pointless daily scrum (a neologism for a status update; we used to do these in email), scheduled for 8:30 or 9 AM, so your day begins after a mind-numbing slog of a rush-hour commute that leaves you weary from the start.

Your day is constantly interrupted by “team” interactions and recurring meetings.

You are told to respond promptly to emails so you leave popups enabled and break from work to respond to them.

You take frequent breaks for “team” events and online gaming.

And worst of all, you’ve never learned to concentrate in the first place. You watch TV and you switch channels every few seconds, you spend hours on social networks where 280 characters strain your attention span, it takes you months to read a novel if you read at all, you play games where response times are instant so you never have to wait for anything longer than microwaving macaroni and even then you dance from foot to foot going “come on, come on.”

You never had a chance, you poor sap. So you write tons of tests.

People Who Concentrate are Toxic

I’ve been told this many times now. Seriously.

On a freelancing agency blog, a manager (who hastened to brag about his hiring authority) told me that he wouldn’t hire someone like me who worked alone because “individualistic” programmers bring toxicity to the “team” and end up demoted and terminated.

On Twitter, a purported developer told me that people who are “obsessed with focus” are mentally unstable and that “people skills” are more important than productivity.

Uh, yeah.

There is a distinct hostility toward developers who work alone, and what was once the pinnacle of software productivity is now regarded with disdain and suspicion. "Not a team player." Teams are for sports.

Well then I proudly cop to not being a team player, to being a lone wolf, and I don’t get to put my feet up on the team table with the others and I don’t get invited to the alcohol-fueled team morale events. Fine with me.

But I write solid code, I can handle huge amounts of responsibility, I can manage vast amounts of detail because I can concentrate for a very long time.

And I’m never working anywhere they won’t let me do that.

Our industry is a mess.

Resources

Flow: The Psychology of Optimal Experience