テストって奥深い
普段何気なく行っていたテストですが、テストの世界でも色んなメソッドが研究されており、アメリカでは大学でソフトウェアテスティングの授業があると知り、驚きました。
ソフトウェアテストの奥深さを知り、ファウンデーションレベルですが、調べたことをここに残します。
テストとは？
ソフトウェアテストは以下の2種類に分かれます。
1. 動的テスト
これは仕様通りに、お客さまの要望通りにソフトウェアが機能するかのテストです。
アプリケーションの機能をチェックする機能テストと、機能上は不可欠ではないが、ユーザーの快適度に影響する（例えば高負荷がかかった時の挙動や、ユーザビリティ）機能をテストする非機能テストがあります。
2. 静的テスト
ソフトウェアが動く前の段階のテストです。ソースコードや要件定義のレビューがこれにあたります。
テストとデバッグの違い
テストとデバッグって、同じ概念と思ってましたが、どうやら違うようです。
テスト
テストとは、「ソフトウェアの故障を発見すること」です。
デバッグ
デバッグとは、「故障のもととなる欠陥を見つけ、解析し、取り除く作業のこと」です。
エラー・欠陥・故障の違い
エラー
エラーとは、ソフトウェアテスティング界では、「人が犯す誤りのこと」だそうです。
欠陥
欠陥とは「故障の基となるもの」のことです
故障
故障とは、ソフトウェアを動かした結果、意図した動作がされないことを言います。
テストの7原則
テストには7原則があるようです。
1.テストは欠陥があることを示せるが、欠陥がないことは示せない
テストがうまくいっても、欠陥がないことの証明にはならないので要注意。
2.全数テストは不可能
全てをテストすることは、単純なソフトウェア以外無理。なので、優先度を決めてテストを行う。
3.早期テストで時間とコストを節約
要件定義のレビューや、ソースコードレビューを早期に行うことで、早い段階で欠陥を見つけることができ、作業の出戻りが減り、コスト節約にもなる。
4.欠陥の偏在
欠陥や故障の原因は特定の少数モジュールに集中する。
5.殺虫剤のパラドックスに気をつける
同じテストは繰り返すたび、殺虫剤のように効力が低減する。テスト内容は同じものを何度も繰り返すのではなく、定期的に見直す必要がある。
6.テストは状況次第
状況が変われば、テストの方法も変わる。
7.バグゼロの落とし穴
表向きのバグが0でも安心してはいけない。ユーザーが「このアプリ使いにく！」と思ったり、後発のシステムなのに競合のシステムに劣ったり、そういうことをなくすための努力を惜しまない。
障害報告書の書き方
書く内容は以下
1.わかりやすいタイトル
2.障害発生日時
3.障害復旧日時
4.障害内容 → 実行した手順を明確に記す！
5.影響範囲
6.問題発生の経緯
7.暫定対応と恒久対応
8.原因と再発防止策
書き方は以下
1.できる限り具体的に書く
2.誰にでも伝わる表現で書く
3.事実と推測を明確に区別する
以上がソフトウェアテストについて学んだことでした。
参考記事：https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J03.pdf