はじめに
Developer＆Designer Advent Calendar 2024 4日目の記事です🎁
こんにちは、QAエンジニアの吉満です。現在、プロセス管理部という部署で、開発プロセスや品質状況の可視化、品質課題の改善支援などを行なっています。
今回は、ISTQBという国際的なソフトウェアテストの資格認定団体がまとめたシラバスから「テストの原則」を紹介したいと思います。
ISTQB（JSTQB）とは
ISTQBとは、International Software Testing Qualifications Board（国際ソフトウェアテスト資格認定委員会）の略称です。ソフトウェアテスト技術者の育成を目的に設立され、世界約130カ国の人たちが認定資格を取得されています。ISTQBのシラバスは、学会や業界を代表するテストの専門家によって作成され、ソフトウェア テストにおいて信頼できる体系的なナレッジを、すべての人に無料で提供しています。JSTQBは、日本におけるソフトウェアテスト技術者資格認定の運営組織です。
認定資格を受けなくても、公開されているシラバスはどなたでも閲覧可能です。少しでも興味を持たれた方はアクセスしてみてください。
- ISTQB Certified Tester - Foundation Level Syllabus v4.0（原文：英語）
- ISTQBテスト技術者資格制度 Foundation Level シラバス（日本語訳）
ちなみに、パーソルキャリア テクノロジー本部では、組織の品質文化を現場レベルから醸成していくを目的に、JSTQB FLシラバスを題材とした「QA輪読会」を半期に一度開催しています。
今回ご紹介する「テストの原則」もQA輪読会の学習内容に含まれています。
テストの原則
「テストの原則」とは、ソフトウェアテストを行う上で共通して理解しておきべき考え方です。
それでは、7つある「テストの原則」を順に見ていきましょう。
原則１：テストは欠陥があることは示せるが、欠陥がないことは示せない
1. Testing shows the presence, not the absence of defects.
いくら準備したすべてのテストを実施したとしても「システムにこれ以上バグは存在しない」とは言えません。今回実施したテストケースで「たまたま」故障しなかっただけかもしれません。また、テストを実行する条件（入力値、回数、環境など）を変更したら新たに見つかる欠陥があるかもしれません。
この原則を踏まえ、実際の開発現場ではどうすべきかというと、テストを実施した際は、「どういう目的で、どの範囲について、どんな条件でテストしたのか」その結果「どのような欠陥を、どのくらい検出したのか」という情報は必ず残すようにしましょう。その情報により、どこの品質をどのくらい担保できたのかという証明になります。
原則２：全数テストは不可能
2. Exhaustive testing is impossible.
限られたリソースで、すべてを網羅的にテストすることは不可能です。一見シンプルに見えるプログラムでも、入力値のパターン、正常系、異常系を組み合わせるだけでも、かなりのケース数になります。それでは、どうすれば良いのか？というと、JSTQBシラバスでは次のように書かれています。
全数テストの代わりに、テスト技法、テストケースの優先順位付け、リスクベースドテストを用いて、テストにかける労力を集中すべきである
テスト技法、優先順位付け、リスクベースドテストについては、シラバスの別の箇所に詳しく記載がありますが、これらのアプローチを使って、効果的・効率的にテストしましょう、ということです。ソフトウェアテストの効率を高めるうえでは「テスト技法」の活用は欠かせません。テスト技法には、「ブラックボックステスト技法」「ホワイトボックステスト技法」「経験ベースのテスト技法」の３つのタイプがあります。ここですべてを説明すると長くなってしまうので、また別の機会にご紹介できればと思います。
原則３： 早期テストで時間とコストを節約
3. Early testing saves time and money.
「開発プロセスの早い段階でテストして欠陥を見つけましょう、そうすれば、時間とコストが節約できます」という原則です。こちらは、皆さんも開発現場で意識されているのではないでしょうか。「シフトレフト」というアプローチが有名ですが、まさにそれです。
JSTQBシラバスでは次のように書かれています。
早い段階で欠陥を見つけるために、静的テストと動的テストの両方をなるべく早い時期に開始すべきである
ここに出てくる「静的テスト」とは、ソフトウェア開発成果物（要件、要求、設計、コードなど）のレビューのことです。（静的解析ツールも含まれます）静的テストでしか検出できない欠陥もあります。静的テスト、動的テスト、それぞれの特性を活かして、開発プロセスの早い段階に組み込むことで、欠陥を早めに検出することができ、結果的に開発コストの削減に繋がっていきます。
原則４：欠陥の偏在
4. Defects cluster together.
欠陥はソフトウェア全体に均一に存在するのではなく、偏って存在するという原則です。
テストで見つかる欠陥や運用時の故障の大部分は、少数のシステムコンポーネントに集中する
ある研究によると「ソフトウェアの欠陥の8割は2割の箇所に集中して存在する」いわゆる、パレートの法則を示しているそうです。では、どうすれば、欠陥の多い箇所が分かるのでしょうか？それが分かれば、効率的に欠陥を取り除けますよね。
そのためには、まず、欠陥の傾向を観察することです。不具合管理と不具合分析を継続的に行うことが大切になります。欠陥の偏りに基づいて、テスト箇所を絞り込んで、効率的に欠陥を見つけましょう。
原則５：テストの弱化
5. Tests wear out.
同じテストを何回も繰り返すと、新たな欠陥の検出に対する効果は薄れてくる
テストで発見した欠陥を修正するから、プログラムはそのテストケースに耐性を持つことになる、そりゃそうだよね、というのが初めて知った時の感想でした。
続けて、シラバスにはこのように書かれています
この影響を克服するため、テストとテストデータを変更したり新規にテストを作成したりすることが必要になる場合がある
新たな欠陥を検出するためには、テスト条件やテストデータを定期的に見直したり、新たにテストを作成することが有効である、ということです。テストを見直したり、新規作成するリソースがなかなか確保できないという場合は、「探索的テスト」というアプローチを活用するのも有効です。探索的テストは、ドメイン知識があり経験豊富なテスト担当者であれば、余裕のないテストスケジュールの中でも効果的に欠陥を見つけ出すことができ、非常に有効なアプローチです。
原則６：テストはコンテキスト次第
6. Testing is context dependent.
この原則は「状況が異なれば、実施するテストや方法、狙うべき品質が変わる、コンテキスト（事情や背景）によってテストの方法を変える必要がある」ということです。
テストに唯一普遍的に適用できるアプローチは存在しない
低品質すぎるのも良くないですが、高品質すぎるのも良くありません。リソースは有限なので、QCDのバランスを考え、適切な品質を狙ってテストすることが大事になってきます。
具体的には、まず「このシステムは、どのようなユーザーが、どういう目的で、どういった環境で、どのように使うのか、また、どのような品質が求められているのか」コンテキストをしっかり理解し分析して、そして、それに合ったテストアプローチを決めて、テスト計画に落とし込むことが大切です。
原則７：「欠陥ゼロ」の落とし穴
7. Absence-of-defects fallacy.
落とし穴ってなに？ 欠陥ゼロって良いことですよね？ どういうことでしょうか。
JSTQBシラバスでは次のように書かれています。
検出した欠陥すべてを修正しても、ユーザーのニーズや期待を満たさないシステム、顧客のビジネスゴールの達成に役立たない、およびその他の競合システムに比べて劣るシステムが構築されることがある
これは、テストで見つけた欠陥をすべて修正した（欠陥ゼロになった）からといって、必ずしも品質が良くなるわけではないよ、ということです。例えば、ある欠陥を修正するためにデータベースを大幅に書き換えたとします。ところが、データベースを書き換えたことにより動作が遅くなってしまいました。欠陥はゼロになりましたが、遅くて使いものにならないとクレームが入れば、また別のインシデントとなります。欠陥を修正することは大切ですが、修正を行う際に、機能や性能、システム全体に影響はないか、また、欠陥を修正することがユーザーの期待に合っているかを考えることも大切です。
以上が、テストの7つの原則、になります。
さいごに
過去に参画したプロジェクトの話になりますが、そのチームでは、プロダクトがグロース期になる頃に、市場障害がじわじわ増加傾向にありました。
そこで、テスト内容を確認したところ、機能拡張や利用者数の増加などによりプロダクトの規模や状況は変わったのに、テスト条件やユーザーシナリオはPMF期のままメンテされていないというテストが点在していました。そこで、現在のプロダクトの状況に合わせて、機能間やシステム間で見落とされたテスト観点を増やしたり、テスト条件を見直したところ、リリース前に欠陥が検出でき、リリース後に見つかる不具合が徐々に減少傾向になりました。まさに「テストはコンテキスト次第」「テストの弱化」を実感したエピソードになります。
もし、今のテストや品質に課題があるなと感じたときは、テストの7原則を思い出してみてください。
最後までお読みいただき、ありがとうございました。
それでは、以降のアドベントカレンダーもお楽しみにー！
吉満 恵子 Keiko Yoshimitsu
テクノロジー本部 ITアーキテクチャ統括部 プロセス管理部 リードエンジニア
2023年QAエンジニアとしてパーソルキャリアに中途入社。3人の子育てに日々奮闘中、キャリアオーナーシップを持ってお仕事することが日々の目標です。
※2024年12月現在の情報です。
