ソフトウェアテスト技法ドリルを読み終えて

ソフトウェアテスト技法ドリル

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

テストのやり方が分からず、情報を模索していた時に出会った本です。

他のどの本よりも具体例を交えて実践的に書かれていたので購入しました。

学ぶことが多く、分からなかったことが整理できたので、それをまとめます。

ソフトウェアテストでやるべきこと　（基礎編）

自分がテストをするときの考え方の基礎になったので勝手に命名しました。

単機能テスト

対象機能が仕様通りに動作することを確認します。

やり方としては、機能を構成する入力項目について1項目ずつテストします。テスト対象の入力項目を決めたら、その他の項目には結果が常に真（正常）となる値を設定しながらテストします。その他の項目が常に真となる値にする点がドメイン分析テストに近いなと思いました。

実際に入力値を考える際には、同値クラスを探し、その中から境界値分析をしてすると見つけやすかったです。

組合せテスト

対象機能の処理（論理関係の組合せ）が仕様通りに動作することを確認します。

やり方としては、①仕様として定義されている処理が正しく動作することの確認と、②仕仕様として定義されていない動作の確認に分かれます。

①仕様として定義されている処理の確認

原因結果グラフ、CFD 等のテスト技法で対象機能のチェックなどの論理関係を整理し、論理関係の組合せの結果が仕様通りになるかを確認します。

テストの目的は単機能テストと似ていますが、単機能テストが単一項目の動作に関するテストであるのに対し、組合せテストは入力項目に限らずいくつかの論理関係が組み合わさったときの動作に関するテストと理解しています。

②仕様として定義されていない動作の確認

仕様に記載のない（互いに関連のない）項目同士の組み合わせで意図しない動作にならないかを、HAYST法 やペアワイズ法を用いて確認します。

状態遷移テスト

対象機能、またはシステムに状態がある場合、仕様通りに状態が変わることを確認します。

やり方としては、①状態遷移表、②1スイッチカバレッジ、③2スイッチカバレッジの観点でテストをします。

①状態遷移表

イベントと状態を軸とし、セルに遷移後の状態を記した表で対象機能、またはシステムの状態遷移仕様を表現します。各状態の時にイベントが発生するとセルに記載されている状態に遷移するかどうかを確認します。

②1スイッチカバレッジ

①の状態遷移表で網羅しきれなかった状態遷移について確認します。

ただ、今の課題は行列計算が出来ないので、1スイッチカバレッジ表を作れないこと。簡単に行列計算できる方法を探さないと。

今後のソフトウェアテストで何をするとよいのか

一通りドリルを読んでいくと、開発工程の話が一切出てこないことに気づきました。

状態遷移テストを適用するシーンを考えていてその理由に気づきました。ストップウォッチのように単一機能で状態が遷移する場合もあれば、業務管理システムのように機能間で状態が遷移する場合もあります。だからテストの対象によってどのようなテストをするのかは違うんだと。

絶妙なタイミングでソフトウェアテスト業界で尊敬する方もＲＴをくださりました。

だからこそのテストアーキテクチャ設計。 RT …自分の場合は結合テストに組み込むことができるけど、単機能で状態遷移するなら単体テストでの実施を計画しないといけない…この工程ではこういうテストをするーみたいなのは一概に言えないね。

それでテストは別に開発手法に縛られるものじゃないよな－と思ったわけです。だからテスト対象を知り、どんなテストをするのが適切かを考えることが大事なんだと。

テストの目的が分かっていなかったころはこんな感じでした。

「単体テストってなにやるんだ？」

「結合テストって何するんだ？」

「システムテストってシナリオテストをやればいいんだよね？」

だから今後は次のことをやっていく必要があると考えてます。

対象機能が満たすべき要件や仕様を理解する

それらは何をもって満たされていると言えるかを考える

それはどのようなテストで確認が出来るかを考える

これらを仕事や趣味で実践しながらエンジニアとしてのスキルを上げていきたいですね。