テストと開発の違いをわかりやすく教えてやんよ！

タイトルは釣りです。むしろ、教えてほしいです。とは言いつつも自分で比喩が思い浮かんだので書いてみました。

テストはQAでもいいんだけど、まぁロールとか立場とか視座とかが違うとはこういうことであるというのをなんかいい比喩を考えついたので。 このエントリでは「プログラミングする」と「テストする」はどう違うのか？ということを説明します。なので、プログラマーが「うーん。テストしているんだけど、あんまり意味がないかもー」って感じるときはこの例に出てくるような「テストする」になっていないかもしれないし、ただただ品質が高いのかもしれません。

ソフトウェア開発を塗り絵として考える

ソフトウェア開発はある形の塗り絵として考えてみます。複雑なものはちょっと考えにくいので、まずは大きな長方形を赤色に塗ることとしましょう。

まず開発する（塗る）

で、例えばプログラミングするときに左から右に筆で赤く塗ったとしましょう。ちょうど下のような感じに。

次にテストする（塗れているか別のペンで調べる）

次にこれをテストします。まずはぬれていない場所を探すことにしましょう。テストには塗られていない場所に塗ると裏写りするペンを用います。このときにたいていのテストというのはもっとすっごく細い鉛筆のようなものでしか実施出来ないという制限があります。（これは大抵は型と値の違いで言われると思う。） そしてその芯が短いこともしばしばあります。

さて、このときに開発と同じように横向きに線を引っ張ってみると。。。

でも、これを縦に引っ張ると。。。

これらを裏返すと塗れていない部分全体をそれなりに予測しやすく黒がでているのは下の方だというのはなんとなく伝わるかと思います。

このように開発とは違う視座や視点を持つことで対象を調べることがテストだと僕は思いました。なので、開発をなぞらえるようにテストしていては塗れていないところの全体像はわかりにくかったり、下手したらより見つかりにくい感じになると思います。

実際には

それにさっきは塗れていないところだけでしたけど、はみ出している部分のテストしていないですよね。これはいわゆるテストの範囲を示していると見ていいでしょう。テストレベルに近いかな？1つの図形だと関数しかないみたいな感じだけど、複数の図形がつらなっていたり、風景画だったりすると、別の色で塗りつぶしていたら困りますよね。なので、図形の中だけ奇麗になっているか見ても、実際には他の図形が塗りにくいとか書きにくい感じになっていないかを調べないといけません。これは統合テストとかコンポーネントテストですかね。

それに、実際にはこれはもっと複雑な形をしています。そうすれば塗り方もかわるし、それによってよい調べ方も変わるでしょう。そうなると、技法が生まれるし、描き方の主義も出てきます。遠近法とかでてくるし、印象派とかでてくる。前者がイディオム、デザインパターン。後者がオブジェクト指向とか関数型とリアクティブとかに似ている気がしています。で、それに対応するようにそれを評価する仕組みも必要ですよね。いい感じに描けているかっていうのを効率よく調べるためにテストエンジニアは最初の例だったらテスト技法でより塗れてなさそうな線のあたりを効率よく線引くためのアルゴリズムを経験則から導きだします。つまり、「右利きでこういったツール使っている人はここで線が曲がりやすいからこういったテストケースが一番塗れていないところを検出できそう」みたいな。あとはツールをつかって人間には判定が難しそうな部分を計測したり高速化します。視座についてもその方法論にあったもので、でもその方法論をなぞるのとは違う感じでどこから始めたらいいかとか、どの方法が早くわかりそうかとか、ざっくりわかるためにはどうしたらいいのかとか考えるわけですね。

じゃあ、TDDってなによ

小さい頃に塗り絵をやったときに塗り絵の枠をまずは縁取りましょう。ってやったことあると思います。TDDはあれに近いんですね。「僕はこれからこの範囲内のものを塗るんだー」っていう感じ。だから、ある意味テストに近いんですけど、実際には開発なんですよね。だからTDDはあくまで設計のライン引きをより奇麗にしている感じなんです。

要求のテストってどうなったのよ？

例えば「印象派後期のような雰囲気で光がつよい絵がほしい。リビングに飾りたくって、これくらいのサイズで、、、」っていうのにうまくあっているかですよね。えっと、考えるの忘れていました。

電子データならソフトウェアで部屋をつくって、そこに実際に配置してみるとか言うシミュレーション？をやるなぁと思いました。で、どの程度部屋に似せるかとか、むしろあり得そうな別の状況でも対応できるかを考えます。うん、やっぱり後付け感がひどいw

まとめ

って言う感じで、絵描きをテストと開発の比喩に使ってみました。描き方を知らないと、その描き方がうまくいっているかはわからないですが、知っているだけでは、それがうまくいっているかどうかを普段から考えていないとなかなか評価もできないものです。たぶん、誰かに同じ方法でつくってもらったのをレビューするときになって気づくことが多いのではないかなぁとか思いました。

まぁ、なのでテストが無駄に感じるときは自分の方法がうまくいっているというのを、どうやったら違う方向から確認出来るかを考えてみるといいと思います。それを思いついたら、あとはテストケースを減らせないか考える段階で、テスト技法で何か出来ないや、そもそも作り方を変えたらテストしなくていい部分が増えないかを考えましょう。で、大抵はそれなりの数もあるし、つくりながら変わるのでどの順番でやるとか、どのときに気をつけるとか考えておいた方がうまくいくので、テスト戦略を考えましょう。

みたいな感じですかね！

基本から学ぶソフトウェアテスト

基本から学ぶテストプロセス管理―コンピュータシステムのテストを成功させるために

ソフトウェアテスト293の鉄則