Project Mercury and Death of Testing

After being in the computing business now for more than half a century, one thing worries me more than almost anything else: our lack of a sense of history. (Jerry Weinberg)

I’ve witnessed lately few great blog posts about the role of a tester and where we are going with what we understand as testing.

First Alan Page wrote his post “Death and Testing“. Then Trish Khoo delivered her thoughts in “Forget developers in test, we need testers in development“.

I’d like to share my thoughts about this subject also. That being, where should we be as testers?

Project Mercury

When we’re talking about challenging software development projects, I think putting the first (hu)man on space is pretty high on that list. Project Mercury had this as a goal on the early 1960’s when US and Soviet Union had their space race going on. Jerry Weinberg, among others, had to develop software that would help in taking the astronauts to space and back, alive.

Jerry talked about Project Mercury on This Week in Software Testing podcast, 2010. I totally recommend listening it, as it’s one of the best podcasts I’ve heard (even though you need to register to softwaretestpro.com). I took the liberty and wrote a part of the podcast, especially the part where Jerry talks about Project Mercury:

Because of the complexity and worldwide nature of the system. I (Jerry) decided that we need to have a group of people dedicated to quality, including testing of the system. We created such a group, which is as far as I know, had never been done before.  They lived through the whole project, unlike a lot of testing groups today. They were involved right from the very beginning. So, for example they could comment on whether the software we were building, was in fact testable, by then. Which wasn’t sure at all to just automatically happen.

Because this was, not only first human life system, but it was the first worldwide online system, ever build, and presented many unique problems in testing. That’s how we got into this. It was after that that other people began to realize they needed separate testing groups. But it became different. Our testing group was composed of experienced and talented software developers.

Later on, managers began to see testing groups as a way to hire cheaper people and put them in testing, because they didn’t have to know how to develop software. I’m thinking a lot of managers thought all they needed to do is sit in there on terminal and bang on keys, like monkeys. Of course that’s simply not true, but it’s taken us a long time, for many people in industry to realize, that testing is as professional, a job, as we realized it back, literally half a century ago. And many managers today still don’t understand that.

In early 1960’s testing wasn’t yet defined, which meant that Jerry, and others, were not growing up with the same dogmas as we do these days. They didn’t have the mental (or concrete) walls that tend to separate testers from development teams these days. They just tried to come up with a good solution for the challenging problems they were facing. Therefore it was natural for them that few of the team would be putting more focus on testing than the others. Also, it was similarly natural that they were there since the beginning of the project and equally part of the team, as the others.

The fact that they were skillful developers is NOT the point. The fact that they were able to be valuable for their team, IS the point.

Boulding’s Backward Basis

I heard Jerry talking about Project Mercury in the podcast, roughly year ago. That moment was one of the first that led me to learning about Boulding’s Backward Basis (didn’t knew about the name then). When people talk about testers these days, many of them mean people who are working on a separate team or otherwise separated from the development team. Personally I think these people are growing up with dogma.

If you think of it, software development as it is, including testing, is not something that it’s MEANT to be. It’s though something that it’s TURNED OUT to be. Now would be actually a good time to mention Boulding’s Backward Basis (from ‘The Secrets of Consulting’ by Jerry Weinberg):

Things are the way they are because they got that way.

I’ll admit that I’ve not dig deep enough the history of our craft, so I could connect the dots and say what lead to where (besides what Jerry is explaining above). I do know though that the idea about testers being separated from the rest of the team wasn’t common long ago and it is these days. Some people talk about future and evolving, but I think we’re going back to our roots and that’s a good thing.

One dogma to another (and beyond)

I understand testing as a mental activity of questioning, observing, evaluating and in the end, exploring. This will never go away. I hope.

I don’t know if testers being integrated part of the software development team is how it should be. It does sound reasonable for me in the contexts I’ve been. Though, it would be naive to think that this is how it’s MEANT to be. We would just be jumping to a dogma after leaving another.

Keeping in mind that we don’t know what we’re doing (see Future of Programming by Bret Victor), and at the same time putting effort on exceeding our limits. Maybe that will move us toward something better.