「ソフトウェアテストの教科書 [増補改訂 第2版]」批判 〜2章 ソフトウェア開発の流れとテスト工程とは〜その2
はじめに
本記事は「ソフトウェアテストの教科書 [増補改訂 第2版]」という本について、ひとりのDirty Tester目線で批判する記事です。
本書はソフトウェアテストを勉強する上で入門書として紹介されることが多いですが、私の観測範囲内では批判的な意見を持っている人をよく見ます。
私もそのうちの一人です。
本シリーズでは具体的にどこが、どのように疑問を持つかを明らかにします。
それによって以下の効果を望みます。
初学者の人が批判的な視点でこの本を読み、テストエンジニアとして成長する
この批判によって、より有益な第3版となって世に出る
本当に「ソフトウェアテストの教科書」に相応しい書籍になる
さまざまなテストと分類へのクダ
さまざまなテストと分類
「ソフトウェアの内部構造に注目する/しない」による分類
「ソフトウェアを動作させる/させない」による分類
「ソフトウェア開発の工程」による分類
概ね「テスト技法の種類」「動的/静的テストの違い」「テストレベル」という分類になっていますね。
これは悪いとは言わないですが、手段、手段、工程となっていて、ややバランスが悪く感じます。
他の区分けがいいとは思っていないですが、以下のような区分けもあるよ、と初学者向けに紹介しておきます。
テストレベル=対応する開発工程やテスト対象の結合度
テストタイプ=まとまったテストの目的
テストプロセス=テストのタスクや活動のセット
みたいな感じで分けてる人もいます。
「ソフトウェアの内部構造に注目する/しない」による分類
「内部構造」って難しくない？と思ったりします。
「コードに着目する」でいい気もします。
ブラックボックステスト(略)入力と出力のみに注目して、ソフトウェアが正しく動作するかを確認するテストの総称
ダメってほどでもないですが、例えば状態遷移テストは内部変数とかでトリガーを決めたりするので、「入力と出力のみ」は言い過ぎかなと思いました。
「ソフトウェアを動作させる/させない」による分類
これは完全に重箱の隅ですが、静的テストについて、「ソフトウェアを動作させることなく行うテスト」だと、ツールによる静的テストが初学者にとってよくわからないことになりそうです。
なので、「テスト対象を動作させない」くらいがいいかなと思いました。
「ソフトウェア開発の工程」による分類
各テストを「ソフトウェア開発の工程」を基準にして分類すると、大きく「開発工程」と「テスト工程」のいずれかに分類できます。
大雑把すぎる気がしますが、テスト屋さんから見たらそうなんだろなーという感じがします。
レビューとは(略)開発工程でのテストといえる
別にいいですが、この区分けだとTDDは開発工程ではないのかな？と思いました。
テスト工程ではさまざまなテストが行われる。通常、テスト工程で行われるテストのことを「ソフトウェアテスト」と呼ぶ
通常ってなんなんだ。
テストの概要
開発工程で行うテスト (レビュー)
レビューだけじゃないよ！
レビュータイプについてはとりあえず違和感なかったです。
机上デバッグ|ソフトウェアのソースコードを目視確認し、検出した誤りを修正する作業。ソースコードの作成者自身が1人で確認・修正することが多い
これを静的テストに入れるのは無理があるよ！
別に開発工程で動的テストにしてもいいじゃん！！
テスト工程で行うテスト (単体テスト)
機能確認テスト※2| 1つひとつのモジュールが詳細設計や機能仕様書どおりに動作することを確認するテスト
※2 本書ではテスト工程の「機能テスト」とテストの一種である「機能確認テスト」を異なる用語として表しています。機能テストは、機能ごとにテストするといった、テスト対象の規模単位を表しています。一方、機能確認テストは、仕様に記載された機能が正しく動作しているかを確認するといった、テストの目的を示しています
早速無理してないですか？！
モジュール単位まで自然言語で仕様化されていて、それを単体テストするのは現実としてあり得るのかなあと思ったりします。(あるか)
「仕様書の対応関係」だけでテスト工程(テストレベル)を識別しようとするから、こういう無理が生まれます。
データフローテスト|データや変数が「定義」→「使用」→「消滅」の順に行われているかを確認するテスト。静的解析ツールなどを用いる
内容はいいかもしれないですが、バイザー本の定義そのまま持ってきていません？
静的解析ツールは静的テストな気がするし、テスト工程なのかーという気はします。
テスト工程で行うテスト (結合テスト・機能テスト)
状態遷移テスト
状態遷移テストはいろんなテスト工程で使えそうです。
結合テスト・機能テストだけではないと思いますよ。
機能確認テスト(略)詳細設計書どおりに動作することを確認するテスト
「仕様書の対応関係」だけでテスト工程(テストレベル)を識別しようとするから、こういう無理が生まれます。（2回目）
テスト工程で行うテスト (システムテスト)
確認テスト|一度テストされている事項を再度確認するテスト。次のように細かく分けてテストする場合もある。
修正確認テスト(略)
リグレッションテスト(略)
スモークテスト(略)
リリースチェックテスト(略)
「確認テスト」という言葉を使ったことないですが、ここに入れるのかーという感じがします。「再テスト」ではないのは目的が異なるからかな？
評価テスト|単純に⚪︎×で判定しにくい品質に対して程度を判断するテスト。次のようにさらに細かく分けてテストする場合もある。
セキュリティテスト（略）
ユーザビリティテスト（略）
障害許容性テスト（略）
全部判定するテストな気はする。性能テストさん入れてあげてー
負荷テスト|動作しているソフトウェアシステムに負荷をかけて行うテスト。次のように(略)
性能テスト（略）
ロングランテスト（略）
大容量テスト（略）
記憶域テスト（略）
高頻度テスト（略）
負荷テスト（略）
負荷テストの種類に負荷テストがあるのはいいのか。
ここまで自由に定義するなら「悪条件テスト」とか自由な名前で名付けしたらいい気がしました。
機能確認テスト
またお前か
テスト工程で行うその他のテスト
探索的テスト|テスト担当者が自らの経験をベースに行うテスト
これは審議。
個人的には、「テスト対象から学びながらテスト設計・テスト実行をパラレルに実施する手法やスタイル」ですかね。
リスクベースドテスト
モデルベースドテスト
ミューテーションテスト
それぞれテストマネジメントの手法、テスト設計の手法、テストに対するテスト
テスト実行の性質や目的を示すものではないです。
これは探索的テストと混ぜずに説明した方がいいと思いました。
総括して
すみません。この章はまだまだ長いので終わりませんでした。
総括して、「教科書における体系化を行なった」という印象でした。
かなりオレオレ定義だなーと思いました。
テストタイプに状態遷移テストがあるなら、機能テストにデシジョンテーブルテストもあっても良くない？と思ったりしました。
次回はまだ気になるテスト工程とテストフェーズについてです。
この記事が気に入ったらサポートをしてみませんか？