「GAFAM」から学ぶ、自動テスト手法――アジャイル開発で単体テストの“確からしさ”を検証する、ミューテーションテストとは：海外企業に学ぶテスト自動化（1）

海外の先進的企業の事例を基にテスト自動化に使われる手法を解説する本連載。第1回は、アジャイル開発において単体テストを検証する「ミューテーションテスト」について。

[高橋寿一，AGEST]

　今の時代に「海外に学ぶ」というタイトルは反感を覚える方がいるかもしれませんが、残念ながら日本のソフトウェア企業と「GAFAM」（Google、Amazon.com、Facebook、Apple、Microsoft）との技術力の差は大きいです。それは日本の技術者が米国などの海外の技術者より劣っているという話ではなく、企業の利益の差が大きいと思っています。例えば、Googleの利益は約4兆円で、利益率約20％、1人当たりの利益は約7000万円、Microsoftの利益は約6兆円、営業利益率 約40％、1人当たりの利益は約4000万円です。

　筆者のいたソニーの利益は約1兆円、営業利益率は10％、1人当たりの利益は1000万円。やはりもうかっていれば、技術（品質技術も含め）に大きな投資ができます。残念ながらソニーにいたころに使えた品質に関する研究開発費は、その前にいたMicrosoftほど潤沢ではありませんでした。

　しかし今の時代、GAFAMの成果は自社の研究開発費がなくても使えます、多くの成果はWebや専門誌で公開されています。他人のふんどしではないですが、少し先端的な品質管理のための技術を本連載で解説していきます。

ミューテーションテストの必要性

　現代のソフトウェア開発はウオーターフォールからアジャイルへの流れは止めるとこはできなさそうです。その流れの中でソフトウェアテストという分野は大きな転換点を迎えていると思います。

　ウオーターフォールモデルでのソフトウェアのテストの基本はVモデルです。要求仕様があれば、要求仕様が書かれた段階でテスト（レビューをして要求仕様の間違いを見つける）をする。詳細設計とコーディングが終われば単体テストをするといったようなものです。実にうまく分割され、そのステージごとの品質保証スタイルも洗練されていました。品質保証の担当者には気持ち良いプロセスだったのかもしれません。

　しかしこれがアジャイル開発が進み、そのメリットとスピード感が受け入れられると、ひょっとしたらテストエンジニアは、私は何をすべきなのかと思うかもしれません。要求仕様はユーザーストーリーに入れ替えられ、開発者は基本設計書や詳細設計書を書かないケースも出てきます。

　またコーディングに対する単体テストの比重は大きくなり、さらにコードの書けないテストエンジニアは困る可能性もあります。余談ですが、今後のテストエンジニアはコーディングに対する関与は必須になりスキルセットの変革が求められると思います。

Vモデル

編集部注）2022年7月13日、上記図版内の記載に誤りがあったため修正しました

　Vモデルに対応するテスト手法がアジャイルではうまく適応できなくなった今、明確に重要度が増しているのが単体テストだと思います。もしかすると、他のテスト手法がアジャイルでは適応しにくくなって地位が下がったので、逆に単体テストに対する品質保証の依存度は上がったともいえるのではないでしょうか。

　単体テストはC0やC1カバレッジという基準が適用されます、C0、C1は一般的なテスト手法なのでこちらの解説を参考にしてください。

　さて、C0やC1をある一定品質担保できればそれで単体テストは終わりなのか？　という問いにはシンプルにYesと答えます。しかし大きな問題が1つあります。

　「開発者はうそをつく」とまでは言いませんが、適切な結果報告をしない場合があります。実際に筆者が経験した話ですが、あるプロジェクトでC1網羅を100％と設定したプロジェクトがありました。筆者はそれはすごいな、と思った次第ですが、そのプロジェクトのマネジャーはただ単にソースコードを網羅しているだけの単体テストをテストプロセスとして、期待値を一切チェックしていませんでした。うそつきと知識の欠如はソフトウェア開発では同質です。期待値をチェックしないテストは無意味で、コストの無駄遣いでした。

　筆者の経験から、開発チームにメンバーが数十人いればそのうち数人は適切な単体テストが書けないものであると認識しています。もちろん開発チーム内で単体テスト研修なるものを実施していればよいのですが、そういう組織は少ないです。

　「うそをつく開発者、プロジェクトマネジャー」「単体テストを書くスキルがない開発者」が一定数いると、アジャイル開発において品質は低下していきます。そうなるとアジャイル開発で非常な重要なミッションである単体テストの確からしさを保証する手法が必要になってきます。その手法が今回説明する、ミューテーションテストです。

ミューテーションテストとは

　ミューテーションテストの考案は1980年だといわれています。ほとんどのテスト手法が1970年、1980年代に生まれているのを見るとそれほど新しい手法ではありません。今までほとんど注目されなかったテスト手法ですが、単体テストの重要性が増す中今後注目されるテスト手法だと筆者は考えます。Googleでも採用されているテスト手法です。

ミューテーションテストの考え方

　ミューテーションテストはまず単体テストケースを用意しなければなりません。残念ながら十分単体テストが書けていない組織ではミューテーションテストはできません。まずミューテーションテストをする前に全ての単体テストが通っていることを確認します。

定常状態

　その後ミューテーションテストツールでミュータント（バグ）を仕込みます。

問題のないケース

　当然バグが強制的に仕込まれるわけですから、ちゃんとテストが書けていれば、単体テストケース群の一部でバグが報告されます。

問題のあるケース

　しかし、あるケースではバグが報告されない場合があります。その理由としては単体テストケースが網羅すべきコードを網羅していなかった、もしくは網羅はしていたが期待値チェックをしていない（先に説明した期待値が全く書かれてない場合）などが考えられます。もし上記の問題のあるケースが発生した場合は単体テストに不備があるので、単体テストを改善する必要があります。

ミュータントの中身

　ミューテーションテストはある程度難易度の高いテスト手法なので、今度は実際のツールの振る舞いをみながら説明していきます。例えば以下のようなシンプルなコードがあったとします。

if (a && b) {
    c = 1;
} else {
    c = 0;
}

　上記のコードで単体テストを全て実行するとパスします。ですが「ひょっとしたら期待値をチェックしてないから成功なのかも？」と疑いたくなります。テスト担当者がいちいち全部のコードに疑いをかけることは開発者との人間関係を破綻しかねませんし、時間的にも許されません。そこでツールにミュータント（作為的に変更したコード）を入れます。例えば、以下のようなコードです。

if (a || b) {
    c = 1;
} else {
    c = 0;
}

　作為的にミューテーションツールが「＆＆」を「｜｜」に変更します。エラーのコードを入れるのですから、既存のテストコードの一部は失敗するはずです。もし、単体テストは相変わらず100％パスしているのであれば、単体テストがなんらかの形で適切ではないことが分かります。

テスト網羅レポート（PIT mutation利用時）

　上記がテスト結果例です。どのぐらいの行数をミューテーションテストで網羅できているか、または網羅できてないかを表示します。

まとめ

　ミューテーションテストの必要性およびその簡易的な機能説明をしました。ただその概念はレガシーなソフトウェアテスト手法に比べ難しく、さらに言えばミュータントは膨大な数があります。

　例えば先の例では「＆＆」を「｜｜」に変更しています。当然ミューテーションのバリエーションとして「c = 1;」を「c = 999」に変更するものもあります。今のところミューテーションのバリエーションは非常に多く、そして国際的なミューテーションテストのスタンダートがないので通常はすぐにテストケース数が爆発してしまいます。

　さらにそのミュータントを膨大なソースコードに入れ込む必要があります。となると「膨大×膨大＝無限大」という式になり（数学者には怒られそうな式ですが）、テストケース数が爆発します。そのため膨大なテストケース数に対応するためにレビューの仕組みを入れたり、ランダムにミュータントを選択する仕組みが必要になったりします。

　アジャイル時代の今後のテスト担当者は「無限大」に対してどう対処するかが重要なトピックになります。ミュータントテストでは「レビュー」の仕組み、そして「ランダム」に抽出するという方法を入れ込むことが必要そうです。次回はカオスエンジニアリングで、そこでも「無限大」なテストケースに対して、「ランダム」「レビュー」という手法をどのように適応していくかがテーマになります。

　繰り返しとなりますがアジャイル開発のメリットは多く、現代のスピーディーなソフトウェア開発には重要不可欠な開発手法です。アジャイルを選択する組織の中には、品質をどう確保するかを鑑みずにアジャイル手法を適用している場合も見受けられます。アジャイルのメリットだけではなく、どのようにアジャイル開発において品質を担保するのかを少し考えてみることはそれほど悪いアイデアではないと筆者は考えます。

著者紹介

高橋 寿一

情報工学博士。1964年東京生まれ。フロリダ工科大学大学院にてCem Kaner博士、James Whittaker博士にソフトウェアテストの指導を受けた後、広島市立大学にてソフトウェアテスト研究により博士号取得。米国Microsoft、SAP Labs、ソニーを経て、AGEST 執行役員 CTSO、AGEST Testing Lab.所長およびAGEST Academy学長を現職として兼任。情報処理学会及びIEEE会員

参考文献

Jefferson Offutt and Roland Untch, Mutaiton 2000: Uniting the Orthogonal, 1980.

Goran Petrovic and Marko Ivankovic, “Steate of MutationTesting at Google”, Proceedings of the 40th International Conference on Software Engineering 2017（SEIP）（2018）