うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

単体テスト(画面単位のテスト)がクソらしいので思ったことを書いてみる

なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。

これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ?

要約

だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。

あと、観測結果として 同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの?ねぇ?なんで?」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。 というのが大きかった。

単体テスト

まず、最初に思ったのはTwitterで文句を言っている人たちは単体テストを定義できていない人がほとんだだった。つまり、カレーが何かはわからないけど、これはカレーじゃない。だってテレビで見たのとか、なんかお店で食べたのと違う。そういっている感じだった。客ならいいけど、自分の仕事に対してそれでいいとは僕は思わなかった。自分の仕事の言葉を自分なりに定義もしくは引用できないでなんなんだろうって思った。

実際に言葉というのは定義の問題であることころがおおい。実際に画面単体でのテストというのはいわゆる単機能テストといわれるテストレベルであろう。WebMVCで言えば一つのコントローラに結びつくような感じのテストだ。単機能テストのことを単体と呼んだときに、単体より小さなものを意識しにくいという言葉の印象が持つ問題というのは僕も2,3年前に感じた。言いたいことはわかる。

単体テストと呼んだ方が楽な場合もある

これは単体テスト/結合テストなんて存在しない - Togetterまとめでも言ったが、この当時の問題意識はつまり「納品物であるドキュメント駆動な開発」ということによってそれ以外のテストを考えられないというものであったが、画面単位が単体テストであるとしてしまえば、クラスやコンポーネントのテストは納品物として作成する必要はなくなる。工数の調整をどうするかは面倒だが、それはマネージャーがいい感じにガントチャート動かしておけばよくって、そうすると作業は増えて品質をあげているけど、納品物は増えないというトリックを使える。(普通は作業には納品物が必要になるが、規定されていない作業には納品物がない)。

まぁこれが正解だなんて思っていないけど、こうやってうまく使えばいい。おそらく対外的な要因でコンポーネントレベルのテストが出来ないということはあまりない。(開発者がやる分には)

組織内にどうやって単体テストを普及させるのか

まぁ隣の人がxUnitやxSpecでのテストをやってくれない。自分しかやらない。むしろ許されないとかいう状況はあるかもしれない。そのときに単体テストをやっているから、コンポーネントレベルのテストなんかいらないんだという発言にであったら、それは計測するまでわからない。とりあえず現状を計測しよう。まずその単体テストと呼ばれているものや統合テストと呼ばれているもので発見されているバグとそれを改修するのにかかっている時間の件数や傾向を調べる。また、静的解析ツールでコードの保守性を計測してみるのもいい。他にも、新しい改修のときに既存コードを読むのにかかる時間や間違いやすい単語を調べるのもいい。これらをした結果、xUnitやxSpecで単体テストをしたほうがかなりの割合でもとがとれるならそうすべきだ。

もし、そうでないなら僕はしなくていいと思う。そんなのはエゴだ。僕もプログラミングは好きでUnitTestのないコードなんて窓から投げたいとか思うときもあるし、汚いコードはrmしたいし、プロフェッショナルじゃねぇよそんなの!ってツバを吐きたくなる。でも、なにかを変えたいときはそうであってはいけない。プロジェクトの成功がなにで失敗がなにで、継続的成長の継続的とはどの範囲なのかを見極める必要がある。

なにより、やってもただ疲れるだけのテストコード導入(画面単体の手動テストでやるのとコストや保守性が変わらない状況)なら価値に「教育」とか「スキルアップ」とかがあるべきだ。

何を言ってもわからずやなバカとどうやって仕事をするかはしらない。だけど、自分がどれくらい根拠を持って説明出来るかは、実際にはエンジニアの大きなスキルだと僕は思っている。全てではないけれど。でも、大きな部分だと思っている。

ちょっと自分の話になるけれど、同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの?ねぇ?なんで?」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。別に言葉は曖昧でいいし、どんな答えなら満足するとかはないんだけど、まぁなんというか物事に対する姿勢としてという感じで。

スクショの件

エクセルにスクショを貼り続ける仕事についてだけれど、まぁ辛いというのはわかる。僕も結構やった覚えがある。たぶん貼った枚数はわからなくて、Excelファイルでいうとたぶん数十GBは超えているだろう。(これは前職の話だ)

ただ、僕には現状であまりいいソリューションが思い浮かばなかった。つまり画像をいい感じにモックアップのようにスライドショーできるようなツールが2005から2010年ころにWindows XPで使える環境ではなかった気がする。個人的にはツールとしては妥当だったと思う。

なんでかというと、まずスクショをとるようなテストをやっている人たちはまずテストを好きでやっていることはあまりなくて結構手抜きなこともある。そういう意味では強制力はあった。ただ、全ての画面をあれでやるのかと言われると微妙だなぁとは思う。なにかいい感じに差分だけ適当にとってくれるツールがあるとうれしいんだけど。って言う感じで、「こういったツールだったら差分も確認しやすいし、いいねー。次のプロジェクトでプロトタイプに活かせるかもねー」とかいう新しい良いものをつくる感じの話題があるといいな。

まとめ

特にまとめはないし、誰かに何かを強制するものでもないけど、テストを勉強する時間はないけど嫌々言う人がいるから自分みたいなロールも必要なんだなぁとか思った感じです。テストなくなればいいのにね。

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

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

ソフトウェアテスト教科書 JSTQB Foundation 第3版

ソフトウェアテスト教科書 JSTQB Foundation 第3版

  • 作者: 大西建児,勝亦匡秀,佐々木方規,鈴木三紀夫,中野直樹,町田欣史,湯本剛,吉澤智美
  • 出版社/メーカー: 翔泳社
  • 発売日: 2011/11/12
  • メディア: 単行本(ソフトカバー)
  • 購入: 5人 クリック: 85回
  • この商品を含むブログ (12件) を見る

ソフトウェアテスト技法

ソフトウェアテスト技法