テストのさじ加減

昨日おかしな現象をプログラマーOさんに見てもらった。5分くらい追試したら再現手順が分かったのでOさんの作業場に行ったら、どこのコードがおかしいか当たりがついたところだったようで、再現手順とコードで答えあわせをした。こんな時わたしは（テストというより）デバッグしてる気持ちになります。

— miwa (@miwa719) 2018年10月5日

はじめに

テスターが「仕様書」や「見た目の出来栄え」だけでなく「設計の良し悪し」を感じ、それをテストに活かすことができたら良いんじゃないかな、という話です。テスター向けに書いたのだけど、プログラマーのみなさんは、どんなときに「設計の良し悪し」を感じるのか、教えてもらいたい気持ちがあります。

「設計の良し悪し」とは

書籍『達人プログラマー』第２章（達人のアプローチ）「８ 直交性」より

直交性とは、簡単に設計、製造、テスト、拡張できるシステムを構築する場合に必要となる重要な概念です。

（中略）

この用語はコンピューティングの分野では、ある種の独立性、あるいは分離性を表しています。２つ以上のものごとで、片方を変更しても他方に影響を与えない場合、それらを直交していると呼ぶわけです。

本項では「直交していないシステムの変更や制御の難しさ」「良いとされる設計」「直交することの利点」などについて書かれています。はじめに貼り付けたツイートのような「再現手順が思いつかないような現象を見たときでも、プログラマーが問題箇所に当たりがつけられる状況」というのは、ここで良いとされている設計 *1 になっている（またはそれに近い）のではないでしょうか。

多くのテスターがそうであるように、わたしも普段はソースコードを読まないので、本当のところは分からないのですが、開発中に起きる様々なことから「設計の良し悪し」 を感じ、テストのさじ加減（テストを行う際の配慮や手加減のこと。一通り触ってみたけど、もうすこしテストしたほうがいいな、というようなテストの微調整）を決めるための「材料」にしているように思います。

「設計の良し悪し」を感じるとき

わたしが「設計の良し悪し」を感じるときをメモしておきます。悪いシグナルを書いたので、反対にすると良いシグナルとして読めるものもあります。

なお、うちのチームは世界的に『外れ値』として扱われてしまうことが多いので、これまで所属してきた複数のチームを思い浮かべて、観測できそうなものを書いてみました。*2

1. チケットの滞空時間が長い

手をつけてからコミットするまでに日数がかかっているチケット。進んでいるように見えるが、なかなかコミットできない。設計が複雑で難しいのかもしれない。*3

ただ、これは他にも問題（もっと深刻な開発全体に関わるようなもの）が起きていることもあるので、単に経過日数だけに注目すると間違えます。（例：開発が順調に進んでいるように見せる必要があり、ひとりのプログラマーが複数のチケットを同時にオープンしている）

また、チームによっては、滞空時間が長いのは良い傾向（サクッと進んでしまうときほど危うい）の場合もあるようです。

2. なかなか手をつけないチケット

設計が複雑で難しく（やりたくないので）なんとなく後回しにしてしまうのかもしれない。

これもさっきと同じで、経過日数だけ見てると間違えます。（例：バグが出すぎていて取りかかれない、手をつけているチケットで難しい問題が発生している、緊急度／重要度が他のチケットより低い）

3.「再現手順が分からないと分からない」と言われる

現象から当たりをつけられないくらい、これに取りかかったら、しばらく他のことができなくなるくらい、設計が複雑で難しいのかもしれない。

各種ログからも追いづらい、調査しづらい厄介な問題であることが多く、簡単には再現しない。再現手順が分からないと、直ったかどうかも確認できないので、わたしも再現手順を見つけたい。*4

4. 変更内容をコードの断片だけで説明する

変更前にそう書かれていた意図、それをどのように変更したのか、それで良いと思ったのはなぜか（根拠）を言葉で説明できないくらい、設計が複雑で難しいのかもしれない。

5. 変更したら別の機能が壊れた

変更したことによる影響が分からないくらい、設計が複雑で難しいのかもしれない。*5 

6. 変更したファイルがやけに多い

一昨日、うちのチームのプログラマー @vistige_ から「コミットログを見ると、いろいろ分かって面白いですよ〜」と教えてもらったので、しばらく毎日観察してみようと思っています。ファイル名からどの辺を変更したか、だいたい分かると言っていたので、これは予想ですが、自分ではちょっとした修正だと思っていたのに、変更したファイルがやけに多いなとか、いつもとは違うあまり見たことのないファイルが変更されてる…を感じることができるなら、テストのさじ加減も変わりそうです。*6

新装版 達人プログラマー 職人から名匠への道

*1:YourdonとConstantine が「凝集度」と呼んでいるもの

*2:プログラマーが常に良いコードを書きたいと願い、実際そういうコードを書こうとしてるのは、見て知っています。わたしが対象にしてるのは製品（ソフトウェア）なので、プログラマーを責める気持ちはありません。どうか怖がりませんように…!!

*3:うちのチームでは「仕切り直し」というキーワードが使われるので分かりやすい。最近、特に注目しているのは「鋭意作成中」とチケットに書いてくるプログラマーがいるので、注意深く観察しているところです。「作成中」なのは知っているので「作成中」と書いてくる時点で気になるけど、さらに「鋭意」を入れてきた理由があるはずだと思うから。

*4:この手の問題は１つ直っても、他に問題が潜んでいることも少なくないので、修正後の確認はかなり時間をかけて行います。問題の周辺をよく見る。

*5:どこを直したらどこが壊れた、という事実は、テスターが内部設計を予測するのを助けます。

*6:ある部分は機械化できそうな気もする。