Comments on: Creating Transparency

By: Asher Sterkin

Asher Sterkin — Thu, 06 Jul 2006 00:13:03 +0000

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.

By: C. Enrique Ortiz

C. Enrique Ortiz — Tue, 04 Jul 2006 21:44:15 +0000

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.
ceo
P.S. I recently discovered this blog, and it is a great blog/info; I’m now subscribed to it – thanks :-)

By: Shahzad Bhatti

Shahzad Bhatti — Tue, 04 Jul 2006 19:51:36 +0000

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.

By: Johanna Rothman

Johanna Rothman — Mon, 03 Jul 2006 21:27:42 +0000

Thanks, Ken. I enjoyed meeting you too, and your presentation was also excellent.

By: Kenneth P. Katz

Kenneth P. Katz — Mon, 03 Jul 2006 20:37:47 +0000

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