0. 始めに
先週、とある研修に行かせてもらい、ソフトウェアテストに関する基本を研修してきたので、その内容からの抜粋と、プラスして自分が調べた内容をメモとして残すことにする。
1. ソフトウェアテストとは
ソフトウェアはシステムの一部または全体を構成するもの
テストは、ソフトウェア自体ではなく、システムに要求される事項を満たしているかを証明するために実施する活動。
「システムに要求される事項」とは、
- お客様の明示的な要求
- 本来備えておくべき暗黙の特性
- 供給者側が必要とすること
このうち、1番目は機能要件、それ以外は非機能要件と考えることが出来る。
信頼度成長曲線（ゴンベルツ曲線）の横軸
信頼度成長曲線を適切に扱うためには、横軸を見直すべき。大概は「テスト時間」を横軸に設定しているが、実際は**「テスト項目消化件数（テストケース数）」**を設定した方が適切である。
このように設定しないと、理想的な曲線（最初にバグが多く見つかり次第に収束する）にはならず、時間が経つと二次関数的にバグが増える曲線になってしまいがちになる。
7つの一般原則
- テストは欠陥があることしか示せない
- 全数テストは不可能
- 初期テスト
- 欠陥の偏在
- 殺虫剤のパラドックス
- テストは条件次第
- 「バグゼロ」の落とし穴
このうちから一部抜粋する。
初期テスト
テストケースを用いたテストは動作するソフトウェアが既に存在することを前提としているが、テスト活動自体は要件定義や基本設計を行っている段階から適用することが可能。欠陥を早期発見することの大切さが主張されている。レビューをこまめに行うことが最も近道だが、初期段階ではなかなかそうならないという問題にも対処しなければならない。
殺虫剤のパラドックス
同じテストを繰り返すと、最終的にそのテストでは新しい欠陥を見付けられなくなる。このため、テストケースを定期的に見直して、改定する必要がある。
システム・ソフトウェア品質
単に欠陥がなければ品質のよいシステム・ソフトウェアであるというわけではなく、対象とするソフトウェアの特性を実現できているかが重要となる。
クリティカルな特性はシステムによって異なる。品質保証は、クリティカルな特性を実現できていることで達成される。
基準を作る
ISO/IEC 9126を用いて、品質モデルの基準を作成する（1つ1つの項目に当てはめていく形でOK）。ここで作成した基準に対して、現状がどれくらい離れているか、何を達成できていないか、という判断を行う。我武者羅に品質を上げればよい、というものではない。
PDCAは常に回す
PDCAサイクルは常に回すことを心掛ける。要件定義が終わったら1周、実装が終わったら1周、という決まりはない。業務に追われているとついつい振り返りや反省を踏まえた取り組みが蔑ろにされてしまう…
2. 品質計画
ISO9126はソフトウェアの品質を3つに分類する。
利用時の品質の特性
- 有効性
- 生産性
- 安全性
- 満足性
外部・内部品質の特性
- 機能性
- 信頼性
- 使用性
- 効率性
- 保守性
- 可搬性
品質特性には、他に「セキュリティ」、「環境・エコロジー」が含まれる。
非機能要件はテスト機能要件に比べ、テストを入念に実行しづらい。
品質計画の立て方
- 目的に合った目標を定め、計画を立てる
- 品質計画≠監査計画
- 文化や習慣の差異（非対称性？）をなくすため、用語を定義する
- 計画の根拠を明らかにする
3. 非機能要件のテスト
非機能要求グレード
情報処理推進機構（IPA）が公開している。
https://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html
さらに、セキュリティのような未来の予測がつかない脅威などに関するテストは、別の指標が必要になる。
例：https://www.ipa.go.jp/security/vuln/websecurity.html
こういった資料の各項目を埋めていく形で計画を立てることが出来る。