InterConnect Blog

こんにちは。

今回も、ソフトウェアのテストを行っているチームのマネージャー(責任者)よりお伝えします。

この投稿にはMicrosoft内部で使われる専門用語(MSの方言？)が含まれています。ここではあえて言い換えないでそのまま使います。

言葉の意味はこの投稿の最後に書いておきます。

----------------------------------------------------------------

皆さん、こんにちは。

今回は現在開発中のInterConnect 2007 に対してどのようなアプローチでテストに臨んできたか、それを少し紹介したいと思います。

まずテストグループとして意識して行ってきた事があります。それは・・・　「進むための判断材料・基準を掲示していく」というスローガン（キャッチフレーズ？）です。これは何なのかということの前に、少し開発の背景を説明させて下さいね。

InterConnect に限らないと思うのですが、実際の開発の現場だと新しい機能紹介・既存機能改良をたくさん行いたい一派（勢力？）と、プログラムの品質を保つため変更を極力抑えようという一派（集団？）のぶつかり合いがあります。でもユーザの立場になれば、良い機能・使えるサービスが高品質で提供されている事を当然期待するわけですし（それが当たり前ですから・・・）、開発に携わっている人間達も時に勢力分布する事もありますが、基本となる強い思い（自分含めて）はどちらか片方に肩入れする事はなく、両方を実現するよう日々努力を重ねているのが実態です。

とはいうものの、コード(*1)変更量が多ければ当然プログラム全体の動きにも多大な影響を及ぼすのも事実。うまく動かない部分がでてきたり、結果が意図しないものになったりという状況になってしまうのです。コーディング(*2)担当者に向かって“変更が与える影響を充分考えて、頑張ってバグ出さないようコードを書きなさい！”と皆で叫んでも、それではあまりに原始的なやり方です・・・。この課題を何とか開発チーム全体として取り組めないか？と、ここまでが背景です。

そこででてきたのが、テストグループの立場からできるだけ客観的指標を開発チーム全体に出す事でした。

具体的にはある大きめの機能を実装する場合、幾つかの担当者毎の小グループに分けて、その機能終了に際してCriteria（基準）を満たしているかどうかをテスト担当者主導で行っています。

またテストグループとしては、常に定期的に作成される公式のビルド(*3)が大きく壊れていないかどうか定期的なレポート・メモも出していますし、特に上記のようなグループでの作業が終わった場合、そのコードを公式ビルドへチェックイン(*4)するため、影響の範囲をしっかりとチーム全体に伝えていく必要がでてきます。

「進むための判断材料・基準を掲示していく」

簡単ではありますが、少しはご理解頂けたでしょうか？

（Criteria（基準）を構成する項目に関しては、また別途書ければと・・）

InterConnect 開発チーム テスティング グループ マネージャ