はじめに
仕事で開発・運用をおこなっている大規模なWebアプリケーションがオンプレミスからクラウドへ移行することに伴い、テストの業務をおこなうことになった。用意されたテストケースを黙々とこなしていく日々を送っていたが、「これでは潜在的なバグに気づくことができないのではないのか？」と不安に感じ、一から勉強してみることにした。知識を定着させるために記事として残す。
ソフトウェアテストとは？
開発したソフトウェアが期待していた通りに、仕様書通りに、想定通りにちゃんと動くのかをチェックするためにおこなうテストのこと。「一生懸命時間をかけて開発したのに、リリース後にデグレがあちこちで起こっちゃって障害になっちゃったー」なんてことが起きないよう本番環境リリース前に最大限バグがないかチェックするような感覚で思っていただければおそらく大丈夫。仮にバグがあったら該当箇所を探しソースコードを修正する。
ソフトウェアテストの7原則
テストを実施する前に開発担当者やテスト担当者が理解しておくべきガイドラインのこと。心構えみたいな感覚を持っておくと良いかと。JSTQB（Japan Software Testing Qualifications Board）というソフトウェアテスト技術者資格の運営組織が公表しているので、一つずつ引用して紹介、自分の解釈も少し載せる。
原則(1) テストは欠陥があることは示せるが、欠陥がないことは示せない
テストにより、テスト対象に残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、テスト対象の正しさを証明できない。
テストによってバグを見つけることができたとしても、これ以上他にバグがないことの裏付けにはならない。「バグが見つかる＝テスト成功」と思うのは非常に危ないかもしれない。
原則(2) 全数テストは不可能
すべてをテストすることは、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、テスト技法、テストケースの優先順位付け、リスクベースドテストを用いて、テストにかける労力を集中すべきである。
考えられる挙動・パターンを全て洗い出して（カバレッジを100%にする）テストすれば、理論上欠陥を見つけることができる可能性は高くなるが、コストと時間の制約を考えるとあまりにも効率が悪い。仮にできたとしても、ソフトウェアの仕様そのものが間違っていた影響で正常に動作しないこともあるため、リスクとってやるようなことでもないように思える。
原則(3) 早期コストで時間とコストを節約
プロセスの早い段階で欠陥を取り除くと、その後の作業成果物で
は取り除かれた欠陥に起因する欠陥を引き起こすことはない。
原則(4) 欠陥の偏在
通常、見つかる欠陥や運用時の故障の大部分は、少数のシステムコンポーネントに集中する。この現象は、パレートの法則を示している。予測した欠陥の偏在、および実際にテスト中または運用中に観察した欠陥の偏在は、リスクベースドテストの重要なインプットとなる。
システムの至るところにバグが少しずつあるというよりは、局所的に集中して存在していることが多い。（特定の部分に新たなエラーが存在する確率とバグの数は比例している、というデータもある）
原則(5) テストの弱化
同じテストを何回も繰り返すと、新たな欠陥の検出に対する効果は薄れてくる。この影響を克服するため、テストとテストデータを変更したり新規にテストを作成したりすることが必要になる場合がある。しかし、例えば、自動化されたリグレッションテストのように、同じテストを繰り返すことが有益な結果を示すことができる場合がある。
「殺虫剤のパラドックス」との紹介をしている記事も多く見かけたが、要するに二度も三度も同じ手は効かんぞという意。同じテストケースばかりだと新しいバグも発見できなくなってくるので、開発者やユーザーなど様々な観点からテストを設計・作成する必要がある。
原則(6) テストはコンテキスト次第
テストに唯一普遍的に適用できるアプローチは存在しない。テストは、
コンテキストによって異なる方法で行われる
ソフトウェアそれぞれが持つ特性を見極めた上でテストをおこなうことが大事。
原則(7)「欠陥ゼロ」の落とし穴
ソフトウェアを検証するだけでシステムを正しく構築できると期待することは誤り（つまり、思い込み）である。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、ユーザーのニーズや期待を満たさないシステム、顧客のビジネスゴールの達成に役立たない、およびその他の競合システムに比べて劣るシステムが構築されることがある。検証に加えて、妥当性確認も実施すべきである。
バグがない＝高品質 とは必ずしも言えない。品質とは機能性だけで判断するものではなく、セキュリティ対策や性能といった非機能要件も考慮した上で評価をされる。
ホワイトボックステスト
システム内部の構造（ソースコードやプログラムそのもの）に重点を置いて確認し、正常に動作しているかチェックをおこなうテストのこと。
代表的な手法
- 制御フローテスト
- 主にソースコードの条件分岐に着目をして、想定通りの動きをするかをチェックする方法。重要度や複雑さにもよるが、基本的には全ての処理経路を通り実行できるようなパターンを組み、カバレッジを少しでも高く設定する必要がある。
- デシジョンテーブルテスト
- 全ての入力の組み合わせを表などで洗い出して、その結果の動作を一つ一つ記述していくやり方。デジタル回路設計の際に用いる真理値表を思い浮かべると理解を助ける。
ブラックボックステスト
システム内部を1個のブラックボックスと見立てて、様々な入力をおこなうことによってソースコードを利用せずにテストをおこなう手法のことである。アプリケーションの内部構造を理解していなくても実施は可能である。テスト対象の詳細設計やソースコードなどの正しさを検証するホワイトボックステストとは対称的な立ち位置をとっている。
種類
- 機能テスト
- アプリケーションが仕様通りに動作するかをチェックする
- 非機能テスト
- パフォーマンスやセキュリティ等（非機能面）に異常がないかをチェックする
- リグレッションテスト
- アプリケーションにおこなった変更によって機能が損なわれていないかチェックする
代表的な手法
- 境界値分析法
- 分岐の際の境界となる値に絞ってテストする手法。「x>0」の場合は、x=0とx=1の条件でテストする、ような感覚。想定される結果を得る際の狭間の条件。
- デシジョンテーブルテスト
- ホワイトボックステストと同じ。
まとめ・要点
- ソフトウェアテストとは、期待通りにシステムが動作するかチェックをすることであり、実施方法は多岐にわたる。
- バグをテストで全て見つけ出す方法は確立されていない為、ソフトウェア全てでバグをなくすことは不可能だと思われる。
基本的な内容を書いただけなので、詳細はまた別の記事に書こうと思う。
参考文献
- ソフトウェアテストとは？種類や目的、重要な7原則を紹介
https://service.shiftinc.jp/column/3621/ - 知識ゼロから学ぶソフトウェアテスト第3版 アジャイル・AI時代の必携教科書
https://www.shoeisha.co.jp/book/detail/9784798182452 - テスト技術者資格制度 Foundation Level シラバス
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf