【連載特集】エンタープライズアジャイルにおける品質担保をどう実現するか ― 第２回　品質を支えるアジャイルテストとは

　アジャイルテストについて、Lisa Crispinが著書「Agile Testing」の中で、分類をしています。分類表は、以下になります。

【図１．アジャイルテスト分類】

※「Agile Testing」Lisa Crispinより引用

開発支援ープロダクト評価、テクノロジー側面ービジネス側面の２つの軸で、Q1からQ4の４分割にテストを分けています。

　はじめに、Q1ですが、ユニットテストなどの開発エンジニアが行うテストです。従来の単体テストと混同しやすいのですが、ユニットテストはプログラム設計のためのテストです。プログラムができてから検証のための網羅性のテストではありません。ユニットテストは、テスト駆動開発によって、作成されます。そして、プログラム完成後ではなく、プログラム作成のはじめに作られます。厳密に言うと、プログラムと同時にテストを作成していきます。ユニットテストは、日々作成していき、プログラムの作成、変更と共に実行されます。従来の単体テストとは大きく異なります。

　従来の単体テストでは、テスト仕様書などを作成するのですが、ユニットテストは、日々変化していくので、テストコードそのものが仕様書になっています。そのため、テストは可読性のあるコードになっています。そして、プログラムが完成と同時に、ユニットテストもパスしているのです。

　ユニットテストは、設計開発のためのテストなので、完全な網羅性はありません。そのため、ユニットテストを用いて、すべてのクラス、すべてのメソッド、すべてのコードをテストしているとは限りません。網羅性のテストは、別のタイミングでテストします。

　アジャイル開発を行うチームは、従来とは違うことをきちんと理解して、テスト駆動開発を行います。従来との違いを理解せずに、ユニットテストは単体テストだと思い込み、従来どおりテストを行うと、アジャイルのイテレーションがうまく回らず、エンタープライズアジャイル開発は失敗してしまいます。アジャイルプロセスの定義、実践するプラクティス、テストのタイミングなど、きちんと決めてから開発を進めるべきです。

　Q2は、ストーリーテスト、UXなどのユーザー視点で作られたテストです。ストーリーとは、アジャイル開発での要件で、ユーザーが作成します。そのユーザーの作成したシナリオに沿って、テストが作成され、UXテストは画面などのテストを指します。画面の細かい動きは、JavaScriptなどで作られていることが多く、これらに対して、テストを書くことができます。

　ストーリーテストは、ユーザーの作成したストーリーに関するシナリオをもとにテストを作成します。テストは、ひとつのプログラム（サービス、コンポーネント）とは限りません。いくつかのプログラムが連携することもあるかもしれません。ただし、本格的な結合テストはQ3で行います。ストーリーテストはシナリオをもとに書いたように、すべてのケースを網羅しているわけではありません。そのため、ユニットテスト同様、ここでも、シナリオ漏れという可能性があり、ストーリーテストは１００％確実なテストとは言えないでしょう。

　従来のテスト方法であれば、フェーズごとに、完璧にテストを行います。これに対して、アジャイル開発では、１００％の品質ではないコードでも、プロジェクトは進んでいきます。もちろん、リリース前までには、Q3、Q4のテストを行うので、従来と同等以上の品質になります。こういうことを理解して、プロジェクトメンバー、プロジェクト責任者は、エンタープライズアジャイルのプロジェクトを進めます。さもなければ、Q2テストを行っただけで、リリースしてしまい、不具合が出た、という状況になってしまいます。

　Q3は、受入れのためのテストです。探索やワークフローと言ったユーザーストーリーにはない、網羅的なテストも行います。そして、テストレベルとしては、すべてのプログラム（サービスなど）を連携させる結合テストです。従来型の結合テスト、総合テストと同じものです。

　受け入れテストなので、基本的にはイテレーション内で完了させて、リリースが可能な状態にしておきます。ただし、アジャイルプロセスをカスタマイズして、リリースのためのイテレーションを設けることも良いと思います。アジャイルは、改善していくことが重要なので、すべて教科書どおりで、イテレーション内ですべてを終わらせる必要はありません。必要だと思う改善は、次々トライしていきましょう。

　受け入れテストをイテレーション内で行い、不具合があった場合、修正して、再度受け入れテストを行うことになります。手動でテストをやっていては、時間がかかってしまいます。そこで、テストの自動化を行います。ユニットテストは、プログラム言語で記述されたプログラムなので、自動化するのは容易です。一方、受け入れテストは、画面に対して、項目を入力することなども含まれるため、厄介な代物です。そのため、受け入れテストを実施する際、テスト自動化ツールを使います。日本の開発現場では、受け入れテストの自動化に対して消極的な傾向もあり、ユーザーによる受け入れの期間がどうしても必要になることが多いです。

　その他、ユーザビリティテストは画面などの操作性であるユーザビリティに関するテストです。ユーザビリティの改善が出たときには、要件として、エンジニアは改善をタスクにします。イテレーションごとに、細かく改善が行われていきます。

　このように、Q3はリリース前のテストになるため、従来のやり方と同等のテストを行い、品質を担保する必要があります。ここでは、従来からのテスト作成者は、同様のテストを作成するので、アジャイル開発になろうとも、スキルを活かすことができます。ただし、イテレーション内で行う場合は、スピード感が違ってくるので、テストエンジニアのマインドチェンジが必要になります。

　最後になるのが、Q4で、パフォーマンスやセキュリティに関するテストです。従来でもリリース前のテストとして実施しているものと同じです。但し、イテレーション内で行う場合には、自動化して、随時できるようにしておく必要があります。パフォーマンスに問題がある場合は、設計に良くない箇所があることも考えられ、コードの作成の修正を行う必要があるかもしれません。また、アーキテクチャーに問題があり、サービスを分割したり、配置を変えたりなど、プログラムを変更する可能性もあります。テストの内容としては、従来と全く変わらない内容です。

　テストに関して、アジャイルであろうと、従来型であろうと、同じ品質を保つためには、同等レベルのテストを行う必要があります。エンタープライズアジャイル開発にして、開発スピードは早くなったとしても、品質レベルが下がってしまえば、本末転倒です。

　しかし、テストの切り口はアジャイル開発では異なります。ユニットテストは、単体テストとの性質の違い、結合テストの自動化、さらにイテレーション内ですべてのテストを実施するなど、多くのことなったこともあります。そして、エンタープライズアジャイルで上記のテストを実施する場合には、スキルが必要となります。従来の知識だけでは、エンタープライズアジャイルのテストは実施できません。新しい技術習得なしでは、アジャイル開発はできないのです。ある意味、チャレンジャーとなって、プロジェクトを進める気持ちも必要です。

　そのため、エンタープライズアジャイルのテストにおいて、実施内容云々ではなく、違いを見極め、学習し、テストを行っていくことが重要なのです。

次回へ
　次回は、生産性の向上や、品質担保を行うことを目的としたツールを紹介します。アジャイルソフトウェア開発宣言で、プロセスやツールよりも 個人と対話の重要性が論じられていますが、実際には、ツールなくして生産性や品質の向上は望めないのです。
アジャイルソフトウェア開発宣言（https://agilemanifesto.org/iso/ja/manifesto.html）

全編をまとめてお読みたい方、下記より全文をダウンロードできます。