「ソフトウェアテストの教科書」から学ぶテスト技法

# ソフトウェアテストの教科書を読んでみた
- ソフトウェアテストについてスキルアップしたいと考えたが、そもそもソフトウェアテストの技法を知らないし、テスト観点をだすノウハウもほぼない。スキルアップというより、スキルを身につけるところから始めたかったので、まずは基礎的な内容を[「ソフトウェアテストの教科書」](https://www.amazon.co.jp/%E3%80%90%E3%81%93%E3%81%AE1%E5%86%8A%E3%81%A7%E3%82%88%E3%81%8F%E3%82%8F%E3%81%8B%E3%82%8B%E3%80%91%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E6%95%99%E7%A7%91%E6%9B%B8%E2%80%95%E5%93%81%E8%B3%AA%E3%82%92%E6%B1%BA%E5%AE%9A%E3%81%A5%E3%81%91%E3%82%8B%E3%83%86%E3%82%B9%E3%83%88%E5%B7%A5%E7%A8%8B%E3%81%AE%E5%9F%BA%E6%9C%AC%E3%81%A8%E5%AE%9F%E8%B7%B5-%E7%9F%B3%E5%8E%9F-%E4%B8%80%E5%AE%8F-ebook/dp/B00U17809A)を読んでみて、学んだことを整理する。

## ソフトウェアテストの基礎
- ソフトウェアの品質とは
 - **要求を満たすこと、ユーザに価値を提供すること**
- ソフトウェアの品質の定義
 - 品質特性(ISO/IEC 926)にカテゴライズすることで具体的な定義ができる
     - 機能性: ユーザにとって必要な機能が実装されていること
     - 信頼性: 機能が正しく動作し続けること
     - 使用性: ユーザーにとって使いやすく、魅力的であること
     - 効率性: 適切な性能であること
     - 保守性: 修正、機能追加がしやすいこと
     - 移植性: 異なる環境に移しても動作すること

- 品質への意識
 - `Verification&Validation`
     - 開発者の定義した仕様通りに動くこと && ユーザーの要求を満たせていること
 - 狩野モデル
     - 当たり前品質 < 一元的品質 < 魅力的品質

## ホワイトボックステスト
   - 論理構造をテストする。処理の分岐や命令文に着目したテスト技法を`制御フローテスト`、データのライフサイクルに着目したテスト技法を`データフローテスト`と言う。
    
   - 制御フローテスト
    - ソースコードからフローチャートを作成。
         - 論理構造を視覚化するため。
    - 着目するカバレッジ基準を決める。
         - 命令文、分岐、複合条件のどこに着目してテストケースを作成するか決める。
    - テストケースを実施する。

   - データフローテスト
     - ソースコードからデータの`定義→使用→消滅`に着目したフローチャートを作成。
     - どの経路のテストを行うか決定し、テストケース作成。
     - テストケースを実施する。

## ブラックボックステスト
  - テストの目的をテスト品質特性に変換し、特性別にテスト観点を抽出する。
  - 抽出したテスト観点をどの機能に対して適用するか割り当てる。
  - それぞれの機能に割り当てたテスト観点に則して、テストケースを作成する。
  - テストケースを実施する。

## テスト技法について
全てのインプットに対してテストを行うことは不可能。なぜならデリバリの期間は決まっているから。
そのため、不具合を検知するのに効果的なテストのみを実施したい。
そのためのテスト技法について。

- 同値クラステスト
 - ロジックの判定に従って、インプットをグループに分類し、グループ内の代表的な値をテストする技法。
 
 - 判定自体は要求を分析すれば、ロジックを類推する(設計書があるなら設計書を見れば分かる)ことができるが、 それが合理的な実装になっているかは分からないと書籍には記載されていたが、`TDD`で実装すればケースから実装が行われるため、必ずケースに従った実装になる。

- 境界値テスト
 - 同値クラステストに似ている。ケースに使用する値を判定の境界値に焦点を絞って、テストを行う方法。ロジック内の判定の境界に不具合は潜む傾向があるという観点に基づいている。

- デシジョンテーブルテスト
 - 複数の判定条件でアウトプットが変わるような機能の不具合を検知するためのテスト。
 - 下記のようなテーブルを作成し、テストを実施。
 ![デシジョンテーブル.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/301386/eb3c259a-05ab-5241-6cfd-0899a6753ddb.png)

- 状態遷移テスト
 - ソフトウェアが動作する中で変化していく「状態」にフォーカスしたテスト。状態を変化させるきっかけを「イベント」と言う。
 - 状態遷移図： ソフトウェアの状態の遷移を視覚化し、ソフトウェアの仕様の曖昧になっている部分を理解できるようにするための図。状態遷移テストケースを作成する上で約立つ。
 ![状態遷移図2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/301386/8d2be0c1-2dc2-bdae-17b2-40543583b535.png)
 - 状態遷移図を使ってテストケースを作るときは以下の点に従って作成する。
     - 全ての状態を１回は通る
     - 全てのイベントを１回は発生させる
     - 全ての遷移を１回は発生させる
     - 想定するユーザーのシナリオに従った遷移順でケースを作成する
 - 状態遷移表： 状態遷移図の内容を表で表現したもの。状態遷移表は図に比べて**イベントが発生しても遷移しないこと**も表現できる。
![list001t.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/301386/92ade1cf-cfc9-4000-8d95-45310e9f07d9.png)

- 組み合わせテスト
 - 複数の条件を組み合わせて行うテスト技法。全ての条件の取りうる値の組み合わせをテストしようとすると膨大な数のケースを消化することになる。そのため、2因子間網羅の組み合わせでテストを行うことで効率的に不具合を検知できる。2因子間網羅の組み合わせを表現する方法は「直行表」、「All-Pairs法」の二つがある。


## 読了後
- 品質特性は意識しておくと、ロジックがバグっているかどうかを気にするだけでなく、ユーザの要求に応えられる機能になっているか、システムになっているかを考えて、実装できると感じた。
- 単体テスト、結合テスト、シナリオテストを行うときに技法を意識してケースを作成することで、今まで以上に抜け漏れのないケースを作れると感じたが、スキルの習熟が必要。