SourceForge.JP: Open Source Software

私がプログラミングに手を染め出したのは1960年代の話であるが、その当時のテストといえば、作成したコードが正常に機能するかを確認するのが相場であった。こうした固定観念に大きな変化をもたらしたのはIBMのBlack Teamであり、彼らは従来とはまったく逆のアプローチを採用したのだが、それはこの時代としては画期的な“コードを解析することでプログラムを検証する”という発想に基づいていた。その次に旋風を巻き起こしたのが、プログラムの作成時に意図した個々の機能を総当たり式にチェックするホワイトボックステストという手法である。

これらのアプローチはクローズソース式のプロプライエタリ系ソフトウェアの世界で編み出されたものであり、FOSSの世界におけるプログラムのテストとなると、その手法は大きく異なってくる。例えばバグレポート1つに関しても、前者では個々の製品に割り当てられた専属の検査チームが行うのに対して、後者では不特定多数の人間が報告してくるという違いがある。FOSS系プログラムにおける“多様な人間による検証”という態勢を実現させているのは、コードの扱いに関する透明性に他ならない。

まずは、かつてDebian Project Leaderを務めていたMartin Michlmayr氏によるアドバイスを紹介しよう。「テストをするなら、最新のバージョンを用いるべきです。それは当たり前のことだと感じられるかもしれませんが、そうした行為を実行するのは口で言うほど簡単ではありません。例えばDebianの場合、最新版へのアップグレードをすれば不安定バージョンに手を出すことになりますし、実験段階のパッケージを抱え込む可能性もあります。その他のソフトウェアの場合でも、プロジェクトの運営するバージョン管理システムの中から最新バージョンを探し出した上で、存在するのか存在しないのか不確かな不具合を特定するという作業を続けなければなりません」

「この種の作業を行うには、ある種の創造力が必要ですし、反応の速さも求められます。既に解決済みの不具合に対してどれだけ多数のバグレポートが報告されてくるかを知ったら、誰でも驚かずにはいられないでしょう。テストをするなら最新のバージョンを使い、バグトラッカの記録も確認しろというのは、そうした理由があるのです。仮に最新のバージョンを利用できないとしても、自分が遭遇した不具合は最新リリースでも当てはまる問題であるのか、という点を確認することくらいは最低でも必要ですね」

「先に触れた創造力についてですが、Debianに寄せられる様々なバグレポートの中には、非常に有用な報告が含まれています。それと同時に、誰でも簡単に見つけられる極ありきたりな不具合に関する報告も多数送られてきます。そうした中で真に役立つものは、創造力を発揮して事態の本質を見極めた意見であって、あるいはそうした報告ができるのは非常に辛抱強い人だと言えるかもしれません。ソースコードをつぶさに読み解くといった行為は、プログラムコードの学習をする場合には非常に役立つでしょうが、必ずしも不可欠ではありません。例えば、マニュアルやmanページに書かれている説明とプログラムの実際の挙動とを比べてみるという貢献もできるでしょう。文章として書き起こされた解説が現実に即さなくなっているという事例は、いくらでもあるはずですから」

「極端に動作速度の遅いハードウェアや利用者数の少ないプラットフォームといった、普段行わない操作や特殊な環境での動作を検証してみる、という貢献の仕方もあります」

Michlmayr氏以外にも、GNOMEのバグマスターとして知られるLuis Villa氏、Debianのバグ検出の達人であるDan Jacobson氏、Linuxベースのアマチュア無線用アプリケーションの制作者であるDave Freese氏から得られたアドバイスも参考になるはずである。こうした先達の意見を整理すると、優れたテストを行うためのポイントは下記のようにまとめられる。

• テストするソフトウェアは最新バージョンのものを使う
• バグレポートをする場合は、それが過去に報告済みの不具合ではないかを確認しておく
• バグレポートには、不具合を再現するのに必要な情報を含めておく
• 説明する文章の上手い下手については、過度に神経質にならない
• バグトラッカないしはそれに類するシステムがあれば、それを参考にする
• 可能であれば、ユニットテストの自動実行用スクリプトを作成する
• コードのテストは、できるだけ現実に即した環境で実行する
• クラッシュレポートの自動送信ツールがあれば、それを利用する
• コードのコンパイル、リンク、テストに関係するツールに慣れ親しんでおく
• 可能であれば、異なる環境でのテストも行えるようにしておく
• どのバージョンでエラーが混入したかを特定できるよう、過去のコードもある程度保持しておく
• どのような条件で不具合が発生したかを、可能な限り詳細に説明する
• “初心者が感じた印象”というのも貴重な情報であり、実際に体験した内容をそのまま報告する
• 開発者からの反応は、辛抱強く気長に待つ

Michlmayr氏は、参考になる文献として下記のものを紹介している。

『How to Report Bugs Effectively』 （バグレポートの効果的な行い方）
『Bug Writing Guidelines』（バグレポートの執筆ガイドライン）
『How to Write a Useful Bug Report』（効果的なバグレポートの作文法）
『Lessons from GNOME Project QA』（GNOMEプロジェクトの品質管理に関する教訓）

プログラマやコンピュータマニアでなくても、プログラムのテストという形において、FOSSの発展に貢献をすることは可能である。あなたにその気があるならば、まずは馴染みのあるフリーソフトウェアについてのバグレポートをプロジェクトに報告してみればいいだろう。

NewsForge.com 原文