今まで理解していなかったが体系的に勉強する
デバッカーとしておよそ十年やってきたが、ソフトウェアテストについてふわりとしか理解していなかった。不足している観点や不足している試験がどこに存在するのか体系だって理解していなかったため、本来であれば設計段階でつぶせていた障害もあるような気がする。このおりソフトウェアテストを勉強しようと考えネットでいくつかの資料を探していたところ割とドンピシャのものが見つかったのでそれを速攻で購入した。それを用いて体系的に勉強することで基本的な試験ケースをもれなく抽出することで基本的なミスによる不具合をなくすことができるのではないかと考える。
テキストは3つ購入し、UdemyのISTQBの講座と、この一冊でよく分かるソフトウェアの教科書とソフトウェアテスト技法練習帳。ソフトウェア技法練習帳に至っては2年間積読となっており、今になってみれば一刻も早く読み解いておく必要性がある一冊だった。過去は戻らないので、今勉強して行くことにする。ひとまず「この一冊でよくわかるソフトウェアの教科書」で勉強し、以下に理解した内容を記載していこうと思う。
システムテストについて。
テストの目的は二つあり。一つはシステム仕様通りに製品が作られているかを確認する。もう一つがその性能が妥当であるかを検証する一つ目の方は割と実施されているが、2つ目はほとんどされていなかったりするしテスト終盤でそこに気づいたとしても、修正されることも実装されることもあまりない。そのため、早めに見つけておく方が望ましいのだが、なかなか難しい。
一つ目のシステム仕様書通りに製品が使われているかを確認する部分においても。不足している観点や網羅性が低い試験が多数ある。しかし一般的に言われる部分でも全くまるっと抜けてることも結構あり、今回勉強することで、その観点が抜けなくなることで、応用情報とか取るよりJSTQB（もしくはISTQB）を取得していた方が圧倒的に身になっていたのではないかと思う。
テストカバレッジについて。
テストが網羅的に実施されているかは、テストカバレッジという指標で確認することができる。カバレッジには3種類があり。命令。デシジョン、要素の複合で確認する方法。命令はフローチャートで命令を網羅できるだけの経路をテスト策定すればOK、デシジョンは、分岐をすべて通るようテスト策定でOK。要素の複合は、分岐の際、複数の要素があれば、その要素それぞれについて確認する必要がある。
境界値テスト
読んで字のごとく境界値を確認するテストで3以下は〇、4以上10以下は△、11以上は□となるようなものをテストする時、その境界値をテストするもの。プログラムを組む際、<や>、=の有無を仕様書と間違えたりするため、バグりやすい。例の場合は3,4,10,11を確認すればいい。マイナス値がエラーならその境界についても確認する。
デシジョンテスト
デシジョンテーブルを作成し、それに基づいて試験を行う。条件を書きだして総当たりで試験する感覚になる。条件が増えると指数関数的に増える。大きくなりすぎないよう適度に単機能に分ける必要がある
状態遷移図と状態遷移表
状態遷移図を作成し、それをもとにテストを作成する。まず状態遷移図をどうやって作ればいいんだ、どういうときに状態遷移図作るんだという話もあるが、名の通り、状態が遷移する時に作成する。ボタンを押すとお湯が出て、もう一回押すとお湯が出るのが止まるとかそういうものである。この遷移図はイベントと状態を書きだして、そこからどう遷移するかを図にしていくといい模様。テストを作る際はその表を元にテストを作れば遷移のある全イベントを網羅することは容易になる。問題は遷移のないイベントで、停止中に停止ボタンを押すようなものである。場合によっては遷移が発生するかもしれないが、何も発生しないが正のことが多いだろうが、これをテストするには状態遷移図や仕様書等から状態遷移表を作成してテストを作成する。
組み合わせテスト
様々な条件の組み合わせを行った場合に障害が発生しないかをテストする。条件が増え、網羅的にテストを行おうとすると指数関数的に試験条件が増えるが、2要素を組み合わせた場合まででほとんどのバグは検出できるらしい（体感でもほぼそうではある）というわけで2要素を網羅するテストを作ることをめざす。と言っていると本質的ではないが、効率よくバグ検出を行ってソフトウェア品質を向上する。オールペア法と直行表というのがあるらしい。オールペア法しか聞いたことがない。ツールを使って自動でできるのはオールペア法だけらしい。それはオールペア法しか使われませんね…
どれを適用すればいいのか
ものによる。何をしたいのかによる。
その他忘備録
信頼度成長曲線とかいう進捗を横軸、不具合件数を縦軸に取ったグラフが寝てくると障害がなくなってきたとかいう神話アイテムがあるが、それについても好意的な解釈というかやり方を記載してくれていた。バグの出そうなところから評価することで、バグを先に出して、あとから出そうにないところをテストするという記載があった。まあそれはそうなのだが、それができれば苦労はない。それをするには3つ要素があり、
①テストケースが最初に全てある。
②テスト全体を把握する時間があり、そもそもテストケースからバグが出そうな当たりがつけられる人が把握する必要がある。
③テスト初期からテストケースどれでもテストできる逸材が複数（最低一人）いる
この3要素に不安があっては世の中的にはダメなんでしょうね。たぶん
コメント