テスターが開発現場にいることのメリット

MTBF平均故障間隔)とかMTTR平均修理時間)とか、世の中には品質をあらわすための指標が数多く存在するようですが「バグを発見してからプログラマーに伝わるまでの時間」という指標は、あるのかな?

わたしたちのチームは、これが圧倒的に早いです。

といっても、どこかと比較したことはないのだけど、どれくらい圧倒的に早いのか、最近のツイートに補足しながら説明します。

テスターが開発現場にいるときの場合


テストしていると(はて、これはこういう仕様なのか、それともバグなのか?)と思うことがあります。その点、クラッシュは分かりやすいですよね。

一瞬で恋におちるような経験はないのだけど、クラッシュも何の前触れもなく突然起きることが多いので、まずは心を落ちつかせて、画面全体をスクリーンキャプチャします。

その後、テスターは担当のプログラマーに連絡し、クラッシュしているナマの状態を見てもらいながら、それまでにやっていた操作や、クラッシュする直前の状況を話します。プログラマーはエラーログや解析に必要なデータを採取していきます。テスターがバグを発見してからここまで5分くらいです。

それからテスターは、システムを再起動する間にチケットを発行します。このときはあるストーリーについてテストしていたので、既存のチケットに追記しました。(記載時間1分)

そして休憩したあと、別のテストに取り掛かります。

 


このときはですね、プロの無職が騒いだので、周りで作業していたプログラマーがわさわさと集まってきました。(担当のプログラマーは不在でした)
みんなで(メモリーリークする処理は)どこが考えられる?のような話をしていて、そのうちにプログラマー(←もうひとりのエース級)がコードを見ながら、解放もれの箇所とリークするであろうサイズを、実際の増加量と比較して、特定。

プロの無職が騒ぐ1分くらい前に(あれ?メモリー使用量がどんどん増えていくぞ)と思っていたので、テスターがバグを発見してから、プログラマーが原因を特定するまで5分くらいです。チケットには、それまでメモしていた、機能を実行する前と実行後のメモリー使用量(と増加量)を3回分、記録しました。(記載時間2分)

 

テスターが開発現場にいないときの場合

「バグを発見してからプログラマーに伝わるまでの時間」は、比較にならないので省略しますが、もしわたし(テスター)が開発現場から離れた場所(組織やプロセス的にという意味で)にいたら、どのようなことをするのか想像してみます。過去にそういうチームに所属していたこともあるので、かなりいい線いってると思う。

はじめのケースでは、クラッシュした直後、プログラマーが解析するのに必要なエラーログなどを取り、その他に参考になりそうな情報(もし何かを登録するような機能だった場合は、その登録処理自体はうまくいってるのか/いってないのか、など)を確認します。なお、わたしが思う「参考になりそうな情報」なので、ハズしている場合もあります。

その後、システムを再起動し、現象が再現するかどうか、もう一度同じような操作をしてみるはずです。(テスターとしては「確実に再現する手順」をプログラマーにお届けしたい)
で、すぐに再現すればよいのですが、単純な操作手順ではなく、そのときのシステムの状態や状況に起因していたりすると、再現しないのですな。わたしは非再現のバグに関しては(どちらかというと)執着するほうなので、再現するまでがんばっちゃう。プログラマーがエラーログを見たら、すぐにわかるかもしれないのに、ね。

次のメモリーリークのケースは、このときは3回でやめてますけど、念のため(?)10回くらい実施してメモリー使用量の「ばらつき」を見たりするかもしれないですね。増加量の平均値とか出したりしてね。パッと見てわかるようにグラフとか書いちゃうかも。それから、与えるデータの大きさによってリークするサイズが変わるのかもしれないとか、いくつか気になることを試すと思います。すべては「バグの解析に役立つかもしれない」と思ってやるのですが、ハズしていることもあるよね。

そうやって試すことが増えていくと時間もかかりますし、報告する内容もそれなりに増えていくので、チケットを書く時間も当然かかります。


さいごに

特にまとめませんが、テスターが開発現場にいないことのデメリットというよりは「もしテスターが開発現場にいると、こんなメリットがあるのよ!」ということを、少しでも感じてもらえたらいいな、と思っています。