![見出し画像](https://assets.st-note.com/production/uploads/images/4880238/rectangle_large_6855218c43c9c21cf9da127e55d12a4e.jpg?width=1200)
テスタビリティについての雑感
まず、タイトルと全く関係ないですが。。。
祝Twitterフォロワー数1000達成!
フォロワーが増えれば良いって訳ではないですが、それだけの数の人に伝えたいことが届くようになるってことは、素直に嬉しいです。
![画像1](https://assets.st-note.com/production/uploads/images/4878810/picture_pc_05774576b58fd9e31e1c4e418eaab4c7.jpg?width=1200)
めでたい!ってことで、今日は、もう一本書いておきます。テスタビリティ(テスト容易性、試験性と訳されることもあります)についてです。
とツイートしたとおり、なるほどなとおもったので、一つ一つの特性について自分の解釈をツイートしようと思ったのですが、途中で時間切れでできていませんでしたので残りを書いてしまおうと思います。
実行円滑性(Operability)
観測容易性(Observability)
制御容易性(Controllability)
分解容易性(Decomposability)
テストの対象範囲を小さくできるよう作られていると、手際よくテストができます。単体テストをするときにメソッド単体、クラス単体というサイズでテストをできるように作ってあれば自動テストもしやすいですが、たくさんの依存関係ができてしまっていると、単体テストするにもおおごとになっちゃう。
単純性(Simplicity)
I/Fの数が少ないほどテストケースが少なく網羅できる。サイクロマチック数が小さいほどテストケースが少なくなる。という話と同じだと思います。
安定性(Stability)
変更が少なければ少ないほど、障害が出る可能性が下がるので、テストした時に止まらない。つまりスムーズにテストが進むってことかと思います。自動テストするところは安定したところですしね。
理解容易性(Understandability)
テストベースがしっかり書かれていれば、テストケースを作るのも楽だし、テストの実行時に迷わないってことを言いたいのだと思います。ソースコードが読んで理解しやすければ何をテストすレベ良いか考えやすいっていうのもあるかと。ちゃんと理解できないままテスト実行したら、仕様に書いてあることと違う結果になったとか、テストケースの期待結果に書いてない挙動を示したってなると、調査が必要になってすごくテストに時間がかかっちゃう!
テスト対象を上記視点でレビューできるとテストが楽になる!
本来は、そもそも作るときにこういうことを考慮して設計すれば良いのだとは思います。私含めたテスターと呼ばれる業種の人たちは、開発の早い段階からテスト対象のテスタビリティを上記の観点でレビューできるスキルを身につけるっていうのが、キャリアパスとして重要になると思いました。品質を高めるっていうことはテスタビリティだけあげれば良いって話ではないですが、テスト工程がクリティカルパスになってしまったり、もっともコストが高い工程がテストだとなってしまうのを防ぐのは、テストのプロとしてとても重要なことだからです。
テストを良くしていくには、まずはテストをやる人たちが自分たちのことをちゃんとしていかなければなりません。一例で言えば、テストケースの改善として、誰が見ても何が書いてあるかわかるテストケースを作っているか?というのがあります。もし、作ったテストケースを複数のテスター同士でレビューしあえるようになっていないのであれば、まずはそれを改善します。(案外やってないんですよね、テストケースを仲間同士でレビューしあうっていうのを。プログラマーが人のコードをたくさん読むことで成長するのと一緒でテスターは人のテストをたくさん知ることで成長します。)
TPINEXTというテストプロセス改善モデルがありますが、そこではテストプロセスの成熟度を「初期レベル」「コントロールレベル」「効率化レベル」「最適化レベル」と分けています。初期化レベルとコントロールレベルは、テスト工程だけの問題だと行っても過言ではなく、テストを担当する人たちは自分たちだけでよくしていけます。上記のテストケースの例は、TPINEXTのテストケース設計という改善領域のコントロールレベルに相当します。
しかし、コントロールレベルまでの改善の場合、逆に時間がかかるようになってしまうことがあります。そのため、効率化レベル、最適化レベルまで自分たちのプロセスを引き上げていく必要があるのですが、そうなると、テスト対象のテスタビリティが影響してきます。
「テスト対象の作りが悪いから自分たちではどうしようもない」とか言って諦めてしまうのではなく、テスタビリティを上げるための貢献ができるスキルを身につけて、開発全体がよりよい世界に向かっていければよいと思います。
---------------
あと、この原典を調べて載せとこうと思ってネット調べてるのですが、なんか上記の定義はプレスマンの「実践ソフトウェアエンジニアリング」かもしれません。このスライドシェアが出典元を書いています。
原点を調べてたら、ジェームスバックは、最近だとヒューリスティックテスタビリティというPDFが公開されていて、これはこれで面白そう。ちゃんと読んだら感想書くかもしれないです。
(9月12日追記)
実はこのノートを公開した後、ソフトウェアテストの生き字引として有名な辰巳さん(@KeizoTatsumi)に以下の指摘をもらいました。
す、すいません、追記しました。
おまけに、出典元に関していろいろ教えてもらいました。
だそうです。勉強になりました。<(_ _)>
サポートありがとうございます。これをカテにこれからも頑張ります。