『ソフトウェアテスト技法ドリル』読んだ
『知識ゼロから学ぶソフトウェアテスト』読んだ - ✘╹◡╹✘ を書いたところ、知り合いのテストエンジニアにこれオススメだよと勧めてもらい『ソフトウェアテスト技法ドリル』を読んだ。読みながら、どこでテストを書くのを満足すれば良いのか、このトレードオフはどんな条件下でどういう状態になるのか、テストについて常に信じられるものは何なのか、ということを考えていた。
なんでテスト書いてるのか
まあ四年前の本なのでググればレビューも沢山出てくるしとりあえず本のことは置いといて、テスト書くときにいかに雑な仕事してるかという話でもしたい。日々コードを書いていると、たまに「なんでテスト書いてんだろうな」と思うことがある。気持ちとしては経験則から来る理由が主で、端的に言うと、これまでテストを書かなかった場合より書いた場合のほうが体験として良かったことが多かったから、ということになる。見落としていた仕様があったがテストを書く過程で見付けられたということもあれば、テストのしやすさを意識してコードを書くことで綺麗に分割できたということも、絶対大丈夫だけど念のためと思ってテストを動かしてみたらリリース前に不具合を発見して笑顔ということもあった。
悪い体験
良い体験も多かった一方で、悪い体験もある。テストを実行するのにものすごく時間が掛かるおかげで一向にリリースが出来ないとか、本番環境では動くのに何故かテスト環境でだけ動かないとか、仕様とコードを少し換えるとテストが一斉に失敗したせいで数十分で実装できたのに直すのに数日掛かったとかそういう類の体験。まあそれはテストが悪いというより使う側が悪いよね〜という意見も聴こえてきそうだけど、ほなテストが良かった場合かてテストが良いんやなくて使う側が良かっただけやないか。悪い体験思い出しすぎて話が逸れた。
効率が悪い
経験則だと、テスト書かないほうが良いか・あるいは書いた方が良いか、の二元論でばかり考えているところがあるので、書き過ぎて無駄に労力を消費したり、狙いがずれていて折角テスト書いたのに不具合が出てしまったり、掛けた時間に対して見返りが得られない不安が拭えない。実際、テストもっと書いていこうという方向には気持ちが向くけど、テストもっと書かなくしていこうという逆方向からの抑圧が無いので、無駄にテスト書きまくってるところがある。
あまり誇れない理由でテスト書いてるところもある。「みんな書いているしそういう文化なので」という理由で思考停止して書いてる部分も幾らかはある。どうせ書いてもほとんど内容見られないんだろうけどテスト含まれてないとレビューで指摘されるしな〜とか、OSSでライブラリ公開してもテスト用のディレクトリ無いだけで「XXXはテスト無くてヤバい」みたいな反応があるので否応なく書くとかそういうケースもたまにはあろう。実際これも完全に悪とは言えなくて、それで不具合が見つかったりすることもあるのでそれはそれで良い。効率は悪い。
テスト書くときに何を考えるか
急に本の話に戻るけど、『ソフトウェアテスト技法ドリル』は全6章構成になっている。前半で考え方や方針を教えてくれて、後半でより複雑な問題への対処法を教えてくれる。例えば最初の章はテストを書くときに何を考えるかという話で、間・類推・対象・外側などの観察眼を身に付け、不具合の混入しやすい箇所を特定する能力を伸ばしましょうという感じの内容。不具合の出やすい境界値はこういうところによく現れるとか、そういう基本的なことが載っている。テストについて真面目に考える機会ってあまりなくて、とりあえず書いてみましょうという形で学ぶことが多かったので、この辺は改めて勉強になった。
再発防止策書きっぱなしなことが多い
人為的に不具合が混入するパターンは傾向が似通っているので、過去の不具合リストを管理して未来に活かしましょう、という話がある。不具合が起きたときに社内Wikiなどに記録として残しておいて、再発防止策をひねり出して記録しておくというのは、真面目なところだときちんとやっていると思う。寧ろ、何かに残しているけどほぼ活かし切れてないという状況の方が多い気がして、そういった類の埋もれている情報をどう管理すれば設計に活かしていけるのかを考えていく必要がある。
恒久的対策と短期的対策のうち後者だけが講じられて、近日中に再発するみたいなこともよく見る。再発防止策、対策完了したという空気感の形成のために作られたり、再発防止策自体を書くことが承認フローの一環として組み込まれることになることが多いので、何故起きたのか担当者が考えさせられるという機能は果たすけれど、実際そんなもん忘れるので未来に特に役立ってないとか担当者もういないので知見無くて再発するようなケースが多そう。
いかにして不具合検出率を保ったままサボるか
@r7kamura 同値分割? http://t.co/BjJHo8DLkc
— 趣味はマリンスポーツです (@hitode909) January 6, 2015
普段経験的にそれが良いと思ってパターン化している一連のテストケースの書き方というのがあって、それが良いのかどうか不安に思っていた。これについては、基本的な方針としては同値分割や境界値分析の考え方でテストすべき因子を洗い出してテストしていくというやり方で良さそうだった。異常値は他の異常値 (の結果の如何) を隠してしまうという話があるので、それぞれの異常系については少なくとも1つずつ丁寧にテストしていかないといけない。全ての因子の組み合わせをテストすることにすると、因子の個数が増えるに従って時間が掛かり過ぎて現実的ではなくなるので、全て網羅するというのは実際には無理で、不具合の検出しやすい組み合わせを残しながらいかに手を抜くかという考え方をした方が良い。そのために、サボっていくための幾つかの戦略や、統計的に捉えることで不具合発生率という観点でもってソフトウェアテストを捉えることも紹介されている。
条件間の依存関係を捉える
テストケースを考えるときには、テスト対象に関係する条件同士の依存関係を考えようという話が良かった。例えば、ラジオボタンは必ずどれか1つが入力されて2つ入力されることは無いとか、電話番号のバリデーションが必要になるのは電話番号が入力された条件の場合のみであるとか。 普段はフローチャートで考えがちだが、テスト設計においては条件の依存関係の有向グラフを考えた方がわかりやすいという話。状態遷移のテストも依存関係という意味では同じ考え方があてはまりそう。但し、これらの依存関係を考慮してテストケースを書いていたとしても、システムとしては全く意図していない経路で入力が行われる可能性はある。そこまでの内容をテストすべきかどうかは、不具合検出率やリスクの大きさなどで見積もると良い。
テストケースで機能の目的を検証する
他に良かった話として、テストの因子を見つけてテストケースをつくるとき、振る舞いというよりはユーザがその機能によってどんな目的を達成したいかに対して検証を行うべきだろうという話があった。仕様通りに振る舞えることは勿論のことだけれど、盲目的に仕様をテストするだけでなく、ソフトウェアがユーザにとって良いものであるかどうかも同時に考えましょうということ。テストを書いたという事実自体をゴールとしてはいけない。
おわり
本文は180ページ程度で、小さい本なのですぐ読める。2010年に出た本だけど、テスト設計の話はソフトウェア開発の中でも比較的変化がゆっくりとしている方なので、いま読んでも十分通用する。関係ないことも含めて長々と書いたけど、特に何の哲学も無く場当たり的にテスト書いてるという人は読んでみると良い。