野次馬エンジニア道

野次馬な気持ちでプログラミングをあれこれと綴ります

アジャイルテストの4象限とテスト自動化のピラミッド

アジャイルなプロセスでやっています」といった台詞はよく聞く。しかしテストの重要性や方法論について力説してくれる人は多くない。

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

これを機に体系的に勉強してみようと手に取った一冊。内容以前に4,800円という価格と一部の翻訳にやや難があるように感じた。誰かもう少し安く読み易い本を出してくれないだろうか。エキスパートな先輩によれば「名著」だそうですが。

この本の特徴は冒頭の

p. xxvi より

テスト実施とテストパターンにおいてアジャイル開発志向のいくつかの素晴らしい本がありました。(参考文献参照)。これらの書籍は、一般的に開発者に向けて書かれたものでした。私たちは、ビジネスが理解できるテストを使用してビジネスの価値を提供することで、アジャイルなチームがさらに成功できるように手助けをするための書籍を執筆すると決めました。

のように想定読者を開発者に限らずに、アジャイルの短いサイクルで柔軟に変更しながら継続的にデリバリーできるというメリットを享受する際に中心的な役割を果たす品質とテストにフォーカスした一冊。

いつも通り気になったところをメモ。

アジャイルの価値

テストの話の前に、本書のマニュフェストでアジャイル開発の価値を定義すると

P.4 より

  • プロセスやツールより、人人同士の相互作用を重視する
  • 包括的なドキュメントより、動作するソフトウェアを重視する
  • 契約上の交渉より、顧客との協調を重視する
  • 計画に従うことより、変化に対応することを重視する

左側の項目に価値を認めながら右側の項目を重視する*1

アジャイルテストの4象限

様々なテストを視点の違いから下記の4象限に分類している(P108の図を元に作成)。

f:id:notta55:20150503133933p:plain

これまで何気なく「システムテスト」「パフォーマンステスト」「探索(Exploratory)テスト」などに取り組んできたが、それらを技術視点なのかビジネス視点なのか、チームを支援するためのものなのか、批評する立場から行うものなのかが4象限にスッキリと整理されている。技術かビジネスかという分け方でピンとこなければ、第1象限は内部で第2象限は外部という分け方でもいいかもしれない。

各象限のテストはこの順に行わなくてもよい。パフォーマンステストなど非機能要件については早めに行ってフィードバックをした方がよい。

第3象限や第4象限は、第1象限や第2象限を補完するもの。例えば、機能的には動作していて、一見すると要求を満たしているようだが、パフォーマンスが足りなかった、使いずらかった、セキュリティが甘かったなどの事態(リスク)を避けることができる。

要求の構造

ビジネス面のテストには要求の正しい理解が欠かせないが、それは一筋縄ではいかない。それをある意味割り切って捉えたのが下記の構造(P131を元に作成)。

f:id:notta55:20150503133943p:plain

本書でも度々出てくる「3人の力」(テスター、プログラマ、ビジネス専門家)で要求を分解し、全員で解決するというアプローチ。従来型の文書ではなくて、ビジネス面のテストが要求を的確に捉えたものとなるという考え方。

例と要求を引き出すツール

会話は重要で柔軟な方法だがコストが馬鹿にならない。そこで面白いツールが紹介されていた

P.153より

私たちは、マイク・コーンがこの本で述べている、「役割、機能、ビジネス価値」のユーザーストーリーのパターンが良いと思います。それは以下のようなものです。

(役割)として:わたしは(機能)を希望します。それにより(ビジネス価値)が可能です。

話を聞きながらこういったポイントを抑えようとするだけで大分違う(はず)。

テスト自動化のピラミッド

これが理想的な形(P.274を元に作成)。多くのチームやプロジェクトの場合はこの図が逆の三角形となる。単体テストコンポーネントのテストを土台として、可能な限り下のレイヤーにテストを押し込めるようにする。繰り返しや負荷の高い作業は自動化の対象となる。自動ビルドや継続的なインテグレーションは言うまでもなく必須となる。

f:id:notta55:20150503133951p:plain

手動で行うテストには限界があるし、手動のテストの割合が大きければ、その分探索テストに避ける時間が減ってしまうことになる。自動のレグレッションテストを導入して手動テストのROIを上げることが重要。

正しいことを行うために時間を取る

この本では(テストを備えていない)レガシーのシステムを技術的負債と表現しているが、

P.301より

あなたの組織の経営陣は結果をできる限り早く出すことに当然のことながら関心があります。もし経営陣が自動化を実現するための時間を与えることを嫌がるのであれば、そのトレードオフを明確に説明しましょう。動作確認を行うための自動レグレッションテストなしに機能を短期間で提供しようとする試みは、いずれ莫大な費用がかかる結果となります。

チームに技術的な負債が積み上がるにつれて、提供可能な、経営陣が求めているビジネス上の価値はより少なくなります。(中略)例えば、機能のスコープを削減する一方で基本的な価値をそのままにしたり、より良い製品を提供、維持できるように自動化を取り入れたりすることです。

全く同感。

反復指標

本書では、テストだけでなく、反復*2のプランニングやレビュー、振り返り(レトロスペクティブ)をどのように行うか、テスターとしてどう関わるかまでが紹介されている。プロジェクトを進行するにあたり、進捗をPMOにレポートする機会もあるかもしれない。その際の指標としてバグの件数は安易だがアジャイル開発においては不必要なものとされるべきとしている。

P.435より

  • ストーリー、機能分野ごとのテスト実施数
  • テスト自動化のステータス (自動テスト vs 手動テスト)
  • 期間中のパスフェイルのテスト数のバーンダウンチャート
  • それぞれのストーリー欠陥指標のステータスのサマリー

これらのような指標を集めたり報告したりすることは、大きな負荷となります。あなたの組織に必要な、シンプルな方法を探して下さい。

とある。ここはJenkinsのようなCIツールや要件管理ツールの出番な気がする。

感想

突飛な事が書いてある印象はまるで無かった。アジャイルのやり方を踏襲したプロジェクトも数多く経験したが、これが元ネタか ! と思うことの方がむしろ多かった。現実を重視する思想だけあって、どんなプロジェクトに関わっている人も取り入れる余地があり一読の価値はあると思う。説明で登場するツールに馴染みがないので、代わりにWebやモバイル系のツールを追ってみたい。

*1:現実的にはそもそも会社や組織のカルチャーがこれらにマッチするかという問題がありそう

*2:自分は「イテレーション」という呼び名の方がしっくりくる