読者です 読者をやめる 読者になる 読者になる

テストの価値。開発者とテストエンジニアの相違。 #kyon_mmAdvent

kyon_mm Advent Calendar

つぎのリンクにあるAdventCalendarの18日目です。
http://connpass.com/event/1457/

ソフトウェアテストの言葉入門 #kyon_mmAdvent - うさぎ組】に続きテストシリーズ2日目。

注意

ここで、開発者とテストエンジニアと書いたのは、どちらが優秀であるとかではなく、普段どのようなことを主に勉強してソフトウェア開発に携わっているかということを表現するための一種の区別です。
勉強している内容が違えば考え方もほんの少しずつ変わりますよね?っていうくらいに捉えてください。

開発者のテストのスタイル

xUnit, xSpec,Cucumberといったフレームワークをつかい、できるだけプロダクトに「近く」「早く」寄り添ってテストをすることを得意としています。
開発者は「つくることがたのしい」と思っているので「つくることを促進するため」にテストを活用することが多いのではないでしょうか。
「自分の設計があっているか」「自分の書いたコードが正しそうに動いているか」
これらの心理をうまくフレームワーク化したのがTDDなのだなぁという理解です。

テストエンジニアのスタイル

品質モデルや不具合モードという視点をつかい、できるだけユーザーとバグに寄り添ってテストをすることを得意としています。
テストエンジニアは「バグを出すことがたのしい」と思っているので「より効率的にバグを検出するため」にテストを活用することが多いのではないでしょうか。
「どうすればどのようなバグがでるのか」「ユーザーが求める品質とはなにか」ということを体系的にまとめて活用することがメインであることがおおく、テスト技法やテスト観点に注目されるのだと思います。

ソフトウェアテストの価値

テストの価値とはなんでしょうか?
僕は最近こう思います。「ある根拠に基づいてテストを完了したと言い切れること」がテストの価値。
具体的に言えば「状態遷移パスで2スイッチカバレッジまでテストした」「プロダクトコードカバレッジ率が80%を超えている」「規模あたりのバグ検出率が社内基準と同じくらい」「複雑そうなコードはだいたいテストした」「たくさんドッグフーディングした」「POがそれでよいと言った」など本当にたくさんあります。
テストの完了基準というのはなかなか難しいと思いますし、僕もたくさん実践できているわけではないですが、上のように考えるようになりました。

開発者とテストエンジニアの相違

では、仮に「ある根拠に基づいてテストを完了したと言い切れること」がテストの価値だとして、それらをどうやって正確にデリバリーするのでしょうか。


開発者のテストのスタイルは「つくるべきものがどのような状態であるか」という視座でテストを行います。
ソフトウェアテストのスタイルは「ある品質やテスト目的を満たすかどうか」という視座でテストを行います。
前者はできたものやつくっているものである「ソフトウェア」から見ます。
後者はできるべきものである「性質」から見ます。
この違いが両者のテストにおけるものかなぁとおもっています。


もちろんですが、どちらからも見ているという人もいらっしゃるとおもいます。


あまりよくないかもしれませんが、僕が使う比喩表現としては小説における「作家」と「編集者」の関係であるといったりします。
どちらもよい小説を書こうとしながら、視座がちがうわけです。もちろん一緒になることもあるかもしれませんが。


この辺の話はいろいろある

テストをロールでわける系の話は有名なものだと2つあります。

  1. Developer, Customer, QAのロールでわける。
  2. アジャイルテストの4象限

僕はまだアジャイルテストの4象限のほうが好きなのですけど、正直なところどちらも嫌いです。
プログラミングが設計と実装を1対1に紐づける方向としてDSLが盛んになって来たように、テストにおいても、テストの意図とテストの実装は1対1に紐づく方向がよいと思っています。そしてそれは、基本的に実行可能なものをそのまま書くというスタイルで。
少なくとも上の2つの分け方はテストの価値を分類したときに、その価値に一番紐づきそうなテストを分類しただけであって、こうあるべきという話をしているものではないと僕は考えています。
僕は「あるべき論」が好きなので「ソフトウェアテストは自身の価値を迅速に最大に届けるためにどうあるべきか」という視点ではロールで別れていたとしてもそれらをどうやって近づけるかという話をもっと盛り上げたいなぁと思っている次第です。