Why split development and testing?

If you had an equal skill set to be either a developer or a tester, for the same pay and career opportunities, would you rather be a developer or a tester?

This is a question I have been thinking about over the past few days, as later today (at the time of publishing this blog post) I will be involved in a session for my Testing Community of Practice “Psychology” of a tester: Why do we split the function of testing and development? (see my last post for further details).

So if you had to pick being either a developer or a tester, which would it be and why?

Where I work, and likely for the vast majority of those involved in software development and testing, the skills and job titles differ between developers and testers, although it is getting more blurry due to roles such as SDET, and TDD being looked at as a development method. But why? And should it still be?

Now, you may be thinking and wanting to comment that developers do test with unit testing their code. To that, I would certainly hope so, though I doubt any tester working long enough hasn’t had code for them to test where they wonder if it has been unit tested… But, the scale of testing is different when compared to testing a business process, or other testing such as load, performance or security testing.

One key difference I see between the two roles, and why they separated, is mindset. Developers are Builders, whilst testers are Breakers.

A developers has something tangible when they are done, some form of code that performs a function of some kind, whether it be a fancy looking web page for using from the front end, or code that lives behind the scenes that no-one will ever see but keeps the cogs turning.

Meanwhile all a tester can do is try and break whatever the developer has made, until it stops breaking and a robust product is left behind.

As I type this, the tale of the three little pigs comes to mind, with the pigs having progressively better houses until the wolf fails to blow it down. Now instead of houses it is software code.
The first pig makes their code and is happy with it, meeting the requirements they were given. But when the wolf comes along, he breaks the code.
The second pig, seeing where the first pig went wrong, builds better, more robust code. But once again, the wolf breaks the code.
The third pig makes further improvements to the code, and hands it over to the wolf, where no matter how hard they try, they can’t break it.
The first two pigs built something they were happy with, and met what they were asked to do, but until someone came along to try and break it, they never realised how frail their creation was.
But in the story, the wolf isn’t the hero, helping the pigs out. The wolf saved the first two pigs. If i lived in a house, only to find out it would fall apart when it got windy and crush me to death, I wouldn’t be happy at all!

Can people easily switch the mindset between breaking and building something, or will we always need to have people with distinct attitudes, and thus keep development and test apart?

And to answer my own question from the start, I would rather break than build, and thus I test.

Advertisements

8 thoughts on “Why split development and testing?

  1. In the building analogy I think testers might be more like surveyors.

    I think our job is a bit more like a quality snag at various points throughout build until thorough inspection upon completion.

    I guess we do apply a ‘demolition expert’ mindset though

    Liked by 1 person

  2. We do not break the software. The software is what it is. It’s broken, or not, when we get it. Calling a tester a breaker is like calling a pathologist a killer.

    That can have real PR and political consequences. “Everything was okay… until *the testers broke it*.” “We could ship right now… except *the testers keep breaking it*.” “We don’t have structural problems in our development process that make for a bug-friendly environment; it’s just that *the testers break it*.” Be careful how you present your role and your work.

    But you raise an important point: testing does require a different mindset from the builder; an analyst’s mindset more than a synthesist’s mindset; a skeptic’s mindset, rather than a optimist’s mindset; a questioning mindset, rather than a credulous mindset. So I’d say we’re not breakers, but investigators.

    There are things that our investigations help break, sometimes: illusions that all is okay; unwarranted confidence; shallow certainty. But we’re not breaking the product; only some people’s fantasies about it.

    —Michael B.

    Liked by 1 person

    1. Thanks for the comment Michael – It’s great to have a comment from someone I have been reading online.

      I remember reading your blog (http://www.developsense.com/blog/2015/02/very-short-blog-posts-25-testers-dont-break-the-software/) where you quote James Bach about how we break the illusion that it was working, and how we didn’t break it ourselves.

      When I was talking to my wife about my blog last night, she even said how she explains my job to others is breaking code, so it is seen like that even by those with no IT experience.

      I see your point about seeing us as investigators over breakers, and as a fan of encouraging exploration over tightly regimented scripts that must be obeyed or else, it’s resonates with me.

      In an internal blog where I work, I made a post a few months ago saying how we break illusions, and that we are critics, explorers, scientists.

      So my intent is there, perhaps it is simply how I’m delivering that message I need to refine.

      So with the difference in mindset, do you feel that testing and development should be kept apart, or that blurring the lines between both will only improve everyone involved, rather than diluting them?

      Like

    1. Thanks for the comment Jamie 🙂

      Whilst it’s true that it was already broken, it doesn’t have the same ring to it sadly saying we find where it’s broken 😉 Though as Michael said above, we break the illusion that it was working. I also imagine we also break the patience or spirit of some devs, depending upon how often they have their work returned to them…

      Liked by 1 person

  3. “Breaking” comments covered above aside, I think you’re definitely on to something about fundamental motivations. My own mostly-formed-thoughts on this (https://testingmanagement.wordpress.com/2016/03/14/devs-are-engineers-testers-are-scientists/) are about testers being motivated to learn and understand things rather than breaking. But, I still feel that for many testers there’s definitely some part of the mindset that really enjoys making things happen differently from how they were intended (which I think ties in with what you call “breaking” above).

    Liked by 1 person

    1. Thanks for the comment Edd.

      It’s good to know that others see there is a mindset difference between a developer and a tester, though for myself trying to “break” something (i.e. prove it actually IS broken) is part of learning and understanding something. If I find out that a username field can’t handle a 100 character username, for example, I’ve learnt something new about that component that I previously didn’t.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s