InterConnect Blog : テストチーム

「評価デイ」とは

yoshiyuki.wada — Fri, 21 Jul 2006 16:17:00 GMT

今までテスト関係を投稿していただいたテストマネージャが独自にブログを立てるかもということで、これが最後の投稿になるかも！？

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

こんにちは。
テスティング担当です。

昨日InterConnect Team全体で「評価デイ」なるイベントを行いました。

これは今まで自分達が作ってきた製品が、本当にユーザさんにとって使えるものなのか/大きな欠陥はないか、実際の製品を皆で使って確かめあおう（自信を深めよう）という活動なのです。

実は過去数回このイベントを行ってきました。時に数日かけたり、あるいは一日で完結したり。今回は一日弱の短いものでしたが、行ったタイミングがもう製品完成間近なためか、製品仕様そのものに対して大きなインパクトのある提言よりも、現在の製品が抱える問題・不具合を解決するような指摘が多かったような気がします。

・・・と書きましたが、実は私の方から今回はできればバグ出し（問題の指摘）観点を中心に行ってくれるとうれしいと関連グループのマネージャ・リーダに伝えていたのです。（関係者の皆様、ありがとうございます）結果としてテストグループが見落としていた問題指摘もたくさんあり、とても助かりました。

テストグループで普段行っているのと違った観点からの指摘が行われるため、このイベントはとても役立つのです。

勿論製品仕様等への提言は、今回のバージョンで全て解決できないものがあったとしても、将来への計画・製品/サービス作りへの貴重な資産となります。

簡単ですが、製品出荷に向けて一歩一歩前進している状況をお知らせしました。

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

製品開発におけるテストの役割

yoshiyuki.wada — Fri, 14 Jul 2006 07:55:00 GMT

こんにちは。

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

本人も慣れてきたようなので私の補足はありません。

私はこの中では「仕様を決める部隊」に属していますので、その辺も投稿しなければと焦っています。

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

こんにちは。

またまたテスティング担当です。

前回は開発のJargon(仲間内言葉、専門語、わけの分からない言葉...)を幾つかちりばめながら書かせてもらいましたがいかがでしたでしょうか？基本的には開発知識等まったくない方でもわかる内容を心がけています。しかしこちらの文章力のなさから、理解不能に至らしめた場合・・　ごめんなさいです。（是非その旨コメントを）

今回は、InterConnect開発プロジェクト全体におけるテストの流れと役割（テストプロセス）について書かせて下さい。

一般的に開発プロジェクトは、仕様策定＞プログラミング＞テスト　といった流れがありますが、基本的にマイクロソフトのテストはその全てのフェーズにおいて仕様を決める部隊、そして実際にプログラミングする部隊と密に連携して作業を行っています。ですので、この流れの中でプログラミングが終わってから、さて仕様に添って動いているかなぁとテストを開始する訳ではないのです。

注意：勿論開発プロジェクトの規模・目的によって、開発そのもの・テストのやり方に違いがあるのは事実ですし、ここで書いているやり方が全ての開発プロジェクトに適用できるという趣旨ではありません。

さて仕様策定でのテストの役割とは何でしょうか？

それは作成途中の要求仕様が本当にユーザさんのニーズに添っているか、ニーズを満たしているか、足りない部分はないか、機能は作るけど、使い勝手が著しく悪い部分はないかといった、仕様を作り込む段階でのテストです。内部ではスペックレビュー、スペックインスペクションと呼ばれていて、正式なプロセスのひとつとして機能しています。

ではプログラミング段階のテストとは？

仕様に基づいて開発者が実際にプログラムを頑張って書いている段階では、こちらが直接作業に関わる事はありません。しかし、作業担当者のプログラミング作業が全て終わってからテストすると、結構色々問題が見つかる事があったりするのです。

例えば・・・

仕様に対する解釈が違っていて出来上がりが仕様と異なってしまう。

あるいは仕様そのものが書いてない場合（これ自体問題ですが、全てを厳密に100％網羅できない場合も実際あるわけで・・）、開発者が独自にプログラムを書いて実装するものの、その出来上がりが使いにくい・わかりにくい物になってしまう。

あるいは、厳しいスケジュール状況から仕様を全て満たすプログラムを書けず、結果として仕様の特定部分が抜け落ちてしまっている事が後日発覚・・など。

全てが開発者そのものに問題があるというわけではなくて、開発プロジェクト全体でフォローしないといけない課題も含んでいます。そこで考え出されたのが・・・　--> プログラミングの段階から仕様策定者・テスト担当者も一緒になって、評価をしていく。開発が全て終わっていないプログラムでも、ある程度機能が実装され・動くようになったら、テストをしていくといったやり方です。

実際はある大きめの機能毎に小さなグループを作り、そのグループは仕様策定者・プログラミング担当者・テスト担当者から構成されます。（それぞれの部隊から最低一人はそのグループに参加）そしてそのグループで仕様の討論をして、出来上がったプログラムの評価も一緒に行っていくのです。

実は・・・　本社も同様なやり方を導入していて、このグループ単位での開発はFeature Crew開発と呼ばれています。ですので、多少ネタあかし？をすると、本社のこのプロセスを我々InterConnect開発チームにも適用したといった次第。しかし、そうはいっても、開発人数の規模も内容も違うものをそのまま導入しても運用にコストがかかり、期待した結果を得られないこともあります。ですので、そのやり方は導入したものの、我々開発チームにより適した内容へカスタマイズしていったのも事実なのです。（ここを強く強調？）

前回テストアプローチとして「進むための判断材料・基準を掲示していく」というスローガンの下、具体的な指標Criteria（基準）を満たしているか、テスト主導で行っていると書かせてもらいました。そしてそのCriteriaが、上で紹介した機能の小グループの活動に対しても適用されます。

Criteriaの構成要素はそれぞれのグループ毎で違う物もありますが、下記は一般的項目として挙げる事ができます。

＋仕様を基に作成したチェックアイテム（テストケースのようなもの）がパスするか

＋仕様で規定されているキーシナリオ（主な使い方）がきちんと実行できるか

＋大きな課題は残っていないか（仕様の不整合や、解決されるべきバグが残ったままになっていないか）

簡単ではありますけど、テストの流れと役割を書かせもてもらいました。

次回はよりInterConnectに特化したテストの内容でも書かせてもらおうかな・・と思いますが、全然違う物となるかもしれませんので、その際はご容赦を。

テスト方針

yoshiyuki.wada — Fri, 07 Jul 2006 11:43:00 GMT

こんにちは。

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

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

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

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

皆さん、こんにちは。

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

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

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

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

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

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

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

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

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

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

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

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

*1 コード・・・プログラムのソースコード

*2 コーディング・・・プログラムを書くことです。

*3 ビルド・・・プログラムの塊を実行可能な形に変える作業。コンパイルとかもこの一作業。

*4 チェックイン・・・プログラムを管理しているサーバーに入れることです。変更を加えるためにはソースコードをチェックアウトして変更しチェックインする工程が必要です。公式なビルドはこのサーバーに入っているプログラムをベースに行われますので、変更を反映させるためには必ずチェックインしなければなりません。これらは複数の人が同時に作業するためと製品の品質を高めるために行います。

他にわかりにくい言葉があればお知らせください。追加で解説します。

テスティンググループマネージャより

yoshiyuki.wada — Mon, 03 Jul 2006 05:30:00 GMT

こんにちは。

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

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

皆さん、はじめまして。

一般的にいってソフトウェア開発におけるテストの捉え方は、下流工程・縁の下の力持ち・同じ事の繰り返し・創造性がない・できればあまりやりたくない？（自分で書いてて・・へこんできますが笑）的な物が大きいのかもしれません。

しかしMicrosoftにおけるテストの役割はとても強大で、製品計画・仕様策定の段階から関係者と一緒に切磋琢磨していくという文化が根付いております。最近は開発者と同程度のコーディングスキルを持つ必要性も従来以上に高まり、実際テスターの中でもオートメーション用のコードを書いている人もいます。勿論開発後半は前半・中盤以上に実際のテスティング作業を行い、たくさんの問題を発見・修正・確認しながら製品品質を向上させていきます。

現在は出荷に向けたまさに後半局面。テスター全員、関係者と一緒に頑張っている今日この頃です。

製品全体を俯瞰しながら個別の問題を同時に片付けていく、テスターとしてまさに一番やりがいを感じられる場面かもしれません。

不定期になるかもしれませんが、テストの観点から見たInterConnect開発像をお伝えできればと思います。

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

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

製品の品質向上のための話はなかなか外からは見えないので、今後どのような投稿になるのか楽しみです。

InterConnect Blog : テストチーム

「評価デイ」とは

製品開発におけるテストの役割

テスト方針

テスティング グループ マネージャより

テスティンググループマネージャより