News Stay informed about the latest enterprise technology news and product updates.

Getting a jump start on software test collaboration

Having tested software during many projects, I’ve seen that the most effective testers are the ones who start early — and I don’t mean the ones who start testing early. I’ll explain what I mean with this step-by-step tour of a pattern I’ve noticed multiple times in software testing projects.

1. A project starts.

2. All the testers work very hard to understand the problem they are trying to solve.

3. Eventually, some small amount of “working” — a very subjective term — software gets delivered to a development environment for the developers to do their unit testing and debugging.

4. One group of testers — often those doing exploratory testing or those working in an agile project context — ask the development team if they can get involved and help test that early code. They don’t care if they can’t log “defects,” because they just want to see the product and provide feedback when and if the developers think it would be helpful.

5. Another group of testers (often those doing scripted testing or those working in more “traditional” corporate testing environments) say they want to wait until unit testing is complete before they start their testing.

6. The group that starts early develops an early collaborative relationship with the developers who let them test their code.

7. Eventually, some small amount of formally “working” software gets delivered to a test environment for all the testers to begin their first test cycle.

8. At this point, both groups of testers start their first test cycle, and both find and log issues.

9. The issues found by the first group — those who worked more closely with the developers — tend to get resolved first, not based on priority or severity, but based on the personal relationship of the tester to the developer.

10. If a defect from that first group — those who worked more closely with the developers — can’t be reproduced, the developer comes over to work with the exploratory tester to isolate the problem.

11. If a defect from the second group — those who waited to start testing — can’t be reproduced, the developer sends it back as “can not reproduce” or the ever famous response, “It works on my machine.”

Before someone points out that “it’s not always practical to start testing early,” and that “there are a lot of good reasons to wait,” I get it. I’m not advocating that in all circumstances you should start testing early. There are plenty of reasons where that might not be practical. However, I’ve never worked in anywhere I would say that’s been the case. And I’ve seen this pattern a lot. It’s not universal, but it’s very common.

The testers who get a jump-start on collaborating with the development often have a closer relationship, and are thus viewed as an asset. It is these testers who are often pressed to help isolate a defects, even if it wasn’t logged by them. They are also the testers who get invited to design review meetings, because their opinions are highly valued.

Does that mean you have to get involved early to be an asset or to have those relationships? Absolutely not. But, I suspect that if you can, you’ll have a better chance of collaborating with people on your project team before pressures are high, stress is up and your “feedback” is viewed as a call for another late night debugging session.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

You say you've never worked in an environment that doesn't allow for getting involved early. I've never worked in this environment either and most of my friends and peers have also never worked in this environment either. So does that environment exist? Or is it a convenient excuse? Or is it simply some testers don't know how to make their way in early? I liked the article but I tend to see that defects get raised in these informal/formal early testing sessions. They get found early. They get fixed immediately. They often don't get entered to the bug system. So the net effect I see is that the early involvers don't raise as many defects when entering their formal testing phase. The same goes when I get involved at a design stage. I can help the team to design out some of the defects I would riase when testing. Some are obvious, some not so. But being involved early allows you to air concerns and design decisions earlier meaning less chance of defects. It also allows you to lay down the types of things you'll be looking for when testing which often results in programmers unit testing for it, designers and BA including more detail in specs/stories etc and the testers being trusted for their honesty, critical eye and ease of working with. If only all testers could read this post of yours. It's a great post. Lots of insight. Rob..