9.3.2 242 93.3 第 9 章 Microsoft DeveIoper Division で得た教訓 スから引き継がれたバグを再検討する無駄な時間がなくなるだろうと考えたのです。 この考え方は、持ち越された作業を睨みながらリリースの計画を立てるという一般 的な方法とは正反対です。負債ゼロの状態から新しいリリース計画を始めるのです から、非常に健全です。 テストに関する目標は、すべてのテストを確実に成功させることでした。信頼で きないテストは除外し、二度と使用されないようにしました。つまり、テストの実行、 特にビルド検証テスト (BVT) の実行結果を手動で分析しなくても済むようにする ことを考えました。これまでは、偽陽性 (false positive) のテスト結果という問題 に悩まされていました。つまり、製品の障害のせいではなく、テスト実行の不備の せいで、テストの失敗が報告されるという問題です。そのため、長い時間かけてテ スト実行を手動で分析しなければ、正しい結果を導き出せませんでした。同じよう な経験をしたことがある人も多いと思います。テストの負債をなくすには、回復カ が高まるようにテストをリファクタリングすることと、テストツールとテストイン フラストラクチャを改善することが必要でした。これらの機能は、 VS 2010 のビル ド管理およびラボ管理の機能として一部製品化されています。 タイムボックスの短期化 同時に、スケジュールの組み立て方を見直し、 3 か月間のマイルストーンから 5 週間のスプリントへ移行しました ( 今では、 3 週間のスプリントを使用するところ まで改善されています ) 。それぞれのスプリント期間において、チームは完了基準 ( 詳 しくは後述 ) を満たす 1 つまたは複数のフィーチャー ( プロダクトバックログ項目 ) を提供するものと定められました。それぞれのスプリントの終わりの目標は、「顧客 技術プレビュー (Customer TechnicaI Preview : CTP) 」と呼ばれる、ソフトウェ 規模の多分野にわたるスクラムチームを作りました。通常、フィーチャークルーは チーム構成に関しては、「フィーチャークルー (feature crew) 」と呼ばれる、小 フィーチャークルー より、すべてのスプリントで品質を評価することができました。 でしたが、ドッグフーディングのために各 CTP を社内にデブロイしました。これに たのは、外部からのフィードバックを実際に収集する必要があった部分の CTP のみ アの潜在的に出荷可能なインクリメントを実現することでした。我々がリリースし 5 人または 6 人の開発者とテスト担当者および 1 人の「プログラムマネージャー」 ( す

9.2 ビジネスのバックグラウンド 237 あたっては、イノベーションを実現するため、そして具体的な制約、特に社内の従 来のシステムとの相互運用に対処するために、 TFS のプロセステンプレートをカス タマイズする必要がありました。また、 TFS の開発を進めるなかで、ソース管理、 バグ追跡、ビルド自動化、テストケース管理、テスト環境管理を行う 5 つの先行す る社内システムとの相互運用が必要になりました。これらの社内システムはすべて 自社製であり、 TFS とは関係なく、数十年にわたり個別に設計されてきたもので ビジネスのバックグラウンド どのような組織でも、ますはビジネスのコンテキストを知ることが重要です。 DevDiv はさまざまな Microsoft 製品ラインをサポートするツールとフレームワーク を提供しています。 DevDiv の製品の多くは無償であり、たとえば . NET Framework 、 lnternet Explorer の F12 開発者ツール、 VisuaI Studio Express など が無償で提供されています。これらの製品の目的は、利潤を追求することではなく、 コミュニティとユーザーが Windows 、 Windows Azure 、 Office 、 SQL Server 、お よびその他の Microsoft テクノロジをベースとするソフトウェアを簡単に開発でき るようにすることです。その他の VS 製品ラインや MSDN は商用の製品であり、 般的にはサプスクリプションによってライセンスが供与されます。 いくつかのビジネス目標がせめぎ合うことは珍しくありません。ーロにステーク ホルダーと言っても立場はさまざまであり、立場が異なれば、優先順位もそれぞれ 異なってきます。ある顧客層にとっては最上位の項目でも、他のグループでは気に も留められない、ということはよくあります。 私はこの状況を何年にもわたって顧客に説明してきましたが、その経験から実感 したのは、ビジネスの優先順位が競合するなかで、このようなせめぎ合いが生じる のはごく普通のことだという点です。どのビジネスにもそれぞれ独特の性質があり ますが、ある目標を他の目標よりも単純に優先することはできないという考え方は 共通です。そのため、さまざまなビジネス目標が掲げられることになり、ステーク ホルダー間での優先順位の競合が生まれます。 こうした優先順位を調整する最善の方法は、 1 人のプ スクラムの理念に従えば、 ロダクトオーナーを定め、共通のプロダクトバッグログを使用することです。この 3 社内で使用したプロセステンプレートは http://mpt.codeplex.com/ からダウンロードできる。ただし、 製品版のプロセステンプレートのほうがはるかに効率的であり、 VS 2010 のフィーチャーを利用しており、 社内の制約を受けすに済む。

8.3 活用できるテスト結果とバグレポート 211 テストの設定では、テストに関係するそれぞれのコンピューターロール上のテスト 工ージェントに対して、 テスト計画 2 : イデレーション 2 〇〇一侖ーテストセンター 内容ープロバティ どの DDA をオンにするかを指定できます。 計画 テスト トラック 新規作成マ 整理 多保罹して聞じるヨ 項目を聞く ( 1 ) 第 ステップ を ロール データと診断 詳第設定 △図 8-8 テスト環墳のロー . 転 : とに、取第するテータまたはシステムで実行するアクションを選択できます . ロール : サーバー @InteIIiTrace コンピュ - タ - のシステム情報を収集するために使用します ( クライアントロールまたはサーバーロ - ル狗け ). システム情報 イベントログデータをキャプチ ? するために使用します ( クライアントロールまたはサーバーロール向け ). ロイへントログ ます (web サーバーに対してクライアントになる任意のロールに対して使用します ). サーバーロールに対し [ い矼「を ] または [ テストの影を ] を道択する場合に、 web アプリケーションに対して使用し マ加Ⅲ Trace およびテストの影を用の ASP.. NET クライアントプロキシ アントロールまたはサーバーロール ) ・ 再現するのが困第なバグを分するのに役立つ、例外および物定の診断トレース情報を収集するために使用します ( クライ ピューターロールから収集するかを定義できる。 テストの設定では、自動テストおよび手動テストの最中にどのデータをどのコン テストを実行すると、 MTM の UI は幅の狭いパネルに折りたたまれ、画面の端に ドッキングされます ( 通常は、図 8-9 のようにテスト対象のアプリケーションが右 側に表示されます ) 。探索的テストの実施時も、テストの記録中も、以前に記録され たステップの再生中も、このレイアウトが使用されます。 手動テストでは、多くの場合、テスト担当者が毎回行う決まったステップがあり ます ( たとえば、テストの本題を開始する前に、アプリケーションをある決まった テスト担当者が再び引き継いで、テスト結果を確認することができます ( 図 8-9 を 録されている UI 操作を再生して、意味のあるステップまで早送りできます。その後、 状態にする必要がある場合など ) 。 MTM では、過去に実施したテストであれば、記 参具 ) 。

7.5 コ 新しい仮想・ : 物 p ⅲ En ⅵ「 0 れ me 飛 テスト環境へのデブロイメントの自動化 は保評して第じる効 187 ステップ 名第と場所 * コンビューター コンビュータ ロバティ △図 7-12 名鋼と一 ) 入力 説明 : この境は、次のチームプロジェクトホストグループに配置されます . そび、選択されたホストグループに仮想マシンがコビーされます . T ん、当 1 、漸に wd ーし奴ぎⅵ・ to ・ ~ “ s 1 ・ ( め 0 名第 、新しいタグ ( T ) メ 環第タグ すへてびスト 12 テスト環境は、実稼動環境を十分に再現するために必要な 1 つ以上の仮想マシン または物理マシンから構成される。 〇〇一侖のポセンター ステガ コ新しい仮想環第 s E " 加ー テストの設定 ライブラリ ロ」 ( : 0 0 第啾 コントローラー ノロー“題第 0 ) イ名前の変を ( R ) X は存して第じる日 1 朝 X 新規作第項目を簡 ( ( 1 ) ・ ; い、 , ダ - をここにド ) しそびにグルーはす . チ - ムプ 0 ジェりト・ 0 使用町能な仮マシンはを 0 第 、名前 厭定のロール、 D ・ 0 を確′ V 朝 m h す MSSCVMML'br•ry MSSCV 材ⅸ町 MS VMM し・ プ 0 ジェクトライプラリ共 : ( を D8 デ - タベ - スサ← ( 円を w W サト △図 7-13 この一知こ見つなら合は、仮想マシンをインポートし ( くだ & 、 現した自己完結的なイメージの中でテストを実行することができる。 ソフトウェア的に実現するオーバーヘッドの少ない方法であり、特定の構成を再 ションの構成が異なっていたりする可能性がある。仮想マシンは、テスト環境を サーバーなどのサポートコンポーネントのバージョンが異なっていたり、ソリュー ティングシステムが各国語にローカライズされていたり、データベースや Web ソリューションのターゲット環境は 1 種類だけとは限らない。たとえば、オペレー

174 第 7 章ビルドとテスト環境 「完了」の定義をチームで作成するときには、次の点に注意する必要があります。 ・定義の明確化ー 「完了」の定義を全員に対して透明にする。たとえば、チー ムのすべてのメンバーが見られるように壁に貼るなど。 ー一貫した品質ーすべてのプロダクトバックログ項目 (PBI) において、その PBI で定めた受け入れ基準に加え、「完了」の定義に含まれるすべての基準を 満たさなければならない。 ・見積もりにおける重要性一「完了」が意味するところと、それに必要なア クティビティを明確に理解することは、見積もりとスプリント計画の前提条 件である。また、もしも「完了」の定義がスプリント間で異なれば、測定さ れるべロシティ ( スプリント内で達成されるストーリーポイントの数 ) が不 正確になるため、意味がなくなるおそれがある。 ■企業の標準ー「完了」の定義はチームに属するものだが、組織の要件も反 映させてかまわない。 ■測定可能ー完了基準は測定可能でなければならない。つまり、チームのす べての開発者が、その完了基準を満たすために何が必要かについて同じよう に理解する必要がある。 ー自動化ースプリントの期間は通常 2 ~ 4 週間 ( 実稼動日数は 10 ~ 20 日、 ここからミーティング時間が引かれる ) であるため、完了基準の確認作業を できるだけ多く自動化するとよい。 「完了」の定義では、チームが各 PBI において到達すべき最低限の品質レベルを 設定します。そのレベルに達しなければ、 PBI は完了とならず、潜在的に出荷可能 とは見なされません。チームが「完了」の定義に真剣に取り組めば、技術的負債の 累積を防止でき、プロジェクトの初期に実装した機能でもリリース直前に実装した 機能でも、決められた一定の品質を顧客に提供することができます。「完了」の定義 には最低限の基準だけを定義することを覚えておいてください。ただし、必要性が ある場合や、より厳しい定義が PBI で求められている場合は、この限りではありま せん。 多くのチームに見られる典型的なアンチパターンの 1 つは、「完了」の定義が曖味 で、時間の余裕がない場合に開発者がいくらか手を抜いてもごまかせるようになっ ている、というものです。これはたとえば、「保守可能なコード」を作成しようとし ているのに、それが保守可能であるかどうかを判断する基準がないということです。 反対に、しつかりした「完了」の定義には、明確な目的 ( たとえば、この変更によっ

6.4 55 第 ( に C51 け E 、ゴぎ Wi ーまー M ー P Y ・ X プログラミングエラーの早期検出 147 全般 トリガー ワークスペース ビルドの既定値 アイテム保持丿シー プロセス △図 6-22 Team Foundation ビルドは Wndows W (XAML) 方イルで定義されているどルドプロセステンプレートを使用します。このテンプレート ( 丁 ] 作は、選析した テンプレートで提供されるビルドプロセス′行メーターを設定することでカスタマイズできます。 ビルドプロセステンプレト : 既定テンフレト ビルドプロセスパラメーター ( P ) 自助テスト 田ま . 詳編 国ソースおよびシンボルサーバーの定 コード分析の実行 ログの詳度 、ワーりスペースのグ丿ーン ビルド番号形式 国自テスト 日 2. 基本 田ビルドマる項目 きます。 MSTest を実行するテストアセンブリまたはテスト 詳総の表示 ( D ) Runt ョ、、に“市、“ t ( 衂・・じ tes ド . 聞′朝Ⅳ : 00 ・ & & U tTes 厭定のプララトフォ、 - ムと構成ぐ $ /cak:•心 t 。り第 3 / w に。 / w 社 3 紀ーをしドする 《 fR 市、 p ′れみ m 《窘 ! れ・Ⅵ辭 4 引《 : 、 実行するテスト ( れ 自テスト Run 5 5 地 5 matchng を第、・ st ・ . 引ー Category: Dady & & LintTests ÖK 追 1 A ) 編集 ( 鄰 ( R ) 上な第ス ( 川 下ハ勧 ( の キップ ビルド定義の中で、ビルド検証テストとして実行したいテストカテゴリを指定す る。 BVT 用のテストを指定する VisuaI Studio の BVT は、いくつかの通常テストを適切なテストカテゴリに登録し たものです。複数のテストを BVT 用のテストカテゴリとしてまとめておく必要があ ります。 詳細については、次の MSDN トピックを参照してください。 ■「方法 : テストカテゴリで自動テストをグループ化して実行する」 http://msdn.microsoft.com/ja-jp/library/dd286683.aspx ■「方法 : アプリケーションのビルド後にスケジュールされているテストを構成お よび実行する」 http://msdn.microsoft.com/ja-jp/library/ms182465.aspx

132 第 6 章開発 チェックインポリシーの追加 チェックインポリシー ( C ) : C 「 eset comments PO ⅱ・ Custom path ⅱ Forb1dden Pa はー 0 ・ Work ltem にⅣー 0 ・ コード分析 テストボリシー 作第項目 説明 て、前回のヒルドが成功している必要がありますを このポリシーでは、関連するそれぞれの覊統的インテグレーションヒルト定義につい △図 6-7 0 キャンセル チェックインポリシーによって、チェックインが特定の規則を満たしているかど うかや、チェックイン時に特定の操作を行ったかどうかを確認できる。チームプ ロジェクトごとに組み合わせの異なるポリシーを適用することが可能。 チェックインポリシー com/b/jimlamb/archive/2010/03/31/how-t0-implement-package-and-deploy-custom- 独自のチェックインポリシーを作成する方法の詳細については、 http://blogs.msdn. Server 2010 』 (Wrox, 201D を一読されることをお勧めします。 Blankenship 、 Woodward 、 Holliday 、 Keller の共著 TProfessional Team Foundation チームプロジェクトに適したポリシーを設定する方法の詳細については、 aspx を参照してください。 リシーのリストについては、 http://www.teamsystempro.com/go/checkinpolicies. Studio コミュニティがオンラインで提供しているポリシーもあります。このようなポ インストールすると、さらに 4 つのポリシーが追加されます。この他に、 Visual T FS は 4 つのチェックインポリシーを標準装備しています。 TFS Power T001S を check-in-p01icy-for-tfs-2010. aspx のプログ記事を参照してください。 サーバー上で完了の定義を適用するゲートチェックイン トが作成されます。工ラーが見つかった場合は、変更はコミットされず、変更を加 6-8 を参照 ) 。検証ビルドが成功した場合は、変更を加えたユーザーの名前で変更セッ ルプセットとしてパッケージ化され、ビルドサーバーに送られて検証されます ( 図 加えたコードはすぐにはバージョン管理システムにコミットされません。まずシェ を自動で実行するオプションがあります。ゲートチェックインビルドでは、変更を lntegration : (I) 」や「ゲートチェックイン (gated check-in) 」と呼ばれるビルド VisuaI Studio には、チェックイン時に「継続的インテグレーション (Continuous な問題が生じないことを確認するために、ビルドサーバー上でビルドを行います。 規則をより厳密に適用するには、コード変更によってピルドや自動テストに新た

2.3.6 32 第 2 章スクラム、アジャイルプラクティスと VisuaI Studio 継続的インテグレーションは、ビルドの中断 ( ビルドプレーク ) がめったに起こ らない場合には、非常に優れたプラクティスです。これにより、正しく動作するクリー ンなコードをいつでも保つことができます。ただし、プロジェクトの規模が大きく なると、ビルドの中断が発生する頻度が高くなります。たとえば、 100 人のコント リビューターがかかわっているソースペースを想像してください。彼らの全員が非 凡な開発者で、平均して 3 か月に 1 回しかビルドの中断を引き起こさないと考えた としても、継続的インテグレーションを行った場合は、毎日のようにビルドの中断 が発生するでしよう。 ビルドの中断が頻繁に起こるのを防ぐために、 TFS では継続的インテグレーショ ンの一種である「ゲートチェックイン (gated check-in) 」を採用しています。ゲー トチェックインは継続的インテグレーションワークフローを拡張したもので、サー バーをプロビジョニングし、チェックインの前にチームビルドを実行します。ピル ド全体がパスした場合にのみ、サーバーはコードをチェックイン済みとして受け入 れます。そうでない場合、チェックインはエラーの詳細を示す警告と共にシェルプ セットとして開発者に戻されます。「第 9 章 Microsoft Devel 叩 er Division で得た 教訓」では、この機能が Microsoft でどのように使われているかを紹介します。 さらに、 TFS は継続的インテグレーションまたはゲートチェックインのサーバー メカニズムに先立って「チェックインポリシー (check-in policy) 」を実行します。 これは開発者に対して最も早い段階で迅速に提供される自動化された警告です。 れにより、単体テストとコード分析がローカル環境で実行されているか、作業項目 が関連付けられているか、チェックインメモが完了しているか、その他の「完了」 基準が満たされているかを、コードが継続的インテグレーションまたはゲートチェッ クインのサーバーに送られる前に検証できます。 テストサイクル 完了した PBI はテストしてバグ修正を行う必要があります。一般に、チームメン バーは PBI を完了する前にコードを小さなインクリメントで何度もチェックインし ます。しかし、 PBI が完了したら、次はテストサイクルが始まります。しかも、た いていの場合は多数の PBI とバグ修正が立て続けに完了するので、それらを 1 つの テストサイクルにまとめることができます。そのため、テストサイクルを処理する 単純な方法の 1 つは、テストサイクルを毎日行うことです。 TFS は複数のチームビルド定義をサポートしているので、継続的インテグレー ションまたはゲートチェックインビルドに加えて、ディリービルドを行うのが好ま

1.6 例 綻させ、予想外の遅れやコスト増、あるいは後からのキャンセルを引き起こす可能 性があります。また前述した金融上の負債と同じように、技術的負債も手遅れの状 態になって初めて公表されたり、詳細が明らかになったりすることが多いのです。 技術的負債に伴う問題の 1 つは、実際にどんなソフトウェアが潜在的に出荷可能 な状態になっているのかをステークホルダーが確認できないということです。この 問題を解消するために、スクラムでは、すべてのプロダクトバックログ項目はチー ムで合意した「完了 (done) 」の定義に従ってデリバリーされなければならないと 定めています。これについては、「第 2 章スクラム、アジャイルプラクティスと VisuaI studio 」で詳しく説明します。このような透明性は、 Louis Brandeis の言う「電 灯」のようなものです。電灯があれば警察官の必要性は減少するのです。「完了」に 関する共通の定義と進捗状況の透明性が確保されていれば、技術的負債の累積は避 けられ、チームとそのステークホルダーがチームの真のべロシティ (velocity) を評 価できるようになります。 テスト用の新しいビルドを用意するために費やす労力を考えてみてください。あ るいは、修正済みと報告されたバグを後で再アクテイプ化しなければならない場合 の作業コストについて考えてください。もしくは、最終的に削除されるであろう要 件の仕様を書くことを考えてみてください。これらの無駄はいすれもソフトウェア プロジェクトでよく見られるものです。 VisualStudi02010 は、ソフトウェア開発プロセスにおける無駄の源を減らすこと に力を注いできました。 VisuaI studio Team Foundation Server (TFS) のビルド 自動化の機能を使用すると、継続的または定期的にビルドを実行でき、また「ゲー トチェックイン」の機能によって、変更されたコードを受け入れる前に強制的にビ ルドを実行することもできます。 Lab Management では、それらのピルドを仮想化 されたテスト環境に自動的に直接デブロイできます。これらについては、「第 7 章 ビルドとテスト環境」で説明します。 悪名高い無駄の一例として「バグピンポン (Bug Ping-Pong) 」があります。テス ト担当者やプロダクトオーナーならば、頑張ってバグを登録したのに、プログラマー からの返事は「再現できない」という言葉だけ という経験を何度もしたことが あるはすです。この「再現できない」という返事には、他にも「もっと情報が必要」 や「私のマシンでは問題ない」など、さまざまなバリエーションがあります。通常、

第 8 章テスト 8 ユ 1 ー出力結果の見方 ロードテストの実行中および完了後は、 2 種類のデータカウンターに注目する必 要があります ( 図 & 22 を参照 ) 。「 Avg. Page Time 」の項目は、 1 ページのロードを 終えるまでのエンドッーエンドの応答時間を示します。この値はユーザーが体験す るとおりの応答時間です。したがってこの値により、応答時間が許容できる範囲内 にあるかどうかを判断できます。また、テストの実行中は、選択したサーバーから 関係のあるすべてのパフォーマンスデータが収集されます。これらのパフォーマン スカウンターは、実行中のシステムのどこにポトルネックがあるのかを判断するの に役立ちます。 Visual Studio では、アプリケーションの種類に応じて既定のしきい 値が設定され、レベルを超えると警告やエラーが発行されます。 226 当をコ彑ヨ・い紙い第環目・ - ) ふ , 、ロ [ 5 は 5 ] 、 カつンタ - 全般 ・ヨシナリオ ・テスト 画」トランザクシ・ン 日ヨペ - ジ ・ .:d を準 1 第物 ・ページ ・ Avg ・ ( 侊・“ー w T 第テストのンスナム 日」シナリオー ・ tsR げ当 ヨ A .11r を 、ページ 第コンピューター 、工ラー 既物ート OÄ、ロー朝ー・、こレーヾ」ヾ IO 製 7 ローー第、プ代いー X マ第いー 0 2 ・ントロ - ラ - およ 0 工 - ジみント インスタンス カデゴリ コンピューター ミノ A 0 1 第第 ッページ庵 ノ V9. 物ー -1 ・ い田テストー - 出テスト下のツステム : ・ツコント 0 ーラーおよび工ラエント 0. 0 0 0 第チスト物第・出力 このグラフには 2 種類のデータが一緒に示されている。「 Avg. PageTime 」は、ユー ザーが経験するとおりのページロード時間である。「 Requests/Sec 」は、テスト 対象のサーバーの測定値の 1 つであり、減速の原因を示す。左側のカウンターツ リーに、問題を示す警告とエラーのアイコンが表示されていることに注意してほ しい。このようなアイコンの中には、サーバー設定でチューニングできる構成の 問題を示しているものもあれば、コードの修正を必要とするアプリケーションエ ラーを示しているものもある。 △図 8-22