テストの知識乏しいから「知識ゼロから学ぶソフトウェアテスト」を読んでみた。 #テスト

はじめに

この記事は「知識ゼロから学ぶソフトウェアテスト」を
読んでみて、自分に足りていないテスト観点や
テスト手法などをアウトプットするために記事にしてみました。
よろしくお願いいたします。

本の紹介

今回読んだ本は 「知識ゼロから学ぶソフトウェアテスト」 です。
著者　高橋寿一さん
下記にアマゾンリンクを張っておきます。
知識ゼロから学ぶソフトウェアテスト

想定されている読者

テスト経験がない方
テスト初心者
テスト経験はあるが、テストの基礎的な観点が抜けている方
責任者としてプロジェクトのテストを任された方

※今回の記事は投稿主が初心者というのもあり、初心者向けの記事となっています。

私が本を読むときに意識した目的

テストを行う上で必要な観点を学ぶ
具体的なテスト手法を学ぶ

上記の2点に沿ってこの本についてまとめていきたいと思います。

1テストを行う上で必要な観点

テストを行う上で考えなければいけないことがあります。

どのように完ぺきな仕様書を作成しても、バグは存在する。
すべてのバグを消そうとするテストは多くの時間、人員、コストがかかる。

これらの考えを踏まえてアプリケーションを作成すると完璧を追求することが難しくなります。
ですのでアプリケーションを作成するときは ~~「完璧」~~　ではなく　「十分な」　品質を作るようにしましょう。

では次にどのような方法で 「十分な品質」 を確保していくのかご紹介していきます。

2どのようなテストをするべきか

前章で十分な品質を確保すると記述しました。
ですが、十分な品質とはどのようなことをテストすれば「十分なテスト」なのか？
この本の著者が進めている3つのテスト技法を紹介していきます。

ブラックボックステスト
探索テスト技法
非機能要求テスト

ブラックボックステスト

概要
ブラックボックステストとはソースコードの中身を見るのではなく、
実行結果のみで仕様を満たしているかどうかを確認する手法。
※基本的にはテストを導入する場合この手法を取り入れることが多い。
※実行結果のみで仕様を満たしているか確認するため、仕様に書かれている条件などは考慮するが、コードの条件分岐などは考慮しない。
メリット
実行結果のみでテストを行うことができるので、テストケースの削減などが行える。
テストを品質を確保するのに適している手法
具体的な手法
- 同値分割法
- 境界値分割法
- 境界値分割法(説明は割愛)
- 状態遷移テスト(説明は割愛)
- ランダムテスト(説明は割愛)
同値分割法
テストする際、条件の入力領域を同値入力クラスという部分集合とみなし、同値クラス内の値はすべて正しく実行できたとみなしテストしない手法。

言葉だけだとわかりにくいので、同値分割法の具体例を記載していきます。

テストケース
aとbがそれぞれ100以上300以下であることをテストする場合

aとbがそれぞれ100以上300以下を同値分割法を使って行うテストケース

テストケース1　150,150
テストケース2　0,0
テストケース3　-10, -10
テストケース4　400,400

aとbがそれぞれ100以上300以下を同値分割法を使わないで行うテストケース

テストケース1　150,150
テストケース2　0,0
テストケース3　-10, -10
テストケース4　0, 150
テストケース5　-10, 400
テストケース6　150, 0
テストケース7　400,-10
テストケース8　500, 150
テストケース9　150, 500 
テストケース10　400,400

上記のように同じ同値クラスのテストは行わない手法のことを同値分割法という

境界値分割法
処理の中に条件文が組み込まれている際に用いられる。
条件が仕様通りに作成されているかを条件に一番近い無効入力や有効入力をテストする方法
条件に一番近い値をテストして、バグが発生しやすい箇所のバグ発生を防ぐ方法

言葉だけだとわかりにくいので、境界値分割法の具体例を記載していきます。

テストケース
aとbがそれぞれ100以上300以下であることをテストする場合

aとbがそれぞれ100以上300以下を境界値分割法を使って行うテストケース

テストケース１　150,150
テストケース２　100,100
テストケース３　300, 300
テストケース４　99,99
テストケース４　301,301

上記のように同じ同値クラスのテストは行わない手法のことを境界値分割法という。

※同値分割法と境界値分割法をそれぞれ分けて、テストケースを作成したが、
本番では二つのテスト手法を混ぜて使うことがおすすめである

探索的テスト

概要
事前に固定的にテストケースを作成するのではなく、ソフトウェアの振る舞いを見ながら実施者が柔軟にテストの内容を作成、調整していく方式。参考リンク
メリット
テストを実行しながら、他の部分に問題がないかを考えて、そこをテストすることができる。
　　ソフトウェアの弱いところが見つかったら、そこに重点を置きテストを行うことができる。
具体的なやり方
- ターゲットを明確にする
  →どこをテストするか
- 機能を洗い出す
  →テスト対象の機能を洗い出す。
- 弱いエリアを洗い出す
  →データ交換が発生する箇所やあまり使わないと思われる複雑に組み合わさったデータを入力
  エラーや例外処理からの復帰機能
- テストと記録弱いエリアを重点的にテストする。
  →弱いエリアなどの観点を踏まえて、テストを実行していく。
- 継続的なテストの実行

3非機能要求テスト

概要
非機能要求テストとは機密性や信頼性、パフォーマンスなどの品質特性を確保する手法。
具体的なやり方
- アーキテクチャバリデーション
  →ソフトウェアがアーキテクチャ的に十分なパフォーマンスを発揮しているかをチェックする。
  　DBの処理能力が要求仕様に合致しているかを机上で確認する。
  　実際にプロトタイプのソフトウェアを作成して、処理ができるかを確認する。
- パフォーマンスベンチマーク
  →実際に開発されたソフトウェアのテストを行い、パフォーマンステストを実施する。
- パフォーマンス回帰テスト
  →プログラムが開発途中に変更がなされた場合にはその都度を行う。
- パフォーマンスチューニングとアクセプタンステスト
  →最後に作成した、ソフトウェアが要求定義に定められたパフォーマンスを出しているかどうか確認する。
  ※要求より下の場合は出荷しない。

まとめ

この本ではわかりやすくどのようなテストを実践すべきかまとまっていました。
またこの本は砕けた言葉遣いで書かれているので、
知識があまりない自分にもかなり入ってきやすいないようとなっていました。

今回紹介したのは本の一部でしかないです。
初心者ぶ向けた部分やプロジェクトのテスト責任者の方向けの内容が他にも多く盛り込まれていました。
ですので、気になった方はアマゾンのリンクや書店でぜひ手に取って読んでみてください。

※今回アウトプットを目的に作成しましたが、見落としている誤字脱字などがあるかもしれません。
もしありましたら、ご指摘のほどよろしくお願いいたします。

そして最後まで読んで下さり、ありがとうございました。

テストの知識乏しいから「知識ゼロから学ぶソフトウェアテスト」を読んでみた。