5アジャイルチームが生み出すソフトウェアの品質は、チーム全体で責任を持ちます。アジャイルテスターはチームの一員として、製品の品質を高めることに寄与します。普及したアジャイル・チーム・マネジメントの枠組みスクラムはアジャイルのチームマネジメントのフレームワークとして、現在、最も普及している手法です。90年代前半に、ジェフ・サザーランドとケン・シュウェイバーによって作られ、96年に発表されました。この両名もアジャイルマニフェストの策定に参加しています。その結果、様々な分野/プロダクトで利用可能な汎用性を持っています。これはホンダやキャノン、富士ゼロックスの新製品開発の事例を研究したものです。従来の開発工程をフェーズ毎に明確に区切るプロセスに対し、開発工程をオーバーラップさせ、全体を1チームとして作業を進める過程を採用していました。竹内と野中は論文中でその過程をラグビーの「スクラム」と表現しました。配布資料(1)3つの原則スクラムはエンピリカル(経験主義)に基づくマネジメント手法です。机上の予測だけに頼らず、できる限り実際の作業や成果物を用いて、意見を聞き、仮説を修正します。できる限り頻繁にリリースとデモを行います。徐々にチームとして知識を獲得し、予測可能性を上げ、現実的なリスクマネジメントのノウハウを獲得していきます。プロセスおよび成果物に問題があると判断された場合は対策を行う一般的には以下のような制約を利用します。(話は聞くが、メンバーが判断を行う)(2)4つのミーティングスクラムでは、スプリント内で行う4つのミーティングを定義しています。2週間のスプリントの場合、以下のような時間を割り当てます。配布資料(3)3つのロールスクラムではチームが主体ですが、チームを支援する2つのロールを定義しています。スクラムの主体となる自己管理されたチーム。理想的にはプロダクトを作るのに必要な全ての能力を備えている。チームが生み出すプロダクトの方向性を決定する役割。プロダクトバックログを適切にメンテナンスする責任を持つ。不確実な将来に対し、投資判断を行う。チームとプロセスの健康状態をチェックし、チームの前進と成長を促す。ミーティングのファシリテーションも行う(適宜)。次のスクラムマスターを育てる。sense)を手助けするのがアーティファクトです。プロダクトの要件を優先順位漬けされたリストにしたもの。一つ一つの項目をプロダクトバックログ項目(PBI)という。実現のための作業規模をチームが見積もる。優先順位付け(並べ替え)はプロダクトオーナーが行う。当該スプリントで完成する見込みのプロダクトバックログの一部。規模見積もりとベロシティ(推定される作業量)によって予測到達点を推測する。スプリント計画第一部で合意し、第二部で詳細に作業計画を行う。スプリント内の残作業量をプロットする右下がりのグラフ。できるか、視覚的に把握する。配布資料5.アジャイル開発のライフサイクルとテスターの役割次にアジャイル開発のタイムボックスと、各タイミングでのテスターの役割についてみていきましょう。顧客と利用者が期待しているものを分析し、今回のリリースで優先する機能(フィーチャー)を決定します。ユーザーストーリーを洗い出し、作業規模を見積もり、優先順位を調整して、プロダクトバックログを完成させます。・テスト戦略について決定する。成果物の価値を期待通りに届けられるよう、アイデアや計画の実現可能性について情報を提供し、テスト計画を立案することに主体的な貢献を行っていきます。ストーリーカードと受け入れテスト項目アジャイル開発で最も有名な手法の一つが「ストーリーカード」です。情報を集めることで、効率的な意思決定を行う、というのが従来の方法でした。配布資料げることは不可能になってきています。そこで、アジャイルでは、カードを媒介することで、チームの中央に知識を置き、多様なスキルを持つメンバーが集まり、効率的な要件定義を行うのです。紙のカードは同時に複数のメンバーが書いたり、操作したりすることができます。8あわせて、完了までに確認が必要な項目(受け入れテスト項目)について検討します。具体例で考えることで、利用者にとっての価値を共有し、完了までに必要な作業の規模をより正確にし、スプリント開始後に確実に着手できるようにします。テスト自動化による品質の作り込みテスト自動化には2種類の取り組みがあります。TDD(テスト駆動開発)はデベロッパーテストとも呼ばれ、開発者自身の作業の足がかりとしてテストを書いていくものです。各メソッドの振る舞いをテストするコードを先に書き、テストに合格するようにメソッドの実装を書いていきます。結果的にはコードとともに、十分な量のユニットテストが生み出され、いつでも確認できるようになります。テストを壊さないようにコードを洗練させるリファクタリングも行っていきます。一方で、受け入れテストレベルでの自動化を行うのがATDD(受入テスト駆動開発)やBDD(ビヘイビア駆動開発)です。受け入れテストを定義したり実施するのはプロダクトオーナーや顧客の役目です。ツールでは、非プログラマでも理解/記述できるよう、自然言語に近いドメイン特化言語やHTML表などでテストケースを記述できるようになっています。スプリントの開始前にどのような受け入れテストを実施するのかを決め、その実行のための環境を整備しておくことが重要です。アジャイルテスターにとって、受け入れテスト項目を洗い出し、自動テストに落とし込むこと、また自動テストを適切に管理することは必須スキルといってよいでしょう。配布資料テストの全体像を俯瞰する製品の品質を確保するには、自動化できるテスト以外にも、多様なテストがあります。テスト駆動開発(TDD)です。機能レベルで受入条件をテストします。ATDDやBDDが支援します。期待に合っているか、競合に対して価値があるかなどを確認します。非機能要件やセキュリティをテストします。テスト環境、テストデータの整備スプリントを始める前に、テストやリリースのための環境を確認し、できる限り整備しておくべきです。各ユーザーストーリーの完了基準を考えておく必要もあります。見える化の仕組みを検討するテストの進捗や自動テストのカバレッジなどを、チームから見える場所に表示しておく方法を整備しておきます。配布資料(2)スプリント計画スプリント計画フェーズでは、チームが当該スプリントで完成させるストーリーが選択され、詳細なタスク(作業計画)を検討します。ストーリーがテスト可能であることを確認するストーリーがテスト可能であるかどうかは、カードを見るたびに気にする必要がありますが、スプリント計画はそれを確認する最後のチャンスです。ストーリーをどのようにデモンストレーションするか検討するスプリントの終了時にはステークホルダー向けにデモを行います。そのストーリーの成果物や価値をわかってもらうためには、効果的なデモンストレーションが必要です。そのストーリーははっきりと見せられるでしょうか。完成したストーリーを、プログラマやテスター以外の人にも簡潔に説明する方法について検討します。ストーリーの規模を明らかにするチームはストーリーの規模を、プランニングポーカーなどを用いて見積もっていきます。テスターもチームの一員として参加し、必要に応じて明確化(clarify)のための質問をしましょう。大きすぎるストーリーは分割します。テスト工数を最小限にしつつ、そのストーリーの有効性を確認できる実装方法はないか、検討を行います。経験のない技術を採用するときなどは、「スパイク」という技術確認のためのストーリーを行います。有限の調査検討時間を決めて、その技術を採用する意味があるかどうかを検討します。その結果、次回以降のスプリントではより正確に見積もれるようになります。配布資料(3)スプリントの進行とテスト、完了の確認チームは、ストーリーを優先順位に従って実装していきます。受け入れテストの自動化を行う場合は、開発と平行して受け入れテストの自動化を進めます。デイリースクラム(朝会)スクラムでは、一日一回のミーティングを行って、日々の進捗やメンバーの状況を確認します。以下の3点を手短かに共有します。(前進を妨げているもの)開発者との協同作業開発者の隣に座ってテストを実装する(ペアテスト)、気になる部分の進捗を適宜見せてもらう、ストーリーが持つ価値の理解を深めるためにチーム外の人々と話すなど、チームが前進するために、できることを行っていきましょう。不具合との対峙スプリント進行中に、以前リリースしたシステムの不具合(バグ)が報告される事があるでしょう。この場合は、スプリントで計画されたストーリーよりも優先して対処しなければならない事がほとんどでしょう。直せる場合は、修正し、リグレッションテストを行い、修正リリースします。テストが自動化されていれば、リグレッションテストは短時間ですみます。不具合への対処時間が短くなり、スプリントの見積もり工数からのズレも軽微ですみます。大きな対策が必要な場合は、プロダクトオーナーに説明し、プロダクトバックログに記載します。スクラムでは、プロダクトバックログを優先度順に記述しているため、予定外の作業を行う場合にどのストーリーが実装できなくなるかが明らかです。プロダクトオーナーに報告し、必要な対策(ステークホルダーへの説明など)をとってもらいます。配布資料(4)スプリントデモ、レトロスペクティブ(ふりかえり)スプリントの終盤では、完成したストーリーをステークホルダに見せ、フィードバックをもらいます。その後、チームでスプリントをふりかえって、今後改善できるところがないか検討します。increment)」に仕上げます。プロダクトオーナーの出荷判断が下ればいつでも出荷に応じられる状態、ということです。受け入れテストはすべて終了しており、事前に定義した「完了の定義(DoD)」にしたがって、その他の確認がすべて終了した状態です。デモンストレーションのための過剰な準備をしてはならないスプリントデモでは「いつでも出荷可能なプロダクトの増分」のあるがままをステークホルダーに見せます。デモンストレーションのために過剰な資料や、ハリボテを準備してはいけません。うまく伝えられなかった場合は、次に向けて改善策を検討しましょう。チームとして改善するスプリントデモは、チームの間違いや、ステークホルダー間の意見の食い違いなどを発見する、よいチャンスです。多くの人は、動くソフトウェアや明日から使うような状態のツールがあってはじめて、具体的な想像力が働きます。チームは、成果物を提示し、ステークホルダーの意見に耳を傾けます。どんな情報も「見つかってよかった!」と考えましょう。レトロスペクティブ(ふりかえり)を行って、チームとして改善のヒントを探っていきます。できない対策も、メモをとっておき、順に解決していきます。解決できる問題だけを問題と考えるのは危険です。チームは前進しました。ささやかな成功を祝い、次のスプリントに備えましょう。製品を磨き上げる複数のスプリントで作られた「いつでも出荷可能なプロダクトの増分」を組み合わせてリリースする場合には、結合した状態で、利用者にとって不都合がないかをチェックする必要があります。利用者になりかわって、チームとして探索的テストを行います。時間を決め、全員で使ってみるのです。可能であれば、実際のユーザー像に近い第三者に協力をあおぎ、試しに使ってもらうところを、後ろから観察させてもらうと効果的です。見つかった問題はすぐさま修正を検討します。問題が発見されない/修正済みになったら、利用者の一部に使ってもらうことも検討しましょう。UAT(ユーザによる受け入れテスト)や、A/Bテスト(一部の顧客に先行リリース)を通して、リリースされるストーリーの価値を確認していきます。本番にリリースできてはじめて価値がある本番環境へのリリースを行い、顧客に成果物を届けることで、初めて価値が発生します。リリースできないストーリーはすべて在庫です。デリバリーをスムーズに行えるように環境を整備することは、非常に重要です。配布資料成功への鍵最後に、『実践アジャイルテスト』より、リザ・クリスピンとジャネット・グレゴリーの挙げる成功への鍵を紹介します。広い視野を持つもしかすると、企業の中にはさまざまな組織の壁があり、簡単にはチーム全体のアプローチができないと感じることもあるかもしれませんが、一つ一つ分析し、実験を積み重ね、できることを増やしていっていただくことを祈っております。助言をいただきました。本研修は森崎修司氏よりきっかけをいただきました。ジャネット・グレゴリーさんには東京での研修の開催を通じて多くのことを教えていただきました。ここに感謝を申し上げます。ClipboardCancelSave。