バグだらけのシステムをどうテストする？ ソフトウェアテスト第一人者がPMとして考えるべきテスト戦略を伝授

アーカイブ動画

テスト分野のプロフェッショナルたちが、テスト戦略を語る

今回講演を行った高木氏は、独立系の開発会社でプログラマ、SEとしてキャリアを積み重ねながら、CMMI内部監査員を経験。その後、東京理科大学大学院MOT（技術経営学科）に進み、ナレッジマネジメントを学んできた。

その後、プライムソリューション（開発会社）やSHIFT（テスト専門会社）のIoTセクションの立ち上げ、さらにはVALTES ADVANCED TECHNOLOGY INC.取締役を歴任している。

JSTQB完全上級技術者（テストマネージャ、テストアナリスト、テクニカルテストアナリスト）、ISO29119 Certified Tester等を取得。著書には「はじめてのテストプロセス改善 ソフトウェアの「バグをなくせ」と言われたら？テストプロセス改善でバグを削減しよう」、訳書（共訳）には「ISO/IEC/IEEE 29119 ソフトウェアテスト規格の教科書」がある。

高木氏が本部長を務める株式会社AGESTは、2022年に株式会社デジタルハーツのエンタープライズ事業部門を分社化し、品質コンサルティング・テストソリューション事業などに特化した戦略的子会社である。グループミッション「SAVE the DIGITAL WORLD」、AGESTのビジョンとしては「先端品質テクノロジーで、すべてのDXに　豊かな価値と体験を。」を掲げている。

株式会社AGESTのボードメンバーであり、ソフトウェアテストの第一人者として知られる高橋寿一氏も高木氏とのQ&Aセッションに登壇。バグに頭を悩ませているPMにとって、非常に有意義な情報がもたらされた。

株式会社AGEST
CTSO（Chief Testing Solution Officer） 高橋 寿一氏

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

PMがより良い結果をもたらす「リスクベースドテスト戦略」とは

今回高木氏が紹介したのは、リスクに応じて、強いテストと弱いテストを使い分ける「リスクベースドテスト戦略」。致命的なバグを防ぎ、限られた時間で最大の効果を発揮するテスト戦略の一つである。

なぜ、リスクベースドテスト戦略が有効なのか。JSTQB（Japan Software Testing Qualifications Board）が提唱している「ソフトウェアテストの7原則」の4原則目に挙げられているのが「欠陥の偏在」。そこには次のようなことが書かれている。

「リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う」

高橋寿一氏の著書「知識ゼロから学ぶソフトウェアテスト」には次のように書かれている。

「ソフトウェアテストでも、『2：8の法則』は当然成立する。同じテストを実行するのではなく、常に弱い部分を想像し、実行を繰り返しながらソフトウェア構造的に弱いバグの多い2割の部分を見つけ、8割のバグを出し切ることが非常に重要である」

高木氏はハインリッヒの法則を例に、2割の部分に致命的な不具合が発生する可能性は低いと説明する。ハインリッヒの法則とは、「1件の重大事故の裏には、300件のヒヤリハット、29件の軽微な不具合が発生する」という法則である。

「もちろん2割の部分に不具合がゼロというわけではありませんが、可能性が高いところに集中する。やらないことを決めることが、非常に重要なのです」（高木氏）

リスクが発生しやすい箇所とリスクの評価方法

システムのどこにリスクが発生するのか。高木氏はSQA総合研究所真野俊樹氏による調査結果、ソフトウェアのテスターJames Bach氏の著書、高橋寿一氏の著書からリファレンスを紹介した。

真野氏が不具合と関連のあるパラメータを統計学的に調査したところ、「開発規模」「開発難易度」「開発者のスキル」という3つにリスク発生との関連性を発見。James Bach氏は「複雑度」「新規性」「変更」「上位依存度」を挙げている。高橋寿一氏は「複雑度」「ホットスポット値」がリスクになるという。ちなみにホットスポットとは、一定期間におけるファイルの変更量である。

またGoogleのバグ予想モデルにおいても、一定期間におけるファイルの変更量がバグの発生に影響していると述べている。さらに、ソフトウェアメトリクスの第一人者であるCapers Jonesは不具合を直すと20％の確率で新たな不具合を生むことを指摘しており、一定期間内のファイル変更量がバグを生む一つの根拠であると紹介した。これらのことから、高木氏は「スキル」「境界」「難易度」「ホットスポット」を4大リスク・スポットとしてまとめた。

スキルは、未経験・新人・スキルアンマッチングなどが原因となる。境界は、OSやミドルアプリケーションとの上位依存や下位依存、API・インタフェースなど、技術的な境界だけではない。他社・他部門・他チームとの連携箇所という人との境界も含まれる。さらには年齢制限が「以下」なのか「未満」なのかという、境界値もリスクスポットとなる。

難易度に関しては、技術の新規性や複雑性、規模など。ホットスポットは先述したように一定期間のファイルの変更量。仕様の変更や曖昧量、人の変更・関与量なども該当する。

次は、リスクの評価の方法である。「リスク度＝可能性＋影響」「リスク優先度指数＝重要度×優先度×発生確率」「リスクスコア＝発生率×影響」など、実は評価方法にはいろいろな手法がある。

「どの方法でもよいと思うが、Reid氏の方法はシンプルで使いやすいので、オススメします」（高木氏）

いずれの方法とも3段階（高・中・低）による評価となっている。もう少し段階を増やしてほしいという要望も多いが、高木氏はこれまでの経験から「細かく評価しても、時間がかかるだけで正確性は向上しません」と言い切る。

つまり評価の厳密性よりも、皆で協議して納得性が得られることの方が大事なのだという。

強いテスト、弱いテストとは？

PMBOK/ISO31000によると、リスク対応の方法は「低減」「回避」「受容」「転嫁」の4つに分けられる。確率と影響の高いプロジェクトは「回避」する、もしくはできる人にやってもらうなどの代替案を出すことと説明されている。

逆に確率と影響が低い場合は「受容」となり、そのリスクを受け入れることになる。影響は高いが、確率が低い場合は「転嫁」となり、保険を掛けたり、多重化をしたりという方策を巡らせることになる。それ以外のところは「低減」となり、ソフトウェアに当てはめるとテストを実施することになる。

「テスト戦略はリスク低減が基本戦略。確率と影響を受容できる範囲まで低減することです」（高木氏）

テストの強度とリスクの関係を表すと、次の図のように、その強度によって強いテストと弱いテストに分けられる。確率と影響の高い場合は強いテストを実施し、確率と影響が低い場合は弱いテストを実施する。

ではこの強いテスト、弱いテストとはどういうことなのか。それを考える前にまず認識しなければならないのが、テスト設計のプロセスである。

ISO29119のテストの設計プロセスでは、次のように4段階で表されている。

1. テストモデルを構築する
2. カバレッジアイテムを特定する
3. テストケースを導く
4. テスト手順を作成する

テストケースを実施する際は、意味のあるグルーピングをして同値分割をして行うことが重要だ。高木氏は、ユーザー名が正しいかどうかのテストを具体例として解説する。

ユーザー名が有効なのか無効なのかで分かれるところは、カバレッジレベルは1となる。このときには有効なユーザー名と無効なユーザー名を1つずつ選んで、2つのテストケースになる。これをさらに深掘りしていくと、文字数や文字種でわけることができる。

文字数は有効最大文字数、中間の文字数、有効最小文字数が発生する。文字種は日本語、アルファベット、記号、数字があり、これらもカバレッジレベルとなる。テストケースはこれらの組み合わせとなるので、指数関数的に増えることになる。

さらに日本語を分割するとカタカナ、漢字、ひらがな、アルファベットとなる。これも単一なのか複合なのかなど、カバレッジレベルが下がれば下がるほど、テストケース数は増えていく。このような強弱をリスクによって使い分けるのが、リスクベースドテストになる。

「リスクが高まれば強いカバレッジレベルでテストを実施し、低いリスクであればカバレッジレベルを低くする。論理的な手法のテストです」（高木氏）

テスト戦略で決めなければならないこと

テスト戦略では、いつ、どこで、どのように、どれだけを規定するかを決める必要がある。

テスト対象がWebサービスだとしたら、要素技術がバックエンド、フロントエンド、マイクロサービス、クラウドなど。開発ライフサイクルはウォーターフォールかアジャイルかなど。テストレベルは受け入れテスト、システムテスト、結合テスト、単体テスト…といった具体だ。

さらに機能テストや脆弱性診断、ホワイトボックステスト、リグレッションテスト、静的テストというようなテストタイプも決めていくのである。

「要素でバラバラに実施する人もいますが、きちんとつなげてトレーサビリティを取っていくことが肝要になる」と高木氏は強調した。

リスクベースドテスト戦略では、プロジェクトの内容によるが、要件定義・設計工程、製造工程、テスト工程、運用・保守工程で分けてテスト戦略を策定。要件定義・設計工程では、レビューを実施することが多いと高木氏。この工程のレビューではインスペクション、テクニカルレビュー、ウォークスルー、ピアレビュー、セルフレビューなどの種類がある。

「効果も高いが工数がかかるので、リスクによって使い分けることもポイント」（高木氏）

また上流工程でテスト設計をすることで、設計部分での要件をチェックすることができ、手戻りが少なくなる。W字モデル、ADD（アセット・ドリブン・ディベロップメント）、BDD（ビヘイビア・ドリブン・ディベロップメント）などの手法がある。

モックアップを作成するという方法もある。リスクの高いところでは電子プロトタイプ、そこまで不要な場合はペーパープロトタイプで作成することも有効だ。

製造工程では、コードレビュー（テクニカル、ウォークスルー、ピアレビュー、セルフレビュー）やペアプログラミング（モブプログラミング、ペアプログラミング、バディプログラミング）、CI/CD、TDD（C0、C1）、リファクタリングなど、リスクに応じて実施する。

テスト工程のテストアプローチとしては、要件ベースドテスト、モデルベースドテスト、観点ベースドテスト、強化テスト、リグレッションテスト、探索的テストなどがある。要件ベースドテストは、要件をどのぐらい網羅しているかについてのテスト。モデルベースドテストは、要件をモデル化して、その状態遷移をテストする。

観点ベースドテストは、不具合を観点にして行うテスト。強化テストは、あぶり出された弱点に対して強化するためのテスト。リグレッションテストは、リスクのあるところに対して行うテスト。探索的テストは、経験ベースのテストである。

もちろん、これらのテストを実施する際は、テストの強度（テストモデルやテストカバレッジ）、順序も考えることが必要になる。

運用・保守の工程のテスト戦略としては、リグレッションテストが挙げられる。リグレッションテストにはスモークテスト、サニティテスト、フルリグレッションとある。そのほかにも、ログの埋め込み、運用監視についても、リスクに応じてパラメータを調整したり、自動化するという戦略が考えられるという。

「戦略とは何をやって、何をやらないかを決めること。KKD（カン、経験、度胸）を活かしつつ、エンジニアリングで致命的な不具合を防いでいきましょう」（高木氏）

高橋氏と高木氏による「ソフトウェアテスト」に関するQ&Aセッション

この後、高橋寿一氏が登壇。事前アンケートでは、多くの人からソフトウェアテストにおいて苦労しており、質問が多数寄せられた。いくつか抜粋して紹介する。

Q．ソフトウェアを開発する上で、重要なスキルや学習とは？

高木：解になっているかどうかはわかりませんが、慶應義塾大学の渡辺宙志（ひろし）先生は、「アウトプットにするためには10倍のインプットが必要になってくる」と言っています。インプットを増やさない限りはアウトプットの質は上がってこないということ。

だが今は1のインプットに対して1のアウトプットをしたいという要望が増えています。例えば資格を取得しても、使えるまでに技術が昇華できていないと、その資格は活かせない。まずは自分が携わっている技術、ドメイン知識についてのインプットを増やすことが重要だと思います。

Q．アジャイルにおけるリスクベースドテストの要求管理はどうすればよい？

高木：ある意味、アジャイルはリスクベースド。各イテレーションで重要な機能から作り、早い段階で動かしていくからです。それ自体がリスクヘッジとなる。素早いリリースができるのはアジャイルの特長ですが、それもリスクの考え方なので、アジャイル自体がリスクベースドテストの重み付けに通じるところがあると思います。

Q．リスク予想が外れたときは、どのように説明すればよい？

高木：リスクが外れたときの説明については、事前の予測と動的な予測をうまく使っていくことだと思います。事前予測は限られた情報の中で行うので、外れる場合もあります。やっていく中で情報が明らかになり、新たなことを知り得て、習熟度が上がっていく。そのときに調整できるようにすることが大事だと思います。

上司への説明に関しては、平均的なテストを実施して「ここはリスクが高いのでテストを厚くします」と伝えるといいのではないでしょうか。

高橋：具体的な対応内容を聞くと理解しやすいと思いますので、洗い出したリスクとそれへの対応の事例を紹介してください。

高木：あるWebアプリケーション開発で、リスクが高いと思われるものに対しては並行で探索的テストを実施。テストを厚くするという事例がありました。

技術的負債が溜まったアジャイル開発の事例では、技術的負債を返済するため、今までの不具合を分析して2割の部分を特定し、強化テストを実施しました。

Q．短いイテレーションの中で効率的にリスク分析するには？

高橋：アジャイル開発は要求仕様がどんどん変わるので、イテレーションの期間が短くなると思います。短い工程の中で効率的にリスク分析をするアイディアがあれば教えてください。

高木：リスク分析やリスク評価というと、仰々しくやってしまうことが多いのですが、その辺も時間との兼ね合いで調整することが重要です。例えば同僚とお茶を飲みながら、「この辺にリスクがありそうだよね」と話すのも、立派なリスクの評価だと思います。形式張ってやる必要はないと思います。

高橋：「バグ＝ミス」という考え方の人をどうやって納得させますか？

高木：人間は完璧ではないので、ミスすることもあります。ただシステム的に防げるところは、多分にあると思います。凝り固まった人を説得するのは至難の業なので、「そうですね。何とか対処します！」とやり過ごすのも一つの手だと思います。

Q． ローコード・ノーコードのプログラミングが普及すると、バグは出なくなる？

高木：モデルベースドテストと同じで、モデルを作るテストは不要になると思います。しかし、他のサービスやシステムとの連携部分の品質保証は必要ですね。

高橋：私もそう思います。膨大なレビューが発生し、範囲が広いと飛ばさざるを得ないところも出てくると思いますが、観点レビューについて何かいいアイディアはありますか。

高木：一つの見極め方としては、誰が作ったのかという観点が必要です。もう一つの方法としては、階層サンプリングをして全体の不具合を求めていく方法です。

高橋：範囲が広いときは、何らかの当たりを見つけて、そこを重点的にレビューすることが重要になります。人はレビューされると思うと構えるもの。レビューをすることで、プレッシャーを与えることも重要です。

高木：寿一さんの書籍では、それが評価に繋がるようなことはやめましょうと書かれていましたね。

高橋：バグを憎んで人を憎まずなので。ただその情報をマネジャーとして把握しておくことは大事だと思います。

Q．今後のリスクベースドテストの方向性について

高木：リスクの判定や評価は、AIや機械学習などと組み合わせていくのではないでしょうか。動的なものに関しては、かなり正確な判定や評価ができるものが出てくると思います。

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

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