Knowing Your Limits
Once you've gotten into the habit of noticing organizational problems and predicting their effects on the software, it's natural to want to get to the root of many potential defects by fixing the organizational problems.
If certain people aren't talking, schedule them to attend reviews of each other's code. If design documents are lacking, require them to be updated. If separate teams need to write code that works together, make them sit together and report to the same manager.
These are all good ideas, but the trap lies in thinking that it's your place, as a tester, to tackle these issues. There are two problems with this.
- Testing well requires that you have access to design documents, development meetings, and interviews with developers. It can be hard to win the trust necessary for this access. Pointing fingers will lead you to losing this access. This is why it is so important to write defect reports in a neutral, nonblaming tone.
The developers may be amazed at your intuition, but the managers probably already know about the problems. Personnel and communication problems are not always easy to fix. Indeed, pointing them out for public attention often makes them harder to fix. This is the trap: The response you get from some might be to conclude that you are the problem.
If you are truly savvy at noticing the correlations between people, the organization, and the resulting software, and you really want to try to fix these problems up front, then you need to get into management. I've known plenty of software testers who were able to build careers as project or development managers from their start in testing. If that's not for you, then stick to finding and reporting the bugs, and use your organizational observations to help you do the job. Your crystal ball can be a big help—if you use it wisely.