Tear Down the Wall

It’s interesting when I go back and look at the number of posts where I talk about what I do, what testing is to me, and how testing is changing. Ever since the Telerik Test Summit (telsum), I’ve been thinking even more about testing and how it fits into software development. When I wrote this post, and added on a bit to it here, I was pondering the same thing. When I (last) blogged about the future of testing, I (likely subconsciously) was thinking about the same thing.

A few things happened recently to make everything really click for me. One, was this article, asking for universities to offer software testing degrees – as a means to “train our testers”. Besides the fact that the author thinks that Universities are vocational schools where we train people (rather than teach people), I think it’s difficult to have a degree in something that the industry can’t define consistently (yes, I know there are test degree programs out there now, and I could make the same argument about those).

imageThen, just over a week ago at Telerik’s testing summit, we led off the open-space session with a discussion on test design. I shared some of my ideas, including how I use mind-maps to communicate test design. Towards the end of the discussion, Jeff Morgan (@chzy) asked, “Isn’t it just ‘Design’”. What Jeff was implying was that many of the details of test design should be equally at home when thinking of feature design. Rather than have programmers determine how it should work, and then have testers determine how it should be validated and explored, that those tasks could occur (for the most part) simultaneously – e.g. “To implement this feature, I need to read a value from the database, but I also need to make sure I account for and understand performance implications, whether or not the values will be localized, what the error cases are, etc.).” Much (not all) of test design can be considered when designing code – so why don’t we consider test design and code design simultaneously?

After this discussion (and for many, many hours since telsum), I’ve been thinking about programming and testing and how the two roles can work together better – and began to wonder if the test role may be detrimental to software development.

Three things are important to note before you scroll down and leave me hate-comments.

  1. I didn’t say test is dead
  2. I said “role”, not activity
  3. I purposely used the weasel-word “may” – that statement won’t always be true

And now for some much-needed elaboration.

The Wall

There’s a wall between testers and programmers. Programmers “build”, testers “break” – but passing features back and forth between one group and another is wasteful. It takes time and extra communication to traverse the wall. I spent at least the first few years of my career on one side of the wall catching the crappy code programmers threw to me. Then, I found unit-level bugs and threw those bugs back over the wall to the programmers. Then, we played this wasteful game of catch until it was time to ship. Recently, I saw a fairly prominent tester mention that their bread and butter was participating in a game of bad-code and happy-path-bug crap-catch. While I’m happy that there are easy ways to make money in testing, I’d rather tear my eyelids off than do work like this. I like what I do because it’s hard. Finding happy path bugs in crappy software isn’t hard. It’s boring and practically demeaning.

The Neotsys blog latched onto one of my recent posts in their testing roundup. They said that my team at Microsoft has moved to the “whole-team” approach, but that’s not true. We still have testers and programmer roles – and while programmers frequently write test code and testers frequently write product code there’s still a wall. Programmers are still responsible for writing product code, and testers are still responsible for testing – we just don’t have a problem crossing those lines.

We still have a wall. It’s a small wall, but it’s still there.

Tear Down the Wall

If you played with my recent thought experiments of programmers who can test and testers who can program, it’s not much of a reach to picture a team where there are no programmers or testers – just contributors (or developers or engineers, or whatever you want to call them). If you have a hard time imagining that, imagine your current team with no walls between role responsibilities. Many of you may do the same thing you’re doing today, but with the walls gone, I bet you could make better software – faster.

Figure out what needs to get done, and get it done. Leverage the diversity of the team. If someone is a specialist, let them specialize. If they’re not, let them optimize for their own skills.

Tear down the wall.

Titles

On a quick side note, testers worry (far too much) about their titles. This recent blog reminds me of the idiocy of tester titles (and I’ve discussed it here). There will always be a place for people who know testing to be valuable contributors to software development – but perhaps it’s time for all testing titles to go away?

The Future?

I’ve written in the past about where test is going – toward data analysis, non-functional emphasis, etc., but I think I was at least partially wrong. What software teams need in the future is team members who can perform the activities of programming, testing, and analysis – together.

I saw a slide deck recently that stated, “Agile Testers frequently can’t keep up with Programmers”. Good software development can’t happen when you serialize tasks – the team needs to work on this stuff – together.

I’ll always be deeply involved in the activity of software testing, but I don’t know if the role or title exists in my future. After nearly 20 years of being a tester (and likely several more with that title), I’m admittedly going out on a bit of a limb with that statement. Despite my title, I want the walls to go away.

Testing can’t be something that happens after programming is complete any longer. Testers aren’t “breakers” any more – but experts in the testing activity are (or need to be) as critical to making software as anyone else on the team.

Since it’s mostly testers who read this blog I challenge all of us to shed any remnants of tester vs. programmer and figure out how to tear down the wall.

I’ll let you know how my own battle goes.

Comments

  1. Why were the roles separated in the first place? I honestly don’t know but I’d be willing to bet that there were smart people who thought it was a good idea.

    I personally think that testers and devs start with different skills but eventually grow into the same skill sets, assuming they each keep growing and don’t defect to some other role. Devs are considered senior when they “cross the T” whereas testers start their careers by making the cross but later develop decenders into deeper knowledge of different areas. “Stalactiting the ceiling”? I don’t know what to call that. Eventually you end up with senior/principle/achitect/whatever-uber-level devs and testers who have the dev and the test knowledge. Again, assuming both continue to grow, and in my opinion the anti-coding testers actively choose to stagnate.

    So if, and I suppose that’s a big IF, testers and devs are on separate tracks for some good reason and they each eventually grow toward the same track . . . does it make sense to continue to have separate roles at the entry level? Much as it pains me to say so, I think it does. At least it makes business sense. This level of specialization makes both testers and developers cheaper to hire and easier to replace.

    That said, I’d honestly like to see a future where more *testing* is built in everywhere from design through post-release feedback and monitoring and the role of the *tester* is diminished to possibly even vanishing. I think a lot of that could be accomplished via process changes and automated systems instead of asking devs (and ops) to suddenly gain a lot of testing knowledge. Compare this to the transition from needing to be an expert in card catalogs and inter-library loans to find information to web search. Or search to the still-elusive goal of “discovery” – information you want that finds you so that you don’t have to find it. We’re technologists; it’s our job to solve problems like that.

    1. Thanks for the response – I think you captured the essence of where I was going quite well.

      As far as “who built the wall” – I bet it made sense, and was the right thing to do once. At the time, we (as an industry) didn’t know a lot about testing. We know a lot more now, and we ship more software more frequently. The wall may have been absolutely the right thing to do at one time..but not any longer.

    2. My guess is – and this is not a wild guess – that the walls were put in place because the work of testers in the classic model (setting up configurations and then running manual test scripts based on business specifications) is time-consuming and doesn’t require a software engineer. The testing role was born so that developers weren’t being paid their high salaries for unskilled work. The idea of an “expert” tester that contributed something a developer could not was probably not anticipated at the time. A tester’s primary contribution was costing less.

      A mature development organization in 2013 is hopefully not rolling that way, but there are a lot of people around that unconsciously still take that view, that testers are around because developers are too expensive to spend their valuable time testing things.

      Alan I agree with your post 100%, and I am working toward that goal myself in my own organization. I have a lot of thoughts on this, I should probably just roll them into a post of my own.

  2. Thoughtful post as always.

    I’m now working at a place where they dont have walls, they have ‘poly skilled’ teams where designers and developers work together to build quality products fast. They’ve worked out how to integrate design and development and the devs are pretty damned good at testing. They did find something was missing and wanted to take on a specialised tester which is where I came in – and I’m finding it one of the hardest challenges of my career. It’s easy to feel useful and think you’re adding value when you’re knee deep in bugs – not so easy when you find that projects have shipped without you input and somehow seem to work well

    did you have to tear down walls or do you think you still have to? If not, how did you get to the situation where there weren’t walls – was it a deliberate approach or an evolution?

    1. You are closer to my vision than I am. I’m slowly tearing down walls (and many teams at MS have already torn them down), but I have work in front of me. Your role is a great example of how “testers” impact product teams of the future (or in your case, today).

      1. You said: “but perhaps it’s time for all testing titles to go away?”

        How do you manage that at the HR level? HR and execs and directors and managers like to identify and label. Good luck getting buy-in on that…

        1. Really? I don’t think they care (and they shouldn’t, because no good software has ever been created by an HR department).

          I think there are much bigger obstacles and challenges to this than keeping HR happy.

          1. Maybe I need to rephrase my question. How do testing titles go away without buy-in from all interested parties? I’m referring not just to HR, but also executives, directors, and managers. Consider my question posed from the point of a view of a large corporation.

          2. Well, for one, you don’t /start/ by just removing everyone’s title. You start by /acting/ like the titles don’t matter. You start by having a team with no walls between disciplines, where people use their strengths and collaborate to make great software. You start by forming a team (within the large corporation), where titles don’t matter.

            Once they don’t matter – and if the benefits are obvious, I doubt any pointy haired bosses would care.

            And then you do it on a different team – or a larger team and see if the idea grows – but it won’t happen just by flipping a switch and removing titles.

  3. Hi Alan,

    Thanks for the post. Interesting read and something for me to think about more, however if a tester would like to be more technical (understanding development environment) – how would the said tester go about doing this?
    – Skilling themselves up in the said development environment language of choice?
    – Writing automation for the said development environment?

    Do you have any other examples?

    1. If you’re a good tester already, don’t change a thing. The key to successful software teams is diversity, so if you’re already contributing, there’s no need to learn more.

      In my case, I’m a better tester because I learned programming and how things work under the covers. Your goal should be to be as valuable to your team as possible – look for what the team needs, and get better at that. It may be programming skills – it may be data analysis – it may be something else.

      IOW – it depends.

  4. I am curious to hear if anybody has tried such a thing. The context I’d be interested in hearing about it would be: 1) an established company with more than 100 employees, 2) creating a particular software product, and 3) with a staff assigned to the product of at least 6 to 8 individuals for various duties.

    1. I work for an established company consisting of well more than 100 employees. We have a few different product teams (each over 100 people) creating customer facing software with one title for all engineers.

      There are a few glitches, but it does work.

Leave a Reply to Alan Page Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.