書評ソフトウェア開発において切っても切り離すことのできないのが不具合(バグ)。そのバグと表裏一体な存在がテスト。プロジェクトマネジメントをするうえで、テストを適切に工程へ組み込むことは非常に重要なことですが、PMがテストの中身を全く把握していないのは良くないと思い、「知識ゼロから学ぶソフトウェアテスト」を読んでみました。この本、本当に知識ゼロでも読むことができるのでお薦めです。見るソフトウェアテストの実力診断この本は「完全無欠なソフトウェアテストは可能か?」という問いかけから始まります。完全なソフトウェアテストが難しいものであるかを示すために下記の演習問題が出題されます。ーザーが三つの整数を入力します。それぞれ三角形の3辺の長さを表すものとします。このプログラムをテストするのに十分と思われる一連のテストケースを書いてください。テストケースのイメージ、湧きますか?僕もこの問題にチャレンジしてみたので、参考まで三角形の判定プログラムとそのテストコードを貼っておきます。※Node.jsのMochaとChaiで書きました。思いますか?これで適切にテストパターンの洗い出しが出来ていると思いますか?...残念ながら答えは「いいえ」です。0"とユーザーが入力した場合でも、正三角形と判定されてしまいます。これは正しい挙動とは言えません。して実際に自分でやってみるとテスト設計の難しさがよくわかります。専任の経験あるテスト担当者がいなければ、品質を担保して製品をリリースすることは難しいでしょう。次に実際にどのようなテストが行われるべきなのかを見てみたいと思います。ブラックボックステストブラックボックステストは、プログラムを一種のブラックボックスと見立て、さまざまな入力を行うことによって、ソースコードを利用せず(見ずに)行う、というものです。本によれば、現在のソフトウェアテストの大半はこの手法が使用されているとのこと。詳細を見てみましょう。分類テストケースを書く同値分割とは、入力領域をいくつかのクラスに分けて、そのクラスの中の値は同値とみなす行為です。いうようにクラス分けできると思います。次に、有効同値と無効同値ですが、システム仕様から見て、有効な値か無効な値かという意味です。「文字」「記号」ということになります。最後にテストケースを書いていきます。三角形判定プログラムは、入力値が三つの整数だけで、無効同値も2種類しかありませんので、全ての有効同値と無効同値の組み合わせの強固なテストケースが書けると思います。実際のプログラムでは、無効同値の数や組み合わせ数が多く、テストケースを作ることが困難なこともあります。その場合は、テストケースを省略せざるを得ませんが、だからと言ってバグが起きても良いわけではありません。入力領域の境界に焦点を置いてテストを行う手法です。三角形判定プログラムでは、そもそも仕様が「三つの整数」としてあるのが問題でもあるので、整数の境界に焦点を置くのはあまり良いアイディアではありません。ここは三角形が成り立つ数値か?というところに視点を切り替えるべきでしょう。すると、入力領域は整数の中の「正の数(1以上の数値)」となります。正の数の境界はどこか考えてみましょう。下の境界は簡単ですね。0以下は正の数ではなくなります。上の境界はどうでしょうか。正の数に上限はありませんので、数値はどこまでも大きくなります。仕様ではどこかに上限を設定しておくべきだと思います。実際のテストでは、異なる処理が行われる一番近い2地点を用います。三角形判定プログラムの下の境界で言うと、「0」と「1」です。この境界値分析法と同値分割法を組み合わせることで、効果的かつ効率的にテストケースを作ることができます。ディシジョンテーブルディシジョンデーブルは、すべての入力の組み合わせとそれに対する出力を表にまとめたものです。出力結果が変わります。組み合わせの複雑になるので、それらを表に可視化することで、漏れを防ぐことができます。同じですが、多数の入出力をチェックするときに有効な手段となります。自分の書いたコードでやってみました。本プログラムでは、各三角形ごとの組み合わせの入力値を書いてまとめた方がわかりやすいかなと思いました。本では、状態は「TRUE」「FALSE」だけの記載でしたが、実態に合わせて臨機応変にしても良いと思います。まあ散々な結果ですね。状態遷移テスト状態遷移テストは、状態によって出力結果が変わる場合に用いられるテストです。いうイベントのときに、どのように状態が遷移するかを一覧にし、各遷移をチェックしていくというものですが、この三角形判定プログラムの例では説明できそうにありません。詳細は下の記事がよくまとまっているので参考にしてください。ランダムテスト(モンキーテスト)これはランダムにソフトウェアを操作し、バグを洗い出すテストです。著者はこの手法に関しては、批判的な意見を持っているようで、推奨していませんでした。テスト設計の必要もないし、一定数のバグは見つかるだろうが、バグはランダムテストでは見つからないところにまだまだ潜んでいると。以上がブラックボックステストの手法として紹介されているものでした。状態遷移テスト」は、どのソフトウェアにおいても最低限実施すべきものだと思います。ランダムテストについては、個人的にはそこにテスターの労力を割くのであれば、別のテストを実施した方が良いと思いますね。まとめ本では、ブラックボックステスト以外にも「探索テスト」「非機能テスト」「セキュリティテスト」などの重要なものが説明されています(詳細はぜひ本をお読みください)。月並みな感想ですが、テストの奥深さと難しさに驚きました。プログラムを書くこと以上にテストを作ることの方が難しいのではと思ったぐらいです。品質要求を満たしたプロダクト、不具合のないプロダクトを出すために必要な労力を改めて認識し、今後のプロジェクトマネジメントに活かしていきたいと思います。22:21「知識ゼロから学ぶソフトウェアテスト」でテストの基本を学ぶTweet広告を非表示にする関連記事2018-12-282018年を振り返ってあっという間に2018年も終わりですね。最新記事アプリ開発の市場で勝つにはどうすれば良いのか調べてみた2019年を振り返ってヒンディー語の音読、リピーティング、シャドーイングが簡単に練習できるアプリを作ってみたヒンディー語のスピーキングが練習できるアプリを作ってみたヒンディー語文法と言語学習のおもしろみプロジェクトマネジメントとプロダクトマネジメントの棲み分けとその組み合わせプロジェクトにおけるタスク管理の大事な3つのポイントヒンディー語の文字(デーヴァナーガリー文字)を学習するアプリを作ってみた月別アーカイブはてなブログをはじめよう!takuya0206さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。