kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

テストに関する話

テストに関するツールとか、方法などを再度整理するためにちょこちょこ書いていこうかなと。まとまりのない話かもしれませんが。そこのところは適宜コメントでどうぞ。誤変換以外は次の日のエントリで反映する場合があります。

ツール支援

最近のVisual Studioの品質を上げるためのテスト機能とかすごいですが、実際に使うとなると、みんなというか、少なくともテストする人にはちゃんと教育しないといけないですよね。その工数を割くという以前に、「テストって最後で、受け入れて、仕様書通り確認だよね」みたいな風潮で、(ウォーターフォール型では特に)テストの時間が足りない。
そして教育もされていないから、ツールを使って効率的に行うという時間も用意されていない。テストエンジニアが専門でテストツールを用意するところも少ないんじゃない?特に業務アプリケーションでは難しいかなと。

オフショアとテスト

海外に限りませんが、自社以外で作って、リリースする場合、工業製品のような検品みたいな作業がありますよね。しかし、設計する人は必ずしもプログラミングの細かいところを知っているわけではない場合もあり、最終的に性能を含めた品質問題になることもあります。
たいてい最後にチェックして発覚するので、作り直すことが大変難しかったり。これもテストを軽視しているためかもしれませんが、設計で「このくらいの計算量だろう」と見えていればいいのかもしれませんが、それだけが理由ではないので、逐次テストしていかないと難しいです。
検品しないで品質を上流で作りこもうという人もいるかもしれませんが、そこでできるのは「書かれた仕様書の範囲において」機能ができるかどうかってことだけでしょう。

どこまでやればOK?

日本人はテストの仕様書に書かれていないことでもテストしてしまって、結果品質が高いけど、過剰品質ではないか(そしてそれに慣れてしまったのではないか?)と思うこともあります。前の話と関連しますけど、「わざわざ書かないよね」、「でも、これくらいは当然やっているはずだ」というような感じ。
無意識のものの代表例としては、たとえばデザイン上ボタンの大きさや色のちょっとした違い。こういうのはUIガイドラインなどで、それぞれの仕様書に書くまでもなく「このガイドラインに従っていないUIは全部バグ」とかね。あまり分厚すぎると特に多くの人数で開発していると読まなくなっちゃうので、俺様ルールはできる限りやめる、そもそも後で修正しやすいようにする方式を採用するとかという感じでしょうか。htmlならCSSWPFならコードで書かずにXAMLとリソースでやるとかね。
ちょっと思いついた感じで書いたので、実際のコードなどのテストの話はまたあとで。