この記事はPeter G Walenによるゲスト投稿です。
2011年、Alberto SavoiaはGTACで「テストは死んだ」と宣言しました。Savoiaのプレゼンテーションは「議論を呼ぶ」ものでした。提起された問題は今も存在しています。皆、本来できたはずのことに比べてテストを遅らせコストを増やすようなことをつづけています。なぜこんなにも多くの企業がそうしているのでしょうか。
Alberto Savoiaは2011年のGoogle Test Automation Conference (GTAC)の基調講演として「Test Is Dead」と題する講演を行いました。 Savoiaが提起した問題の1つが、テストと「オールド・テストメンタリティ」および「ニュー・テストメンタリティ」をめぐる議論です。ソフトウェアテストの「エキスパート」らの間でソーシャルメディアは爆発しました。
大勢がSavoiaと彼を紹介したJames Whittackerを攻撃しました。大勢がSavoiaをペテン師だと罵倒し、彼のメッセージは誤りで見当違いだと非難しました。多くの人は、Savoiaの講演と主張は良く言っても偏見だとして退けました。
ここに実際の講演へのリンクがあるので、非難が正当かどうか、ご自分で確認してみてください。
この講演にはおおいに検討すべき価値があります。私が興味深く感じたのは、どんなにずさんでも製品をビルドし、出してみて本当に需要があるかどうかを確かめるのが重要だという点です。これが完全に妥当な状況もあります。製品に巨額の投資をする前に、おおむね動作するプロトタイプを作成するのは賢明なアイデアかもしれません。
少し考えてみれば、鳴り物入りで発売され、ほとんど間を置かずに消えていった製品を多数思い出せるでしょう。そうであれば、製品を買いたい、使いたいという人がいるかどうかわかる前に企業の時間と労力を費やして製品を完璧にする価値があるかを検討するのは意味があることのように思われます。
これは多くの産業ではよくあるアプローチです――皆が直接的に体験したことがあって分かりやすいのは、フードサービスやレストランの例です。シェフやスタッフから見て良いと思う料理が開発できたら、短期間の「スペシャル」として提供されます。需要があれば、おそらく多少の改良を加えて、調理手順が広く配布され、一部の人だけでなく、厨房のクルーが作り方を練習します。そして料理は通常メニューのアイテムになります。
ソフトウェア業界だけは、このやり方に問題があると考えるのでしょうか。それとも、私たち自身の自己防衛の感覚が、多くの人たちにこのアイデアへの反対を叫ばせたのであり、また現在も叫ばせているのでしょうか？
しかし、テストは
私が思うに、あれほど多くの人を動揺させたのは、Savoiaがどんなふうに彼の言うソフトウェアの「オールド・テストメンタリティ」を切り捨てたかではなかったでしょうか。Savoiaは「オールド・テストメンタリティ」を指して、要件が仕様につながり、仕様が設計につながり、設計がコードとテストにつながると説明しました。コーディングが完了すると、テスターがコードをテストします。
要件定義書と仕様書は至高の存在です。これらが設計書およびテスト戦略の元になり、それがテスト計画書、テストスクリプト、テストスイート、テストシナリオ、テストケースの元になります。前提となるのは、当然、テスト計画書がそれら他のドキュメントに基づいていることです。
ドキュメントは完ぺきであらゆるものをカバーしているので、それらのドキュメントでカバーされていないシナリオはあり得ません。バリエーションは存在しません。皆無です。
もちろん、要件は定義され、まとめられ、レビューされ、修正され、またレビューされ、修正されます。しばらくすると、要件は「合意済み」になります。私が働いていたいくつかの職場では、これは単に、ソフトウェアに何をしてもらいたいかを記述しようとしている人たちが、それはよくないアイデアで達成したいことの役には立たないだろうと言い続けるIT部門の人たちと議論するのをあきらめたということを意味していました。
要件は正式なドキュメントに変換され、署名されます。要件定義書のコピーが要件に基づいて仕様書を作成する仕様チームに送られます。すべての要件が仕様に変換されるか、時間が尽きるか、どちらか早いほうが来ると仕様書作成ステップが完了します。仕様書は設計チームに送られます。
設計者は仕様書を見て、仕様を反映する設計を作成します。ときどき設計者は要件定義書に戻って、設計が要件と一致しているかを確認します。その後、設計はドキュメントとして印刷され、コードを書き、テスト戦略およびテスト計画を作成する人たちの元に送られます。
テスト計画がテストスイート、テストシナリオ、テストケースとともに完成すると、テストチームはコードが完成するのを待ちます。待ちます。ひたすら待ちます。
しばらくして、たいていは計画されたコード完成期日が過ぎた後、コードが完成してテストできるようになります。お祝いムードが盛り上がり、ピザとTシャツで記念すべき偉業がお祝いされます。多くの作業が完了し、プロジェクトは史上最高のプロジェクトになりました。コードの複雑さを思えば、遅れはほんのわずかです。テストが開始できるようになりました。
そのため、テストチームはピザとTシャツのパーティには姿を現しませんでした。テストをしていたのです。コードが遅れに遅れたため、テストの期間は深刻に制限されていたからです。
それで、テストは？
私はこれと非常によく似た道をたどった組織で働いた経験があります。注意深く文書化された作業モデルおよびアプローチを4つ思い出すことができます。わたしはいまだにそれらの作業モデルと、その「新しい」モデルにどれほど大きな利点があるかを説明した文書のコピーを持っています。
テスト計画やスクリプトも含め、各作業成果物に必要なステージゲートがあり、チェックポイントがあり、サインオフがありました。サインオフされた合意済みのパスから逸脱するには、苦労して承認を得る必要がありました。
誤解しないでください。このレベルのチェックが必要な場合もあります。重大な傷害や死亡につながるようなシステムです。生命や身体に関わるソフトウェアでは、これは完全に妥当なやり方です。
他のアプリケーションも、生命の危険があるシステムほどではないにしても、詳細レベルの確認が必要です。ナビゲーションや通信を行うシステムも、コントロールや詳細に細心の注意を払って慎重にテストする必要があります。これが適切ではないと言いたいのではありません。
私の知るかぎり、たいていの組織では、非常に詳細に情報を記述するのは良い考えです。また私の知る限り、たいていの組織では、そのような詳細な情報を開発作業が始まる前に記述するのは不可能です。
言い換えれば、たいていの組織では、そのような開発構造はうまくいきません。厳密なガイドラインに従ってスコープや境界を制限されたテストは、テストが開始される前に可能なあらゆる条件が予期され、計画されている場合にのみうまくいきます。これは類似の作業モデルの大半が前提条件とするものです。
私たちが期待し、また上記のアプローチの唱道者たちが説くことに反して、多くのソフトウェアは完全に予期できるようには動作しません。
コントロールされ、構造化されたモデルで行われるテストは、定義上、可能性という点でバリエーションを許しません。プロジェクトの要件定義、仕様作成、設計フェーズで、ソフトウェアの状況とすべての可能なパスが識別され、検討済みであることを前提とします。固定された最終状態が明確に描けていなければ、このような条件はほとんど達成不可能です。
機能するテスト
2011年にSavoiaが「死んだ」と宣言したのは、このように範囲が固定された、あらかじめ定義済みの、そのほかには何もないテストです。
彼は間違っていました。依然としてこのようなテストは行なわれていますし、多くの企業はこれ以外のテストを知りません。おそらく、だからこそまだ死んでいないのでしょう。
すべての開発が終わってからテストをするのは、控えめに言っても問題があります。1か月も2か月も前に作成されたコードのテストにテスターが取り掛かったとき、開発者が該当のコードを覚えているとどのくらい期待できるでしょうか？開発者はどのくらい迅速に今行っている作業をいったんおいて、「完了」とマークしたものの問題に取り組むことができるでしょうか？
テストには時間がかかります。見つかった欠陥や問題を修正するのにも時間がかかります。私の経験では、このような環境では、欠陥の修正にはテストよりも時間がかかります。ときには、最初の開発作業よりも時間がかかります。
いいかげんに状況は変わるべきです。プロジェクトにふさわしいテストという課題に対して、孤立してばらばらに多大な時間を費やすのは、他のオプションに比べて不確かです。
テストに関して、「即興でやる」ということを提唱しているのではありません。そうではなくて、別のアプローチを提案したいのです。会話です。コードを開発する人たち、設計を担当する人たち、テストを計画する人たちが対等に協力して、アイデア、考え、懸念を出し合います。互いに協力するほか、プロジェクトチームが実現しようとしているビジョンや意図を考えた人たちとも連携します。
これは来るべきポストアジャイルのビジョンなどではありません。魔法のように仕事をこなし、付箋に書いたり窓にホワイトボードマーカーで書きつけたりしている人たちのユートピア的な見方でもありません。私自身が関わり、結果として成功を収めたモデルの話です。
このモデルは、テストチームと開発者に互いのアイデアと洞察を知る時間と機会を与えます。誰もが機能と機能周りのテストに貢献します。
価値を届ける
これによってテスト計画が現実的なものになります。理解を早くし、変更やバリエーションが発生したときの余地をつくります。プロジェクトチーム全体が顧客の本当のニーズに集中することを可能にします。顧客のニーズと問題を解消する明らかな価値があるソフトウェアをデリバリーできるようになります。
私がこのアプローチを採用したときは、コミュニケーションと理解を促進するのに役立ちました。チームが個人の集まりとしてではなく一体となってプロジェクトに取り組む助けになりました。テスターは変更がどのような形になるかに労力を集中させることができます。
新しいソフトウェアや変更されたソフトウェアがどのように動作するかに応じて計画を立てることができます。違いを厳しい目で検討し、単に何かが起きたというチェックでなく、プロジェクト全体に情報をもたらすような意味のあるテストを構築できます。
また、製品がデプロイされるときには実態とずれているかもしれないドキュメントを作成するのに要する労力を削減できます。テスターは開発者とペアを組み、検討されていなかった動作に光を当てるような意味のある単体テストを作成できます。
たいていの状況では、テストで本当に重要なのはエビデンスです。テスト戦略、テスト計画、テストスイートなどに関して念入りに用意された膨大なドキュメントは、状況によってはある程度有効な場合もあります。しかし、そういったドキュメントは、テストで何をし、テスターが何に遭遇したかの本当のエビデンスにはならないことも事実です。
「すべてのテストのボックスがチェック済み」であることを確認するのではなく、製品が可能な限りベストな状態であることを確認するのにテストの労力を振り向けましょう。これが「オールド・テスト」に代わるべきものです。
テスターが全面的に関与する専門家としてチームや組織に貢献できるようになるために、「オールド・テスト」は死ななければなりません。
Peter G. Walenは、ソフトウェア開発、テスト、アジャイルプラクティスで25年以上の経験を持っています。ソフトウェアがどのように動作し、他のソフトウェアと連携するか、またソフトウェアを利用するユーザーをチームが理解できるよう支援に尽くしています。Agile Alliance、Scrum Alliance、American Society for Quality (ASQ)のメンバーであり、ソフトウェアミートアップに熱心に参加し、カンファレンスでもたびたび講演しています。
（この記事は、開発元Gurock社の Blog 「Old Testing Must Die」2020年5月5日の翻訳記事です。）
