( 18 ) はじめに ビルドのセットアップ待ちをなくす。多くの開発チームは、ソフトウェアの定期 的なビルドを 1 日に何度も作成するという継続的インテグレーションのプラクティ スを実践するようになっています。特に高度に分散された Web べースシステムでこ のプラクティスを実践するケースが見られます。しかしそれにもかかわらず、テス ト担当者はこれまでと同じように、テスト用の新しいビルドを入手するまでに何日 も待たなくてはならないのが実情です。なぜなら、ビルドを実稼動環境に近いテス ト環境にデブロイするには非常に手間がかかるからです。 VisuaI Studio 2010 では、 テスト環境を仮想化し、テスト環境にデブロイするまでをビルドの一部として自動 化することによって、テスト担当者が新しいビルドを毎日 ( あるいは 1 日に何度も ) 継続的に入手できるようにします。「第 7 章ビルドとテスト環境」では、ビルドと テスト環境の自動化について解説します。 の退化をなくす。最も効果的なユーザーインターフェイス (UI) テストは、た いていの場合、探索的で、決まった筋書きのない手動のテストです。しかし問題は、 バグを修正しても、それが実際に修正されたのか、単にもう一度見つけることがで きなかっただけなのかの判断が難しいことです。 VisualStudi02010 では、テスト担 当者による探索アクションのログを作成し、それを自動テストに変換することによっ て、このあいまいさを排除します。それにより、修正箇所を確実に再テストするこ とができ、推測ではなく実際に発見されたバグの箇所を自動テストで確認できます。 「第 8 章テスト」では、探索的テストと自動テストを取り上げます。 パフォーマンスの退化をなくす。動作の遅いアプリケーションや Web サイトを提 供すれば簡単に顧客はいなくなる、ということはほとんどのチームが知っています。 しかし、多くのチームはパフォーマンス要件を数値化する方法を知らないため、リ リース間際まで負荷テストを行わす、問題が見つかっても既に手遅れであるという ケースが見られます。 VisuaI Studio 2010 では、負荷テストを早い段階で開始するこ とができます。パフォーマンスを事前に数値化する必要はありません。テストを実 行すれば、「何に時間がかかっているのか」というシンプルな質問の回答が得られる からです。そしてその徹底的なテスト結果から、 VisuaI Studio がコード内のホット パスをプロファイリングし、問題のあるスポットを直接開発者に教えてくれます。 第 6 章と第 8 章では、プロファイリングと負荷テストについて解説します。 変更の見落としをなくす。ソフトウェアプロジェクトには多くの変動部分があり、 その変動は反復の回数が増すにつれて大きくなります。開発者やテスト担当者が要 件を理解し損ねたり、変更による影響を見過ごしたりすることは少なくありません。 これを防ぐために、 VisuaI Studio Test ProfessionaI はテストの影響を分析する機能 を導入しています。この機能では、 2 つのビルドの間で行われた変更を比較し、ど

1.5 スクラム 9 1.5.2 スを経ないうちは、そのサイトは不完全であり、実際に出荷することも、公式にデ プロイすることもできません。しかし、カタログ検索の機能が使用できて、製品デー タベース、ビジネスロジック、およびページ表示を使用できるならば、それは「潜 在的に出荷可能 (potentiallyshippable) 」なインクリメントであると言えるでしよう。 これにより、ステークホルダーとチームの両方がスプリントの結果を評価し、フィー ドバックを提供し、次のスプリントに進む前に変更を促すことができます。また、 これらの変更に基づいて、プロダクトオーナーはプロダクトバックログを調整でき、 チームは内部プロセスを調整できます。 ソフトウェアの価値フローの向上 アジャイルコンセンサスの中心にあるのが「フロー ( flow ) 」の重視です。顧客価 値フローは、納品システムの主な測定基準になるものです。この考え方について、 Schwaber and Sutherland, 立 r Ⅲ〃 . ・ D に怩あ〃に d and & パⅲに d. 【邦訳】「アジャイルソフトウェアマネジメント』宗雅彦、前田卓雄訳 ( 日刊工業新聞社、 2 開 6 年 ) お″、ⅲ肥 R 〃 / な (Upper SaddIe River, NJ: Prentice Hall, 2 開 4 ) , 77. David J. Anderson, Agile Mat Ⅲ g に〃肥厩ル r software Engineering. ・ Applying に 7 方ど 00 , 可 co 〃 ra ⅲな r することで、成果物の顧客価値フローに関するコミュニケーションを促進していま 法に従い、 VisuaIStudi02010 では、いつでも見られるプロダクトバックログを提供 プロダクトバックログは、価値フローの測定基準になるものです。スクラムの手 詳しく説明します。 ます。プロダクトバックログについては、「第 3 章プロダクトオーナーシップ」で 随時保守します。プロダクトバックログには、目標とする顧客価値の定義が含まれ であり、プロダクトオーナーはステークホルダーのニーズに基づいてこのリストを ゆるものの優先順位付きリスト」のことです。・これは要件のスタック順位リスト れています。プロダクトバックログとは、「その製品で必要になるかもしれないあら スクラムでは「プロダクトバックログ (product backlog) 」という概念を取り入 なく、達成できた価値を単位とします。 このパラダイムでは、計画した各タスクの完了を主な進捗評価基準とするのでは 動し続け、処理能力が着実に達成されていく。・ 客価値となる機能は、稼働コードのデリバリーを経ながら各変化段階を通して変 フローとは、システム全体を通して価値が常に変動していることを意味する。顧 うに述べています。 David J. Anderson は『 AgiIe Management for Software Engineering 』で以下のよ

8.3 活用できるテスト結果とバグレポート ■テスト対象システムの構成情報。 己録された UI 操作の一覧 ( テストファイルと HTML ファイル ) 。 実行中のアプリケーションの IntelliTrace ログ (IntelliTrace の詳細について ■ は、「第 6 章開発」を参照 ) 。 ■ ( 仮想化 ) テスト環境のスナップショット ( テスト環境と環境管理の詳細につ いては、「第 7 章ビルドとテスト環境」を参照 ) 。 この形式のバグレポートは、テスト担当者の仕事を根本から変化させます。テス ト担当者はテストに専念すればよく、バグ報告に神経を使う必要はなくなります。 バグレポートは Visual Studio が作成してくれるので、「どうしたら良いバグレポー トを作れるか」という議論に幕を引くことができます。テスト担当者の作業は、バ グ報告の見出しを付けることだけです。 詳システム情事引テストケースーすべてル引添付方イ ) 引 再現させるステガ ( の 。 B 必さ / , 三に三を牽を U いせ 3 / ー町 20 ー 0 ま 32 : V 紀に 0 ま、 C1ick model AÉ懿肥、 [ 翫 kF0 市 [ 研にー er CBckAddtoC&t ( h ・ quantRy を 0 WQ•地 y [ 厳 konwt に、 p “にⅲ w 曲、資に [ : k 肥 XtorernoveRernfrMncart ( 、に ow 、曾 213 一三ロ 、 2 ここにコメントを入力します。 ー白ー 0 / 22 / 20 ー 0 ーー 3 : 304 、 1 国変更点の表示のンり ) 。日 3 ハ町加ま OAM 国変更点の表示 ( フィールドリンク 3 3 ハ町加ま飄 6 応 M 国変更点の表示 ( フィールド . リンり も 3 ハ町加加 & : 田変更点の表〒 ( フィールド . リンク 一日 3 ハ町加 10 ま 23 3AM 田変更点の表示 ( フィールドリンり 日 3 / / 加加ま 23 : AM 田変更点の表示 ( フィールドリンク TestconfWation: W ヤ橋 7 圧 8 3 3 ・ 80 山 ( 0 破・ Ad ・は物・ ln T 「・ 、 oR ・ TC 引・介 テストケースから収集されたバグの詳細データにより、テストステップ、タイム スタンプ付きのビデオ記録、操作ログ、サーバーからのⅲ te Ⅲ T 「 ace ログ、システ ム構成情報などを確認できる。また、必要に応じて、仮想化テスト環境のスナッ プショットを取得することもできる。 △図 8-10

218 第 8 章テスト 3. 可能ならシナリオテストを自動化します。ただし、保守の必要があることを 頭に入れておきます。 4. ロードテストを自動化します。ただし、こちらも保守の必要があります。 ます。 5. 誤った自信を持たないように探索的テストを実施し、テストの多様性を保ち さらに確実性を求めるならば、次のようにします。 テストシナリオの自動化 ることができます。共有ステップは積極的に活用しましよう。 さいコンポーネントを作成し、ログインなどのよく繰り返されるタスクを記録させ ネント化できるという利点があります。 MTM では、「共有ステップ」と呼ばれる小 シナリオが変わったときに作り直すのも簡単です。保守に関しても、簡単にコンポー ば、コード化された UI テストは便利な方法です。 UI テストは簡単に作成できるので、 しかし、 UI を変えるつもりがなく、回帰テストと構成テストを行いたいのであれ テストを自動化するのは時期尚早でしよう。 トも変更する必要があります。したがって、 UI がまだ確定していない場合は、 UI め、他のソフトウェアと同様に保守が必要です。 UI が変更された場合は、 UI テス 自動化されたソフトウェアテストは、それ自体が基本的にソフトウェアであるた 行した手動テストの操作記録を変換して自動化することもできます。 Studio を使用して、コード化された UI テストを最初から記録することも、以前実 クリックやキーストロークなどの操作を自動的に再現します。開発者は Visual リケーションや Web べースのアプリケーションに対して、本来ならユーザーが行う た UI テスト」です ( 図 8-13 を参照 ) 。コード化された UI テストは、 Windows アプ Visual Studio でシナリオテストを自動化するための主な方法は、「コード化され

6.6 バージョンのすれの防止 165 v 「»nl 分岐階層 △図 6-40 分岐の階層構造全体を図で表すと、分岐の相互関係を理解しやすい。この関係は、 ソース管理のフォルダー構造と合致していなくてもかまわない。 6.6.4 複数の分岐に該当する変更のマージと追跡 変史セットのトラッキンり ことです。 その作業項目自体を同じビューで追跡し、作業項目を使用してマージを実行できる ザーストーリーやタスクなどの作業項目に変更セットが関連付けられている場合に、 セットを追跡 ( トラッキング ) します ( 図 6-41 と図 6-42 を参照 ) 。便利なのは、ユー するときには、分岐の階層構造を示すビューかタイムラインピューでそれらの変更 更をコピーする操作のことを「マージ」といいます。 Visual Studio で変更をマージ TFS での変更の追跡は変更セット単位で行われます。ある分岐から別の分岐に変 △図 6-41 変更セットの追跡 ( トラッキング ) 。変更 ( 具体的には変更セット 39 ) が「 Version 1 」分岐にチェックインされたが、他の 2 つの分岐にはマージされていない。 変更セットのトラッキング x : 朝 0 再実徹匐タイムョンのトラ , キング ( げ - 階層の ? ング、↓ : 夛」ユ 1 = . や : マージ ( M ) 41 V に ionl 14A 叩 14.08.20111 1 去 26 2011 変史セット 39 のトラッキンり V に池 △図 6-42 変史セ外引 以下によりコミットされました TFS 、健 作成日 . 14.08. 加 1119 : 1226 コメント : MERGE f 「 omV 5i0n1 DEV イムラインビューで表示。 変更セット 39 から DEV 分岐へのマージ ( 変更セット 41 としてコミット ) をタ

6.3 コードベースの完全性の維持 133 えたユーザーにシェルプセットとして返され、調査と修正が求められます ( 図 6-9 を参照 ) 。 ェッツノ ' 変更が正常にヒルドされた場合は、自動的にチェックインされます . イいオプションの表示 ヒルド定義 ( D ) : Wi - Ma 0 ( ( 砒山 ) シェノレプセット : 朝 t - 却 11- 図 -03- 547.05 変更がシェルプされました . 次のようにヒルトされます : あります ぎ 1 ようにするには、変更をビルドして検証する必要が Team Foundation 艶Ⅳ e 「に変更をコミットできる △図 6-8 ゲートチェックインを有効にしている場合は、チェックインした変更はまずシェ ルプセットに格納され、ビルドサーバーが検証を行う。通常の手順に従って正常 にビルドできた場合は、バージョン管理リポジトリにコミットされる。ビルドが 失敗した場合はコミットされない。 蕈 グートチェックインが拒されました n 朝 Main CI 却 11 鬨 03 ユー斐敗 TFS\neno によって 2012 / 02 / 13 14 : 11 : 03 に送信されました 問題を修正するために変更をアンシェルプできます第 さらに、 △図 6-9 アンシェルプ ... 検証ビルドの結果、チェックインが拒否された場合でも、不備のあった変更をバー ジョン管理システムから簡単にアンシェルプして開くことができる。修正を加え て検証し直し、再度コミットすればよい。 ビルドチェックインポリシーを定義することで、ゲートチェックインが 成功するまでの間に別の開発者がコードをチェックインするのを防ぐこともできま す。この場合、チームメンバーには、ビルドの失敗を伝える警告メッセージが表示 されます ( 図 6-10 を参照 ) 。

6.4 プログラミングエラーの早期検出 テスト影響分析 : 重要度の高いテストから実行 143 アプリケーションのコードベースやデータベース構造に加えた変更は、常に副作 用のリスクと隣り合わせです。現代のソフトウェアはきわめて複雑なので、アプリ ケーションの一部に変更を加えると、どこか別の部分の動作が変わってしまうおそ れがあります。できれば、このような影響はすぐに発見したいものです。 Visual Studio には、コードの変更内容に問題がないかどうかをチェックインの前 に検証できる機能があります。 Visual Studio は現在のビルドとべースラインのビル ド ( 最後に成功したビルド ) とを比較し、コードが変更されたメソッドの一覧を [ テ スト影響ビュー ] ウインドウに表示します。さらに、一連のメソッドとそれまでのコー ドカバレッジに基づいて、変更されたメソッドを呼び出すテストやその依存関係を 特定し、実行すべきテストを提示します ( 図 6-18 を参照 ) 。 [ 影響を受けたテスト ] の一覧には、使用可能な単体テストとテストケースが表示されます ( サーバー上の テスト影響データについては、第 8 章で説明します ) 。 D 山 L “ ( 5 x W ⅲ ( alc. 03 いい y に「 三 u51n9 system; VAdd(int 3 , int b) 寺 テスト影ヒュー ① 1 働のテストが影をを受けました云辷のⅱ using system. collections. Generic; enamespace WinCalc using system. Text; using system. Linq; 影響を受けたテスト : テスト名△ プロジェクト 日影響を受けたテスト ( 1 項目 ) AddTest 名前△ コードの変更 TestP 回に public ( 1a55 DataLayer public int Add(int a, return a ー b; int b) 18 % テスト結第 ①テストの実行は道行中です結異 : 成切 0 / 1 : 道択された項目 : 1 プロジェクト テスト名 AddTest 工ラーメッセージ As 代 . A Eq リ引信 i 厄 d. Expected: 40 》 . A ・ ~ 0 失敗しました ■出力工ラー一覧 △図 6-18 自コードメトリッりスの経果・コードカバレッラの果婦 = 呼ひ出し階層 : コテスト経果 日変更されたメソッド ( 1 項目 ) 0 Add0n い nt) 第ソリューチームエ第テストヒ・ テスト髟を [ テスト影響ビュー ] ウインドウでは、ソースコードに加えたすべての変更と、そ れらの変更の影響を受けた自動テストを確認できる。これにより、使用可能なす べてのテストの中から、影響を受けたテストのみを実行できる。

180 第 7 章ビルドとテスト環境 ビルドレポートにより、ビルドの実行を監視し、完了したビルドの詳細と、作業 WI . e - 25 プロックがカバー済み、 113 プ 0 ックが未加←です 第し第 ) バイナリがインストルメント化塾れました - すべてのコードプロックカバレッジの 18 % 成功したテスト 6 / 6 、夫散 0 、結梁不確定 0 テスト東の表示 , 1 回のテス砌実行が完了 - 平月成功率 1 % ( 総合成防率 18 % ) S/Calculator/Main/src ′ WnCalc.sln- 0 工ラー、 0 を告、ログファイ几 ) 表示 マ 1 プロジェクト / ソリューションがコン ( イルされました 工ラー 0 、告 0 概要 26 移前に最終更新されたヒルト 最新のアクティビティ を、、 115 秒 ( H22BU D ・コントローラー ) に対して実行し、 118 移前に完了しました 飛 no により %nCalc-Main-Q(CaIcuIator) が変更セット 1829 に対してトリガ - されました 欟要の表示ーログの表示ー格納フォルダーを聞く一無期限に尿持ーヒルドの削除 朝 Winca に一 Main 工し 20110710.2 - ビルドが成功しましたー初期テストの準備完了 ヒノレト WtnC lc - Main -0 ー加 1107102 X を関係者に知らせることができます。 静的コード分析の結果が含まれます。このレポートに基づいて、 には、 BVT の結果と BVT のコードカバレッジが表示されます。ビルドの警告には、 項目の変更状況 ( ビルドに何が加えられたか ) を確認できます。テスト結果の詳細 ビルド品質の状態 影響を受けたテストはありません 影きを受けたテスト 現をの状をは物解決済み " てす , 現在は N LQ にり当 ( られています バグ 533 、サプフ b カクトのコード加 ( ラが有効になっていません 関連付けられた作業項目 変されたコートカバレッシ設定 変更セラト 1829. no によるチりイン 関連付けられた変更セット △図 7-6 ビルドレポートは、 細情報を集計する。 ビルドの実行をリアルタイムで監視し、完了時にビルドの詳 関連付けられた変更セットと作業項目のリストは、同じビルド定義を使って生成 された最新のビルドと前回成功したビルドとの差に基づいて判断されます。したがっ て、ディリービルドの場合は前回のディリービルド以降に組み込まれたすべてのコー ド変更と作業項目が表示され、リリースビルドの場合は前回のリリース以降にチェッ クインされたすべての変更が表示されます。 ビルドレポートから、関連付けられた変更セット、コード分析の警告、およびテ スト結果に直接ジャンプすることができます。ビルドレポートに表示されるデータ はメトリクスウェアハウスに直接供給され、プロジェクトの履歴データとして記録 されます。

6.4 プログラミングエラーの早期検出 手動コードレビュー すことができ、開発者は完全に準備ができたときにのみ、ビルドのためにコードを レビュー担当者はシェルプセット内のコードに関する提案とコメントを開発者に返 にレビュー担当者と共有できるようになっています ( 図 6-26 を参照 ) 。これに対し、 の変更をシェルプ (shelve) し、チェックインに先立って、それらの変更を非公式 手動でのコードレビューを容易にするために、 Visual studio では開発者がコード チェックインします。コードレビューに関連するワークフローの強化については、「第 10 章継続的フィードバック」を参照してください。 ソースファる区 F ) コメント (M): BuSlness に a シェルプセット名 ( H ) : シェルプ - ソースファイル - ワークスペース : ALSTERSCHWAN 」コ員・しの可フ チェックイン メモ ( N ) 作業項目 ( w ) Busin 引 09 ( h 96 名前 団ゆⅸ血飜「un ・ testrunconfig マト幻 nkA ( ( ount. ( を マト当 BankAccountTest. (5 変更 に d に d 代 団保留中の変更をローカルに保存するⅣ ) ロシェルプする前に、ポリシーおよびチェックインメモを評価 ( E ) フォルダー D: \ TF 馭 D に mo VST VSDE れ ( od に ( き 9 に キ ? ンセル D: \ TF D に E05 Ⅳ ST VSDE い Cod 曾 09 臥 T 当 tP 「 oj “Ⅱ D: 、 TF D を mos 、 VST い DE Ⅵ ( od を ( ag Cod に ( “ 09 に △図 6-26 バージョン管理データベースのシェルプセットは、後でチェックインできるかど うかわからない変更セットを一時的に保存しておく場所である。シェルプセット の目的の 1 つは、チェックインに先立って新しいソースコードをレビュー担当者 が利用できるようにすることである。 シェルプセットを使用したコードレビューやコミットされていない変更を 取り扱う VisuaI Studio でのシェルプセット作成方法と使用方法を理解するには、 MSDN ト ピック「シェルプセットの操作」 (http: 〃msdn.microsoft.com/ja-jp/library/ms181403. aspx) を参照してください。

23 プロセスサイクルと TFS 23 場合は、スクラムマスター同士が連携して、スクラムオプスクラム (Scrum of Scrum) を作ります。 1 人のプロダクトオーナーが複数のスクラムチームに関与す ることはできますが、プロダクトオーナーがスクラムマスターを兼務してはなりま せん。 多くの場合、チームの自己組織的な運営を信頼せすに、ツールを使用してアクセ ス許可を強制的に適用するのは悪いスクラムです。一般的には、「責任は割り当てら れるものではなく、受け入れられるだけ」・という原則に従い、信頼して任せるのが 好ましい態度です。 TFS は作業項目に対するすべての変更の履歴を常に記録してい るので、予期しない変更が行われても、それを追跡してエラーを取り除くことが簡 単にできます。 とはいえ、やはりアクセス許可が ( たとえば、規制や契約上の要請から ) 重要に なることもあります。そのため、次の 4 つの方法を使用して、チームプロジェクト 4. ビルド、レポート、およびチームサイト別 ルダーおよび分岐階層によって制御可能 ) 3. システムのコンポーネント別 ( 作業項目の区分パス階層や、ソース管理のフォ 2. 作業項目の種類別 ( フィールドや値まで細かく制御可能 ) 1 . ロール別 内でアクセス許可を強制的に適用することができます。 会社テクノロジックアート訳 ( ピアソン・エデュケーション、 2 開 5 年 ) 【邦訳】Ⅸ P ェクストリーム・プログラミング入門第 2 版一変化を受け入れる」長瀬嘉秀監訳、株式 (Boston: Addison-Wesley, 2 開 5 ) , 34. ・ Kent Beck with Cynthia Andres, E. 尾川 e Programming E 挈ⅲに d. ・ Embrace C ん住れ g に , 立 co 〃 d E 市行 0 れ 速なイテレーションによって、チームは不確実性を小さくし、実践を通じて学び、 プロセス制御におけるイテレーション ( 反復 ) の原則を重視します。なぜなら、迅 (iterative and incremental development) 」という概念です。スクラムでは、実証的 第 1 章で説明した収斂的進化の中核を成すのは、「インクリメンタルな反復型開発 プロセスサイクルと TFS ルを設定できます。実際には、これが行われることはめったにありません。 業項目の種類に対して、「 PBI を更新できるのはプロダクトオーナーだけ」というルー たとえば、プロダクトバックログ項目 (ProductBacklogItem:PBI) という作