Monday, October 25, 2010

Anybody Need a Pair?

Here's a dirty little secret: testers are probably the biggest generalists on any team. Your average tester can write some code, parse a customer's request into a requirement, draw boxes on a board to explain the system design, install a new package in the test lab, and go through logs with a support engineer to see what on earth the customer might have done. Oh yeah, and test. Generally, your tester isn't your best developer, is not your greatest business analyst, probably doesn't understand the system as well as the architect, but he's pretty good at a lot of things (and often very good at testing).

So if you're a tester and you want that kind of breadth of knowledge, how do you start?

Pair with anyone who will let you.

Okay, maybe you're not in an agile environment and ya'll don't do pairing. In that case, the question is "can I sit with you for a while and...?". It's still pairing on some level, we just won't call it that! You get to learn about what they do and about the system from a different perspective, which can only help you test better. They get the benefit of fresh eyes, and of having to explain things to a newbie.

I don't think this was set up intentionally, but in every functional engineering team I've worked with, the test team is the glue that crosses silos. You want to be in that position. You want to be the team that sits with development and says, "You know, I heard the support team complaining about that taking a long time to do serially. I think they said they had a customer that added 200 widgets a day, and the customer was none to happy about having to do it one widget at a time." It may not get the workflow changed, but it starts the conversation, and you have a decent chance at fixing real problems before you ship.

So when in doubt, find someone and go pair. It's amazing what you might find, and you didn't even know you were testing!


  1. "testers are probably the biggest generalists on any team" - that's a pretty good insight. That actually offers me an insight into how migrated into software test. I sometimes explain it as an evolution from chip design and test, to software tools for chip design and test, to simply test of software tools. But it is probably really more because I am interested in everything and like to stick my nose everywhere. While working in test I have been called upon to help customer support, pre and post sales, marketing, and development.

    I like your ideas about developing the breadth of knowledge, and most of all getting the conversation going.


  2. This is better than "forced" pairing probabaly

  3. This post resonates really well with me as well.

    When I started testing, my eventual goal was to the the "real" hard work and be a developer. I did that, however, and found that I really didn't like it.

    I have described for years that a lot of what testing gives me is a "variablility", or a "diversity" that programming didn't. If I wanted to write, I could write some documents. If I wanted to code, I could work on test automation. If I really wanted to break stuff, I could find a hacker friend and learn the sneaky tricks. If I wanted to see why my app crashed on this one specific job, I could get with my systems guys and monitor the server processes to watch it fail.

    I've spent a lot of my testing career jumping around, learning a little bit from other people, and now can see exactly how your description fits my own experience :)

  4. I don't know if I agree with the statement that Testers are necessarily not the best developers, or that we may not know the system as well as the 'architect'. Let's be honest, Not everyone can put their mind in the testing mindset. When I was doing pure development work, guys would ask me to test stuff for them all the time. Why? Not because I was bad at Developing, but I was very quick at noticing defects. Also, sometimes developers may only be aware of a small segment of a system, and are oblivious rightly or wrongly at how a change in their system has repercussions in several other parts they do not hold responsibility for. In such a case its the tester's job, to find those areas and test them to make sure things work correctly.

    However, I do understand why some people on the outside seem to think Tester = Failed Developer. I just happen to believe that testing isn't about development skill, but about thinking skill.

  5. Wow - so many people like playing in so many different places!

    Veretax, keep in mind that being a tester doesn't make you a bad developer. It just means that there's probably someone around who's done it more recently and is a bit fresher than you. Unfortunately, we aren't going to be the best at everything - but we can be pretty darn good at a lot!