With TDD, BDD and tools providing code coverage, automated checking, continuous integration, continuous delivery, one could argue that testers are no longer needed. A developer can do both, can’t they?

Whilst I’d love to believe that every developer working on an application took time to look over the whole application after delivering some functionality, within large scale agile enterprise development, given tight timescales, this is unlikely. Even testing their area rigorously enough in a way that pushes the boundaries would be a novelty for some.

Automating various checks will validate positively and provide confidence that the software works as intended, but plenty of bugs will slip through. This, in part is due to attempting to write down your thoughts whilst solving problems. You won’t get the coverage required to find every issue. So having someone dedicated to looking for problems reduces the number of unknowns considerably, but can also provide product owners with the confidence that they are getting the software they expect.

Liz: What do I want? I’ll tell you what I want! I want Ken Railings to walk in here right now, and say 'Pam Shortt’s broken both her legs, and I wanna dance with YOU!'
[the door flies open. It’s Ken]
Ken: Pam Shortt’s broken both her legs, and I wanna dance with you.
Kylie: That was unexpected.

With testers involved, expect the unexpected.

/ In the real world

In our experience of developing trading applications for various clients, the interactions involved are numerous and complex. This experience has shown that having dedicated test resource has enabled the identification of thousands of issues, the majority of which would not be found with just automation, developer testing and business acceptance testing.

The complex interactions required of a system that has multiple interactions and multiple states, requires a much greater level of testing to identify risks and issues and ultimately produce a quality product. This is not something developers alone can do unless you sacrifice features, time to market and stability.

Testers find important, critical issues early, providing tight feedback to developers so they can be fixed quickly, making each iteration more stable, more usable and more shippable. This gives confidence to the Product Owner that your development team is working well and that once the software is live, there will be a minimum of problems for the intended users.

/ But, testers don’t find all the bugs

Having testers constantly questioning the software and asking questions of the developers gives rise to others not only thinking critically about something they perhaps hadn’t before, but also thin-slicing without realising. Sub-conscious thin-slicing, also known as a Blink test, can occur when people ask questions. How many times, as a tester, or developer, have you asked someone to take a look at an issue and the other person spots a different one? Their sub-conscious is activated by the conscious act of questioning, leading to new problems being discovered.

This is a regular occurrence when you have testers as part of your development team.

/ Testers question premises and when premises are questioned, unintended consequences can materialise

Carl Sagan said:

"There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question"

And Colin Powell said:

"there is no such thing as a stupid question, only stupid answers"

Whilst not specific to software, an example of this is the iPhone 6+ 'bendgate'. The premise that because the phone had been put under a 3 point flexural test, it wouldn’t bend under normal circumstances was one that was questioned by Unbox Therapy. Here’s the original video as a reminder. https://www.youtube.com/watch?v=znK652H6yQM

Now this isn’t 'normal' circumstances per se, though there have been sites dedicated to the bending, but the premise was questioned. As it turned out, Unbox Therapy had applied a four point flexural test which produced markedly different results.

Asking questions can lead to different tests that will produce different, important outcomes.

/ Tester interactions lead to better outcomes

Staying on the problems with iPhones, another issue that I’m sure most people remember is “antennagate”. Here was a phone that couldn’t make phone calls when you held it in a particular way. Now, it may have been this problem was identified by testers. If it happened to other phones, which Apple was more than happy to point out, then it’s likely this issue was well known by experienced device testers. However, once it hit the mainstream media, the problem was amplified. In the end it may have cost Apple in excess of $175m. Small change for them. A princely sum for others.

There was an upshot though. That costly interaction led to a better outcome. Redesigned antennas that don’t exhibit the same issues, no matter which way you hold it.

/ Bugs, bugs, bugs

The above two iPhone features demonstrate a point, but they do little harm to the provider or user; Here are some examples that demonstrate the extreme end of problems that can occur and in a few cases, could have led to horrific consequences.

/ Hatford Civic Center, Johnson, USA.

What happens when something isn’t built to the specification and not tested? Well, here, complete collapse of the structure due the loads being underestimated and a lack of testing during construction.
https://failures.wikispaces.com/Hartford+Civic+Center+%28Johnson%29

A system of checks and balances needed to be preformed. The use of traditional design factors of safety, used with nontraditional methods is something that should never be overlooked. However, such a large error in design cannot be compensated by an arbitrary design factor of safety increase. The computer is simply an analytical tool and can never guarantee the correct solution. The operator should be experienced and competent about all information that is put into the model and fully understand all of the information given out. Assumptions should be checked and compared to the as-built conditions to verify that field measurements match those of the original design. In general terms, it was noted that there was confusion over a number of design and construction responsibility issues that contributed to the collapse but could have been avoided.

/ How about automation being relied upon?

http://www.investopedia.com/features/crashes/crashes6.asp
In this first case, it caused huge financial loss. $500 billion was lost in one day in 1987

As people began the mass exodus out of the market, the computer programs began to kick in. The programs put a stop loss on stocks and sent a sell order to DOT (designated order turnaround), the NYSE computer system. The instantaneous transmission of so many sell orders overwhelmed the printers for DOT and caused the whole market system to lag, leaving investors on every level (institutional to individual) effectively blind.

/ An even worse possibility was averted in 1983 had the automated system been relied upon.

http://archive.wired.com/science/discoveries/news/2007/09/dayintech_0926

1983: A Soviet ballistics officer draws the right conclusion - that a satellite report indicating incoming U.S. nuclear missiles is, in fact, a false alarm - thereby averting a potential nuclear holocaust.

/ This is however, a great example of how Waterfall can fail spectacularly.

http://www.zdnet.com/article/child-support-it-failures-savaged/

The NAO report also found that although all the software fixes in the last year have been delivered successfully and on time, there are still 500 faults with CS2 that have to be dealt with, three years after the system went live.

I worked on this project, seems like eons ago, initially as a tester, then as a developer. With such a large project and a big bang approach it was destined to be problematic, even with the hundreds of people working on it.

/ And finally

A slightly less alarming, fairly amusing bug caused an 'epidemic' in World of Warcraft. The fact that when testing this, nobody thought to test anything remotely related to trying to spread the disease shows that the testers weren’t asking the right questions.
http://en.wikipedia.org/wiki/Corrupted_Blood_incident

It may well have led to a better outcome, should a real incident occur.

The conditions and reactions of the event attracted the attention of epidemiologists for its implications of how human populations could react to a real-world epidemic. Anti-terrorism officials also took notice of the event, noting the implications of some players planning and perpetrating a virtual biological attack.

So when developing software, including testers as part of the team should be a natural addition. But how they go about testing is just as important.

http://listverse.com/2012/12/24/10-seriously-epic-computer-software-bugs/
http://www.devtopics.com/20-famous-software-disasters/