久々にテスト行程について本を読んで学んでみたPt1
読んだ本
なぜ読んだか
- ソフトウェアのテスト行程や用語に興味が湧いてきたから
- 入門書を探していた
- ソフトウェア開発工程の知識を深めたいから
- QAとアジャイルについての知識を深めたいから
- インプット=>アウトプットしたいから
ここで記載する内容
- 気になった各章の内容や、浮かんだ疑問点など
(振り返った時に何を思ったか見返しやすいように) - 各章を読んでみての感想
2章 : ソフトウェアテストの基本
| Title | Detail |
|---|---|
| ホワイトボックステスト | プログラム内部の論理構造のみをテストする |
| ブラックボックステスト | プログラムをブラックボックスと見立てて、様々な入力を行うテスト(コードは利用しない) |
| 制御パステスト法 | コードカバレッジを担保するテスト |
| ステートメントカバレッジ | 制御パステスト法の一種で命令文の動作をチェックするテスト |
| ブランチカバレッジ | ステートメントカバレッジより網羅性の高いテストで条件分岐に対して、True , falseの結果を少なくとも一回は検証する |
コードカバレッジ基準
-
何%で担保できたと言えるのか？
一般の商用ソフトウェアなら 60~90% で十分とのこと。
実際には60%くらいのテストを実施した状態で出荷されている
ケースもあるとのこと。。。 -
汎用的な計測方法はなにがあるのか？
| ステートメントカバレッジ |
| ブランチカバレッジ |
- カバレッジテストでカバーされないコード
| エラー処理(ほとんど起こり得ないエラー) |
| 使用されていないコード |
- カバレッジテストで検出できないバグ
| 因子 | 理由 |
|---|---|
| ループ処理 | テスト担当者がループがどこにあるのか不明 |
| 仕様自体の誤り | 矛盾のあるシステム仕様だとテスト漏れが起きる |
| データに関するバグ | マルチタスクや割り込みに関するもの |
-
カバレッジテストの罠
カバレッジテストと、非機能テストは別の指標軸として網羅率を設ける必要がある。
カバレッジテストはコストがかかるため、予算立てを行う必要がある。
100% に近づくほど、テスト費用は等比級数的に増加する。 -
TDDについて
TDDの本質はスピードを持って開発し変更に対して耐性を持つこと。
TDDにより、開発者には単体テストを行う時間がないという言い訳を作らせないw (先にテストコードを書くため)
章を読んでみて
この章を読んでて気になったのが、テスト担当者と開発者間でのテスト担当領域。
そもそもこの章で言ってるカバレッジ(網羅率)がテスト担当者が行ったテストと、開発者自身が行っている単体テストを合わせてカバレッジと書かかれているから、少し混乱した。
実際の現場だとテスト担当者(QA)と開発者(PG)での担当領域が曖昧で、コミュケーション不足によってテストに抜けが出てバグを見過ごしたりっていうケースが多そう。。。そのためQA・PG共に仕様の認識合わせを行いながら、担当可能領域を共有しておく仕組み作りが必要で、そのためにスクラム開発でPBLを通してリファインメントを行ったり、して、QAとPGでの認識齟齬を減らす仕組みづくりが必要なんだな〜。
3章 : ブラックボックステスト
- ブラックボックステスト(振る舞いベース)
| Title | Detail |
|---|---|
| 同値分割 | 入力領域を同値クラス(有効・無効同値)という部分集合に分割してテストを行う |
| 境界値分析 | 主に裏で動いている条件分岐処理が仕様通りの条件になっているのか確認するテスト(閉包関係バグ) |
| デシジョンテーブル | 仕様に対してどのような状態を取り、どういった結果が起きるのか、組み合わせを列挙するテスト |
| 状態遷移テスト | 操作に制限が加わっているのが仕様通りか確認するテスト |
- ホワイトボックステスト(内部構造ベース)
| Title | Detail |
|---|---|
| 制御フローテスト | 制御フローのテスト |
| データフローテスト | データの状態遷移テスト |
- そのほかのテスト
| Title | Detail |
|---|---|
| エラー推測 | 経験則によるテスト |
| 探索的テスト | 対象の製品を学んだ上でテスト設計し実行するテスト |
| 非機能テスト | 仕様にない、動作・処理速度やUXなどのテスト |
章を読んでみて
ブラックボックステストにおいても、システムや実装する機能の大きさなどによって、テストする量が肥大化していくので、スクラム開発を取り入れている組織であればQA側もスクラムに参画することにより、スプリント毎に区切って
テスト設計・実装・テスト実施を行えるので、テスト量の調整を行い業務負荷の調整管理も出来るはず。(大量の手動テストは気持ちが折れるので...)また、テストする範囲を細かく分けることで、動作検証するなかで(手動テストの場合)、仕様上の矛盾や不具合などの早期検知につながりそう。
書籍によると、ブラックボックステストを行う際には以下の順序でテストを行ってバグを潰していくとのこと。
- 境界値 : 入力フィールドがある場合
- デシジョンテーブル : 入力フィールドが「複数」ある場合
- 状態遷移 : 状態遷移がある場合
今回はここまで。
Discussion