すべてのコードはテスト済みのコードだ。

テストが追いつかない場合、a.開発者が多すぎるか b.テストしたくない開発者が多すぎるか、のいずれかだろう。

 

 

開発者とテスト担当者の概要

アジャイルチームは主に開発者とテスト担当者からなる。開発者は、ユーザーストーリーに対応するコードを書いて、スパイクあるいはリファクタリングストーリーを用いて、調査や設計、プロトタイプの作成を行う。開発者たちは協調的に作業し、他の開発者とペアプログラミングしたり、テスト担当者とペアを組んで作業を行ったりするかもしれない。開発者の責務としては、プロダクトオーナーやテスト担当者と連携し、確実に適切なコードを開発すること、コード、単体テストと自動化された受け入れテストを作成すること、毎日共有リポジトリーに作成した新たなコードを入れることである。

開発者がコードを書く間に、テスト担当者が受け入れテストケース(できるだけ自動化される)を書き、開発者やプロダクトオーナーと連携してコードと受け入れテストが望まれた機能に沿っていることを確認し、受け入れテストを実行するとともに、共有リポジトリーにテストケースのメンテナンスをする。このようにテスト担当者の作業は開発者の作業と並行して実行される。

みんなでテスト、みんなでコーディング。

詳細

品質責任を分担し、価値創造を強化する

従来までは、開発者とテスト担当者の役割は大きく異なるとされてきた。というのは、2つの役割はそれぞれ異なる管理構造に所属していたからである。しかしながら、価値を創出したり、価値を実現するためのあらゆることにおいて両方の役割が必要であるので、今や2つの役割は混ざり合い、同じチームの一部分となる。例えば、Cohnの書籍([1]の第8章)では、開発者とテスト担当者はともに価値創出に欠かせないので、役割は区別せず、全員が「開発者」と呼ばれる。

さらに、アジャイルでは、すべてのコードはテスト済みのコードである。チームは他の何も信用しない。これを達成するため

  • 開発者はテストする:開発者は自分自身でコードの正確性を保証することに誇りを持つ。
  • テスト担当者はテストスクリプト(コード)を開発することによって、より積極的にコードの振る舞いを評価する。
  • 日々(時間毎)で、開発者とテスト担当者が一緒に作業をすることが、各ストーリーが完了の定義に満たしていることを保証する。
  • 開発者とテスト担当者は形式的な手続きや引き継ぎ、受け入れを取りやめ、むしろ、単純に1日目からプロダクトオーナーがストーリーを受け入れるまでに一緒に作業をする。
  • 据え付け部(フィクスチャ-)の作成や自動化された受け入れテストの作成に関して、開発者はテスト担当者を支援する。
  • テストコードの網羅性を向上させるため、テスト担当者は、開発者が境界ケースや有効なデータに関する理解を深めることを支援する。

協調とイノベーションを促進し、ベロシティーのボトルネックを解消するため、このようなやり方で、アジャイルはチームメンバーの多能化を助長する。

テスト容易性の設計

アジャイル開発者はテスト容易性を支援するためのシステム設計を常に進化させる。実践上、テスト容易性の設計はよい設計と同意語で、モジュール化され、結合度が低く、凝集度が高いレイヤ、コンポーネント、クラスを意味する(詳細は「テスト容易性のための設計」を参照する)。テスト容易性の設計は、個別のロジックの断片のテスト容易性のみならず、より高い、システムレベルや結合されたテストの作成をサポートする。

協調と知識共有

アジャイルでは、小さなチームが迅速に価値提供を納品できるのと同様に、開発者とテスト担当者が同じ場所にいることがベロシティーと品質の向上に貢献する。これは権限を与えられたアジャイルチームを構築するための「(陰陽の)陰」である。「陽」とは、開発者が開発者の集団で一緒に仕事を行うのではなくなるということである。それでも、開発者はそのような集団の方が個人として、学習、共有、全体のスキル向上をしやすかったと主張するかもしれない。これを実現するため、アジャイル企業は意識的に、ベストプラクティスや知識がチーム間で容易に共有される環境を作らなければならない。これらのベストプラクティスと知識とは、継続的なインテグレーション、コードの共同共有、自動化された単体テストと受け入れテストなど、新たに発見されたアジャイルスキルを含んだものである。

これは専門技能コミュニティー(CoP)によって促進される。CoPは非公式的なワーキンググループであり、以下の図に示すように、チームや専門家グループ間で横断的、効率的に知識共有と開発を行うために設置される。例えば、自動化テストCoPは自動化テストスキルの推進に興味を持つテストエンジニアや開発者によって構成されるかもしれない。また、継続的なインテグレーション、継続的なデリバリ、コーディング標準やその他の新しいプラクティスやプロセス周辺のCoPも設置されるかもしれない。

Community of Practice

図1.専門技能コミュニティー(CoP)。メンバーは自分達のアジャイルチームにて作業するが、定期的にベストプラクティスを共有する。

開発者とテスト担当者はアジャイル開発の中心にいる。小さな機能横断なチームで作業し、価値を提供するテスト済みの動くコードを迅速に作成できる。開発とテスト間の境界ははっきりしなくなった。開発者はテストをし、テスト担当者はテストスクリプトを書く。継続して個人が専門知識を習得するのと同時に、効率的に複雑なソリューションを構築していくためにも、新しい言語、フレームワーク、プロセスとツールの習得が必要であり、横断的なチームと専門技能コミュニティーの協調も重要である。


さらに知りたい場合

参考文献
[1] Cohn, Mike. Succeeding with Agile: Software Development Using Scrum.  2009.

[2]Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise,Addison-Wesley, 2011. 第4章 (邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

[3]Larman, Craig, Vodde, Bas. Practices for Scaling Lean & Agile Development: Large, Multisite and Offshore Product Development with Large-Scale Scrum, Addison-Wesley, 2010, chap. 3.

Last update 1 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.