ソフトウェアテスト第一人者の高橋寿一が語る、未知領域のアジャイルテストと品質視点の変化とは

■登壇者プロフィール

株式会社デジタルハーツホールディングス
CTSO（Chief Testing Solution Officer） 高橋 寿一氏
広島市立大学にてソフトウェアテスト研究により博士号取得。米Microsoft社・独SAP社でソフトウェアテスト業務に従事。ソニーのソフトウェア品質担当部長を経て、株式会社デジタルハーツホールディングスCTSOに就任。著書に「知識ゼロから学ぶソフトウェアテスト 【改訂版】」「ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方」など。

ソフトウェアテスト第一人者の高橋寿一氏が、AGESTのCTSOとして登壇

今回登壇した高橋寿一氏は、米マイクロソフト、独SAPでソフトウェアテスト業務従事した後、ソニーの品質担当部長を10数年経験。ソニーでは品質のストラテジーを考えるポジションで活躍してきた。現在はデジタルハーツホールディングスのCTSO（Chief Testing Solution Officer）、2022年4月からはさらにAGESTの執行役員CTSOとして、同社技術を牽引している。

株式会社デジタルハーツは、ゲームのデバッグ事業からスタート。2013年にホールディングス制をとり、さまざまな会社をグループ子会社化。UX/QA/セキュリティの専門知見を活かし、業界問わずソフトウェアテストやテストファーストな開発の支援、バグ修正のためのクラウドインフラまで含むコンサルティング、脆弱性監視やサイバーセキュリティ事業等の加速度的な成長を目的に、同事業部門をスピンアウトし、2022年4月1日に株式会社AGESTを始動させた。

AGESTは先端QAテクノロジーの研究や最新技術に対応したQAテックリード人材の育成の推進、次世代QAソリューションを提供する。今回のイベントは、AGESTのお披露目の機会でもあった。

高橋氏は、主に「品質の本質」にフォーカスを当てて講演。モデレータとして登壇した株式会社AGESTの高木陽平氏や、視聴者からの質問にも答えるセッションタイムも交えながら、進められた。

アジャイル開発で品質を担保するために必要な4つのポイント

ウォーターフォール時代は、バグと品質は相関関係として考えられてきた。だが、バグはゼロにはならない。だから「バグの数を数えるのはやめよう」と、高橋氏は呼びかける。

「バグを出した数＝品質ではありません。今後、定量的に品質を語る上で、バグの数を数えるべきではないと考えています」

では、アジャイル開発で品質を担保するためには何が必要か。ウォーターフォール開発のV字モデルをアジャイル開発に適用するのは、重すぎると高橋氏は指摘する。そこで提示するのが以下の4つのボックスである。

「この4つの活動を同時に考えることで、アジャイルでの品質担保がうまくいくでしょう」

この4つのボックスをウォーターフォールモデルに当てはめると、テスト担当者の作業量は膨大となる。バグを出す膨大なテストケースを書き、膨大なテストを実行するためだ。そこで、ここに時間や人員をかけることで、品質を上げていったのである。

一方、アジャイル品質モデルでは単体テストに頼らざるをえないため、開発者の具体的な作業量が大きくなる。単体テストの活動で品質がどれだけ向上したか、ゴールの品質として出荷していいかという判断など、そのメトリクスをどう定めるかはまだ解っていない。

アジャイルの場合、2週間のイテレーションの中に、ウォーターフォールモデルのように単体テスト、結合テスト、システムテストを入れることはできない。そのため、開発者は2週間のイテレーションの中に、単体テスト、レビュー、リファクタリング活動を詰め込むことになる。

2週間のイテレーション終了後、その成果物に対してステークホルダーから品質について問われた際、回答しにくいという現実があります。私個人としてだけではなく、AGESTとして2週間というイテレーションが終わった時に、定量的な品質を回答できる世界にすることが必要だと考えています。

単体テストで品質を担保する

ではイテレーション内で、単体テストのみで品質担保するにはどうすればよいか。単体テストはやっているものの、網羅率を聞かれると黙ってしまう人も多いのではないだろうか。

「アジャイルに移る上で大事なのは、チームの中でどう品質を単体テストで上げていくか定義すること。イテレーションの中で品質が完結しないと、出荷後にバグが出てしまう。そうならない体制や考え方、アクティビティを定義する必要があります。これが実現できれば、チームとして圧倒的に仕事を減らすことができます」

アジャイルで品質を担保するには、エンジニアリングの人材戦略を変えることも必要だ。アジャイルに移行すれば、テスト担当者ではなく、開発者自身が膨大な単体テストをして品質を上げる世界となる。

つまり、旧来のテスト担当者の仕事はどんどん減っていく。そのため数年のうちに、テスト担当者もこれからはソフトのコーディングスキルが必要になる世界になることが考えられる。アジャイルのメリットは、顧客が望むものをスピーディに出すこと。だが、品質を高める工夫をしないと、顧客の望むものにはならないと高橋氏は言う。

品質問題について、高橋氏は具体的な例を挙げて説明。以下のスライドのように、「コードが汚い」→「機能追加でリファクタリングしない」→「ファイルが長くなり、複雑度が高くなる」。そして品質が劣化するというわけだ。

「ウォーターフォール・アジャイルいずれでも品質の劣化は起こるのですが、ここで重要なのはアジャイルの方が劣化するスピードが上がること。イテレーションごとに品質が劣化するので、ウォーターフォールの方が、品質が良いという世界になる可能性があるのです」

というのも、品質にかける費用は30年間変わっていない。つまり、どんどんソースコードのサイズが増えているのにも関わらず、コストは変わらず人員も増えないために、品質が下がっていくのである。

バグは一定の確率で起こるもの。その大きなバグの海の中で、QAやテスターは、いかに大きなバグを素早く除くか。そのための戦略およびテクノロジーが必要になってくるという。

「例えば、Googleは効率的にバグを見つけるテクノロジーを持つ会社の1つです。Googleにはテスターはいませんが、バグを除くテクノロジーは世界トップレベル。開発者がコードを書き、自分が担保する自動化コードをクラウドのコンポーネントにプルリクエストし、自動で何回もビルドを回している。これは僕らが学ぶべきテクノロジーです」

バグはすべて取ることはできないことを前提に、有限の時間の中で最適品質を探す。そのため膨大なシステムテストは行わず、上流（単体テスト）で効率的なテストを自動で実施し、CI/CDに流していく。つまり上流での単体テストをいかに効率的にやっていくかというのが一番、重要なことなのだと高橋氏は強調する。

「2週間から最大4週間のスクラムの中に、単体テストやレビュー、リファクタリングを入れ、毎日、自動でテストを実施しCI/CDに流して、日々の品質の状況を定量的に把握できるようにする。そんな仕組みを整えることが必要だと考えています」

上流品質の担保は網羅率だけでは実現できない

単体テスト、リファクタリング、要求仕様のテストケース展開という3つのアクティビティをしっかり実施することで、上流品質は担保される。だが、単体テストは網羅率を担保する必要があるため、C0網羅を70～80％に持って行くのは至難の業だ。

「C0網羅を70～80％に持って行くことをあきらめてしまう方は多いです。ただ、実はそこまでする必要はありません。ソフトウェア全体の2割をテストすれば、大方品質は担保される。つまり2割の部分に8割のバグが潜んでいるのです」

では「どこにバグが潜んでいるのか」というと、最も怪しいのがよく変更されるファイル。その他は、長いファイル、複雑度の高いファイルである。基本はファイル単位で、関数単位ではない。その2割の部分に注力し、ファイル単位で単体テスト計画を立てる必要がある。

ホットスポット概念には、バグキャッシュなど、亜流を含めていろいろある。だが、適切なやり方を実施すると、ポリシー的にバグを見つけることができると高橋氏は指摘し、自身が使っているチャートを示して、解説を行った。

「バグが見つかるということは、網羅率を担保できていることとニアリーイコール。こういう形で利用するのがよいと思います」

直近でホットスポットをチャートで出して、リファクタリングするターゲットを決めて、開発者に対して指示を出す。市場バグは突然出るものではなく、単体テストやシステムテスト内で致命的なところから出るものだという。

「こうしたチャートを書き、どういうところからバグが出るのか、ホットスポット値を測ると、市場バグがどこのファイルから出るのかが、高い確率で解るようになります」

「単体テストは網羅率が重要だという話をしましたが、実はそれだけでは十分ではありません。以前、単体テストの網羅率が100％という会社があったので、ソースコードを見てみたら、単に網羅しているだけで、期待値チェックがゼロでした。テストケースが適切に書かれているかどうかという指標も重要になります」

例えば、2017年のGoogleでの単体テストの網羅率の中央値は78％。Googleでは網羅率75％を推奨しているが、許容範囲は60％をとしている。網羅率の低い会社は、まず60％を目指していくのが手だと高橋氏はアドバイスする。

「網羅率は担保しているが、期待値をチェックしていないという企業や組織には、ミューテーションテストをお勧めします。これは境界値を網羅し、単体テストが適切かどうかをチェックする、テストの品質自体を評価するテスト手法。ソースコードに人為的にバグを仕込み、テストが失敗するかどうかを検証します」

検証テストが失敗した場合は、実行したテストがバグを検知できる能力があるということ。ミューテーションテストは2000年代初頭からある手法だが、アジャイルで単体テストが増えている今、注目を集めている。

「すでにツールも登場しており、オープンソースのPitestなどはその一例です。JavaやSwift、Shellなどの言語のプログラムで使えます」

最後に高橋氏は次のようなメッセージを語り、講演をまとめた。

「単体テストを行えば、チームの仕事は減ります。テスト担当者の仕事が減り、みんなでテスターがバグを見つける文化はなくなっていく。チームの中でどう戦略的にバグを見つけていくか、話し合いながら品質を上げていくことが重要です。

現時点では、上流品質の定量的な指標がありません。ソフトウェアテストが始まって以来のパラダイムシフトが起こっている今だからこそ、最新の海外事例などを学ぶ必要があります。今回の講演が、ソフトウェアの品質を上げることのモチベートになれば幸いです」

【Q&A】質問タイムはディスカッション方式で実施

今回のQ＆Aは、モデレータの高木陽平氏とのディスカッション方式で語られた。大変多くの質問が寄せられたので、その中からいくつか抜粋して紹介する。

Q．ユニットテスト（UT）、システムテスト（ST）について

高木：それでは視聴者からの最初の質問です。「ユニットテスト（UT）だけ積み上げても、イテレーションはビジネス要件だけになるので、システムテスト（ST）がいるのではないでしょうか。」

高橋：それは正しいと思います。アジャイルではユーザーストーリーという形でユーザーの要件をイテレーションの中で積み上げていき、それがテストされます。ユーザーストーリーに入らないビジネス要件の一部や非機能要件は、システムテストをした方がよいでしょう。システムテストは下流でやると非効率なので、なるべく少なくする。それが品質を上げるコツだと思います。

高木：ユーザーストーリーやビジネス要件は、V字モデルでいうとシステムテストになると思うのですが、それをUTでやるというイメージが結びつきません。

高橋：V字モデルの要求仕様は、多くの部分が単体テストで網羅できると考えているからです。例えばソースコードの単体テストはもちろん、機能がちゃんと実装されているかどうかも単体テストでチェックできます。

高木：それでは次の質問です。「STは工程の最後に実施されます。XP、Test Firstの流れがあるのに、なぜでしょう。」。これは、「アジャイルでは、ゴールの品質として出荷していいかという判断など、そのメトリクスをどう定めるかはまだ解っていない」と説明した時の話ですね。

高橋：ケント・ベックの「XPエクストリーム・プログラミング」、「Test First」などの文献を読むと、Test Firstもケント・ベックが定義したペアプログラミングもやるべきだけど、そこに定量的なものはありませんでした。

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

高橋：定量的なものは、ウォーターフォール時代からある網羅率しかないと思います。

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

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

高橋：基本的には指標はありません。バグトラッキングツールもありますが、各組織で定義した方がよいと思います。銀行系のシステムとAndroidのゲームでは致命的なバグの概念は変わってくるので、各組織の中で定量的に決めて定量的に測っていくことが重要なアクティビティです。

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

高橋：僕はISTQB（International Software Testing Qualifications Board：国際ソフトウェア資格認定委員会）の委員を務めており、そこでは網羅率ベースのUTと単機能ベースのUT双方と定義されています。自社内で網羅率ベースでも良いし、単機能ベースでもよい。今回の話は、UTは網羅率ベース、関数ベースの話になります。

Q．自動化が難しい領域でのテストについて

高木：コネクテッドなどのモビリティ領域や、決裁システムなどの自社内で完結しない多数のプロダクトの連携など、自動化が難しい領域でのテストは今後どうなっていくと思われますか。

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

例えばNetflixは、システムに障害が起こってもサービスを継続するためのテストツールChaos Monkeyを導入しています。システムが複雑にコネクトされているものは、そのようなアプローチが重要になりますが、各コンポーネントで最低限の単体テストはやる必要はあると思います。

高木：疎結合を目指して、アーキテクチャでコネクテッドの部分は防ぐ考え方ですね。

高橋：今は疎結合、マイクロアーキテクチャという方向に行っているので、品質を担保するいいアーキテクチャに向かっていると捉えています。

高木：「ここでの「単体テスト」とは、主に関数ベースのユニットテストだけのことを指しているわけではなく、ストーリー（ユースケース）ベースのE2E自動テストも含めているから、イテレーションの中でも機能要件のテストもできるという意味合いですか。」

高橋：完璧な姿はホワイトボックステストベースで単体テストを行い、ユーザーストーリーベースの機能確認を単体テストでする。その組織はすごく洗練された組織だと思います。

Q．リファクタリングのやり方について

高木：「リファクタリングをしないといけないところは、なかなか手をつけられない複雑怪奇なところだと思う。その辺はどうすればうまくリファクタリングができるのでしょうか。」

高橋：リファクタリングは積極的にやってほしいと思います。複雑度が20％を超えると、修正成功確率が50～60％になり、複雑度が40％になると成功確率は20～30％となります。複雑度が40％を越えると、リファクタリングしようがしまいが、バグの確率はイコールとなります。

高木：リファクタリングにかける工数や期間は、イテレーション内のうちどのくらいの割合で行った方がいいですか。

高橋：より大きな時間を取りましょう。リファクタリングの工数はみなさんが思うより大きいからです。

高木：イテレーションが進んでくるとその割合は変わってくるのでしょうか。最初はシンプルに作っていても、機能を追加するごとにだんだん複雑になる気がするのですが。

高橋：組織の成長度合いにもよります。複雑なソースコードを持っているところは積極的にリファクタリングをしましょう。成熟した組織では、機能追加したときに複雑度が20を超えたときに、その担当者が自動的にリファクタリングする。リファクタリングしないとプルリクが通らないというような、開発プロセス基準を決めることをお勧めします。複雑度を測るツールは、SoneartQubeなどがあります。

Q．開発における必要なテストとそのタイミングについて

高橋：開発に必要なのは、単体テストとユーザーストーリーに対してイテレーション内でどうやって担保しているかをチェックすること。イテレーションが基本的に積み重ねていくので、どんどんユーザーストーリーのテストが積み上がっていきます。単体テストも含めて、最後のイテレーションではすべての単体テスト、全てのユーザーストーリーが完了することになります。

高木：デプロイパイプラインにその辺のテストを組み込んでいくという形ですか。

高橋：そうですね。CI/CDサービスの「CircleCI」の中に、単体テストを組み込むのは比較的やりやすいかもしれません。

Q．アジャイル開発の品質に関して上長を納得させるコツ

高木：「アジャイル開発で品質に関して、上長を納得させる論理的な説明のコツはあるか。ウォーターフォールでは、バグ曲線等で論理的にバグがつぶせているので大丈夫と言えるのですが」という質問です。

高橋：ウォーターフォール時代よりも、アジャイルになるとさらにメトリクスがとれる量は減っています。組織においてユーザーストーリーに対してテスト、単体テスト、ミューテーションテストの結果を上長に報告するしかないですね。

高木：スプリントレビューに上司を入れて、動くところを見てもらうというプラクティスになるのでしょうか。

高橋：最初の段階から上司を入れるというのがアジャイルのメリットなので、今のところはそういう回答になると思います。

Q．単体テストで大部分の品質を保証できるという考えに至った背景

高橋：僕は品質保証ができてソースコードがバリバリ読める人でした。市場バグのほとんどのソースコードを見たところ、単体テストで潰せるという経験があったからです。そこで単体テストをちゃんとやった方が良いという結論になりました。

高木：QAは品質の作り込みにシフトするというイメージでしょうか。

高橋：僕は共に歩むというイメージを持っています。バグを見つける集団ではなく、一緒に品質を上げていくチームになることです。そのためのスキルを身につけることが、QAの生き残る術になっていくでしょう。

株式会社AGEST
https://agest.co.jp/
※2022年4月1日 株式会社デジタルハーツからスピンアウト

株式会社AGESTの採用情報
https://agest.co.jp/recruit/career/

株式会社AGESTエンジニアブログ
https://engineers-blog.agest.co.jp/