「致命的なバグの決め方はある？」「自動化が難しい領域での今後のテストは？」　ソフトウェアテストの第一人者が語る“定量的に判断できる”品質管理

UTの積み上げだけではなく、STも必要ではないか

高橋寿一氏（以下、高橋）：（スライドを示して）今日は下のビジネスとか最大公約数的なユーザーの話、Netflixの話をしたいんですが、ちょっと時間がないので、一番重要な、上流テストをどうやって効率的にやっていくかという話を少ししたいと思っています。

繰り返しになりますが、基本的には2週間とか最大4週間のスクラムの中に、単体テストとかレビューとかリファクタリングを入れなきゃならないわけですよね。毎日CI／CDを流しますと。全ケースでもいいんですけど、サンプリングでもいいです。

CI／CDを流して。本当だったら1日何回も自動テストをやりたいですね。日々品質の状況が定量的にわかる状態に今後はしていかなきゃならないのかなあとは思っています。

ここまでが前振りのロジックのところですが、ちょっと質問タイムにいきます。

高木陽平氏（以下、高木）：質問係をしている、AGESTAGEST（※株式会社AGEST）の高木です。ヨシノさんから質問が来ております。「UT（Unit Test）だけを積み上げてもイテレーションのゴールは大概ビジネス要件だと思うので、やはりST（SystemTest）がいるのではないでしょうか」という質問です。

高橋：それは正しいと思います。ちょっと端折ってしまったんですが、アジャイルだとユーザーストーリーというかたちでユーザーの要件、ある意味ビジネス要件も織り込まれているとは思いますが、そこがイテレーションの中でどんどん積み上がっていくので、それはやります。

そのユーザーストーリーの中に入らないものが、やはりあります。それがビジネス要件の一部であったり、非機能要件の部分は入らないので。僕はそこだけSTでハンディングしたほうがいいのではないかと（思います）。

ただ、システムテストというものは、やはり上流でやるよりは非効率で、お金も時間もかかるものです。なので、なるべく少なくして、多くのテストを2週間なり4週間内のイテレーションに突っ込むのが品質を上げるコツなのかなとは思っています。

高木：ちょっと古い考え方で、私はアジャイルじゃなくてV字モデルで考えているのかもしれないんですけど。ユーザーストーリー、いわゆるビジネス要件は、V字でいうと右側がSTになるじゃないですか（笑）。

高橋：はいはい。

高木：それをUTでやるというのがなかなか結びつかないんですけれども。

高橋：僕はちょっと違う考えを持っていて。いわゆるV字モデルの要求仕様は、半分以上の部分が単体テストで網羅できるような気がするんですよね。

それはソースコードベースの、網羅率ベースの単体テストかもしれないし、いわゆる機能がちゃんと実装されているかどうかも単体テスト中に入れられるので。そういう意味では全部は入れられませんが、かなり多くの部分が単体テストに入るんじゃないかなと思っています。

高木：なるほど。先ほど回答してしまいましたが、STというのはシステムテストの略で、工程の最後でやるテストのことですね。

なぜ品質の文献がないのか

高木：もう1つ質問があります。「XP（Extreme Programming）、テストファーストの流れなのになぜなのでしょう」。これは恐らく最初の寿一さんの品質の文献がないという話だと思います。

高橋：すごくマニアックな質問をありがとうございます。XP限定のケント・ベックの本を、すごく読んだんですよ。ケント・ベックが単体テストをどう書くかっていう、ソースコードベースのけっこうめんどくさいソースコードがたくさんあるものをしっかり学びました。

テストファーストに関しても読みましたが、テストファーストはやるべきなんですよね。ただ、「テストファーストをやることによって定量的にこう改善しました」という文献が、少なくとも1990年から2022年までのほとんどの学術的文献を読んでもなかなかない。

だから、XPの中でケント・ベックが定義したことは、ペアプロもすごいし、テストファーストもいいものなので、ぜひやるべきですが、そこに対して定量的なものは今のところはないので。今後、やはり僕らも含めて、そこをやるべきかなとは思っています。

高木：ということは、プラクティスはあるけれど、定量的な部分はまだ確立してないという話なんですね。

高橋：そうですね。定量的な部分は、実はウォーターフォール時代からある網羅率しかないみたいな。もしくは「クラスコードとかきれいだよね」というところになってしまう。

高木：なるほど。

致命的なバグの決め方や指標などはあるか

高木：お、いきなり来ましたね。「致命的なバグの決め方、または指標などはありますか。同じプロトタイプでも、利用者の使い方によって致命的か否かが変動するため」という質問が来ています。

高橋：そこに関しては、どんな本を読んでも基本的にはあまりないんですよね。バグトラッキングツールとかそういうものがサンプルで載っていますが、僕はそこは各組織で定義したほうがいいと思っています。

当然、銀行系のシステムとAndroidのゲームでは、致命的なバグの概念はやはりぜんぜん変わってくるので。ただそこは、アジャイルもウォーターフォールも変動させちゃいけないです。なので、各会社、各組織の中で決めて定量的に測っていくのが、僕は真摯で重要なアクティビティだと思います。

高木：致命的というものに関していうと、各会社またはインダストリーによるということですね。

高橋：うん。

高木：続いて、「UTはE2EテストツールでのUIテストも含めての話でしょうか。画面遷移結合のようなテストもUTでカバーされるということですよね？」という質問です。

高橋：単体テストに関しては、ユニットテストですね。僕自身はISTQB（International Software Testing Qualifications Board）の委員なので、僕が言うのもなんなんですけれど。用語は網羅率ベースのUTと、単機能ベースのUTの両方が定義されています。

なので自社内で網羅率ベースでもいいし、単機能ベースでもいいと僕は思っています。今日の話に関しては、UTは基本的には網羅率ベース、関数ベースでの話になります。

高木：いわゆるホワイトボックステストと言われている領域ですね。　

自動化が難しい領域でのテストは今後どうなるか

高木：では続いて。「コネクティブのバグも、モビリティ領域や決算システムなどの自社内で完結しない多数のプロダクトの連携など、テストフェーズの自動化が難しい領域で、テストは今後どのようになっていくと思われるでしょうか」。

高橋：すごくいい質問ですね。今後もこの話を3時間ぐらいしなきゃいけないんですが、時間がないので手短に。

基本的に、ソフトウェア単独で動くことは今はほとんどなくなっています。マイクロサービスという考え方もあるので、基本的には自分たちの中でコンポーネントを決めて、そのコンポーネントに対してどういう品質を定義してそのまま持っていくか。それを守った後にコンポーネントを付けていくような戦略が必要になります。

例えばNetflixでは、どれが落ちても絶対にシステム全体は落とさないみたいな話をしたかったんですが。“カオスモンキー”みたいな。“カオスモンキー”はググっていただければすぐ見つかります。

そういうシステムが複雑にコネクトされているものに関しては、Netflix的なアプローチがまた重要になります。でもそれだけだとやはりうまくいかないので、各コンポーネントで最低限の単体テスト、いわゆるホワイトボックステストに出口があるのかなとは思っています。

高木：ここではどちらかというと疎結合を目指して、コネクティッドの部分はアーキテクチャで防いでいくという考え方なのですね。

高橋：そうですね。今のアーキテクチャの流行りっていう言い方はおかしいんですが、基本的には疎結合、マイクロアーキテクチャという方向なので、品質を担保するものとしてはいいアーキテクチャに向かっていることになります。

高木：では、アーキテクチャがそこに行っていないところは、やはり結合が必要という話になってしまうんですね。承知いたしました。

ここでの単体テストはストーリー・ユースケースベースのE2E自動テストも含むか

高木：最後の質問です。「ここでの単体テストとは主に関数ベースのユニットテストだけのことを指しているわけではなくて、ストーリー・ユースケースベースのE2E自動テストも含めているから、イテレーション中では機能要件のテストもできるという意味合いですか」。こちらは先ほどの質問と少しかぶっていますね。

高橋：この匿名さんはすごく理解をしていると思うんですよ。なので、完璧な姿はホワイトボックステストベースで単体テストをやって、ユーザーストーリーベースの機能確認を単体テストでやると、すごく洗練された組織になると僕は思うんです。

高木：もう1つ、これは深い質問が来ました。「初歩的な質問で恐縮ですが、既存のシステムへの改修案件でウォーターフォール開発からアジャイルに切り替えたい場合、既存のモジュールが含まれているので定量的な単体テスト、自動化を行うのは難しいと思うのですが、こういったケースはどう適用したらいいのでしょうか」と。

高橋：そうですね。すごく短い時間で答えるのは難しいんですが、こういうケースはあります。今後たぶんすごく増えてくると思うんですよ。ウォーターフォールでやっていたのが、組織がアジャイルに行って、ウォーターフォールで作った部分をリファクタリングしたらバグってしまったみたいな。

いろいろ手法はあるとは思いますが、基本的にはウォーターフォール部分に関してはなるべくいじらず放っておいて、新規の部分だけアジャイルでやっていくのが1つの手だと思います。

高木：今までの部分はもうブラックボックス化してしまうしかないという話ですね。

高橋：はい。

高木：そこを改修する時は、もうオールドファッションでやるしかないっていう。

高橋：というふうに割り切ってしまうことも僕はアリだとは思います。

高木：ありがとうございました。いったんここで真ん中のQ&Aは終了としたいと思います。

（次回に続く）