Creating Transparency


I was at the Better Software conference last week, met a bunch of great people (including Jim Shore and Joel Spolsky).

Another important person is someone who’s not famous–and important nevertheless. A senior tester explained her situation and asked for some help. “Most of our testers can’t read code. And, we don’t know what the developers are putting into the code when they fix problems. Even if the testers could read the code, we don’t know what to look for. We don’t know what to test. The developers add and change features without telling us.”

I asked if the developers had to write check-in comments. She said that they did not. I suggested she work with the build people to write a script that forwarded every check-in comment to an email list of all developers and testers. If there was no comment, it would be an empty email with just the person’s name and the filename. If there was something in the email, she and the rest of the testers might have more information with which to test.

On this project, there is little transparency about who is doing what and the kind of progress they are making. Normally, I wouldn’t email check-in comments to an entire project, but if there is no other way to see what’s happening, it might work.

Transparency in a project is key to the project’s success. No, it’s possible that not everything has to be transparent. If you’re working on a project where you have different levels of clearance for product content (something that occurs on DOD projects), then it’s critical to keep some content opaque, not transparent. But most of us work on projects where transparency would help–sometimes dramatically.

I didn’t gratuitously name-drop at the beginning of this post–I had a reason 🙂 Both Jim and Joel make portions of their work transparent to the rest of us, so we can learn from them. We need to learn from our own projects too. If there’s a piece of your project that seems to be causing problems for another part, think about how you could make the output of the “troublesome” part more transparent to everyone. You may well discover the troublesome part is reacting to someone else’s work that’s not transparent.

If you’re a project manager or involved with project management in some way, think about what is not transparent to the rest of the people involved with the project. Could you create some transparency to make things clearer? It’s worth a little thought.

5 Replies to “Creating Transparency”

  1. Johanna:
    I enjoyed meeting you at the conference last week. Your presentation was excellent.
    Ken Katz

  2. In general, testing is divided into white-box testing such as unit-testing and black-box testing such as functional or integration testing. Often, programmers are responsible for white-box testing because they understand internals and QA staff is responsible for black box testing because they try to test features and perform exploratory testing to find bugs. However, I am not sure sending checkin-comments can help in this situation especially programmers may be committing small changes several tiems a day and it would be hard to build a mental picture or design from these comments. Instead, I would suggest that testers be involved in design sessions and learn how internal ddesign works.
    By the way, I am big fan of your blog and also have a copy of your book.

  3. The “problem” described in this thread is very common. As a long-time developer, and manager, etc. I’ll say the right answer is “proper release management”. This is, source configuration management, properly baselined code, defect tracking, defect to source code mapping, practices (such as comments and naming convention) _AND_ reporting that allows testing to query “what the hell is in today’s build”. The latter is key, as it allows testing to concentrate on specific areas, re-test functionality, w/o knowing low-level details and/or wasting time testing areas w/o change.
    P.S. I recently discovered this blog, and it is a great blog/info; I’m now subscribed to it – thanks 🙂

  4. In my oppinion a full transparency is just the must. Unfortunately expecting developers to put meaningfull check-in comments is a bit naive, when enforced to put comments they are smart enough to put any blah-blah that in fact will do more harm than good. For that reason I have been always in favor of a tight integration between defect tracking and version control system. When it’s in place it would enfornce a developer to supply a defect tracking system ID for any check-in and that would give testers enough information about the change. In such environment we typically submit new features and re-factoring activities to the defect tracking system as well in order to have a complete follow-up. With re-factoring do not expect too much from the comments.
    Those who are using IBM’s Clear Case/Clear Quest suite will get this integration for free as a part of Unified Configuration Management solution. Users of other systems will need some local customization. I did it once with my team for Bugzilla and CVS. It took two days and a small Perl script to achieve a required level of integration.

Leave a Reply

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