yoshitake_1201’s diary

テストのこととか、ペンギンのこととか書きます。

バグを逃してしまったときにチームでやること #テストアドカレ

qiita.com

この記事は、ソフトウェアテストアドベントカレンダー2021の1日目です。

先日友人に「バグを逃してしまったときどうしてる?」と聞かれました。 そこで自分たちのチームがバグに気づけなくて逃してしまったときはこんなことしてるよ、という話をしたのでその内容をブログに書くことにしました。

逃したとき

バグを逃してしまったとき、自分たちは「そもそもそのバグに気づくことができたかどうか」を考えます。 気づく実力があったかどうか、という意味合いが近いかもしれないです。 ただどちらにせよ、逃している時点でその実力はなかったと言われるとその通りです。 「他のプロジェクトでテストしたときは逃さなかったバグかどうか」を考える という感じが近いと思います。

自分たちの実力ではそもそも気づけなかった場合

自分たちの実力ではそもそも気づくことができなかっただろうものについては、以下を行います。

  • バグについてエンジニアに聞く
  • バグに関係することを調べる
  • どういうテストで見つけれるか考える
  • どうやったら↑のテストをするようになるか(したくなるか)を考える

「エンジニアに聞く」「調べる」は、何が原因だったのか、どんな条件で起きるのか、どんな対応をしたのか、このバグから他にどんな事が起きるのか考えるなどをやります。 自分たちが気づきようがなかったので徹底的に調べます。

それが終わると、次は「どんなテストで見つけれるか」「どうやったらそのテストをするようになるか」を考えます。 ここでどちらかというと難しいのが「どうやったらそのテストをするようになるか」です。 「このテストをやればこのバグはみつけられるぞ!」と思っても、そのテストをやるようにならないと意味がないですよね。 しかし、このとき考えたテストは自分たちにとって完全に新しい取り組みなので、うまいことやらないとなかなか自分たちの動きに馴染んでくれません。 そこで「どうやったらこのテストを自然に気付けるようになるか?自然にやるようになるか?やりたくなるか?」を話します。 話している途中にこれが決まらない場合は、また「どんなテストで見つけれるか」を考え直します。 「このテストをやれば見つけれるよね、意識して頑張ってやろう!」と言いたくなる気持ちはわかるんですが、現実問題そのテストをやるのが難しいということもよくあります。 また、意識しようと思っても体に染み付いた考え方を変えるのはなかなか難しいです。 なので、今の自分たちのテストの流れ(テストの考え方/やり方)にできるだけ自然に埋め込める/拡張するよう考えるようにしています *1

自分たちの実力で見つけれたかもしれない場合

次に「自分たちに気づく実力があったけど気づけなかった場合」の話です。 繰り返しになりますが「そもそも気づけてないのでその実力がなかった」のはごもっともです。 「他のプロジェクトでテストしたときは逃さなかったバグだけど逃してしまったバグの場合」です。

この場合、まず以下を考えます。

  • テスト中どの瞬間に気づけたか
  • なぜその瞬間にテストをしなかったのか

「普段なら気づけたはずなのに気づけなかったと思う」ということは、普段とは違う何かがあったということですよね。 なので、普段ならどの瞬間に気づけたんだろうかを探します。

その瞬間が見つかると次に「なんでそのテストをやらなかったのか」を思い出します。 その場面を思い出すと、自覚してやらないを選択したのか、無自覚にそのテストをやらなかったのかなどがわかるので、そこからさらに「その選択をした理由」または「そのテストをやらないようにさせた要因」を辿ります *2。 ここで出てくる例としては「データの準備が大変だからケースを減らした」「直前に大きなバグが直って安心してしまった(油断)」「既存のシステムをコピーするだけだから大丈夫(油断)」「余裕がなかった」などがありました。 そしてさらにこれらから「なんでその判断をしたの?」や「なんでその状況になったの?」をある程度繰り返し考えていきます。

例えば「無自覚にそのテストをやらなかった」要因が「余裕がなかった」としたとき「なんで余裕がなかったんだろう?」を考えます *3。 すると「デグレや再確認が多くて疲弊してた」とか「仕様変更が多くて…」とかそういったものが出てくるので、また「なんで?」を考えるという感じです。

ある程度繰り返して要因を出し終わると、それぞれの要因に対して「その状況にならないようにするにはどうするか」「その状況になってしまったときどうするか」「どうやったらその状況になっていることに気付けるか」を考えます。 先程まで挙げたものだと以下を考える感じです。

  • 余裕がない状況にならないようにするにはどうするか
  • 余裕がないときどうするか
  • 今余裕がない状況になっていることにどうやったら気付けるか
  • デグレが多いときどう立ち回るか
  • 疲弊してることにどうやったら気付けるか
  • 油断していることにどうやったら気付けるか

ここで特に気にしているポイントは「どうやったらその状況になっていることに気付けるか」です。 「余裕がない」「疲弊している」ときは 本人はその瞬間は自覚がないことが多くて、プロジェクトが終わった後にふりかえってみると「あー、あのとき余裕なかったな」と気づくことが多いです。 なので「余裕がないときこういう風に立ち回ろう」と決めても「余裕がない状況になってることに気づけてない」ため、せっかく立てた対策が実行できなくなってしまいます。

もちろんここで考える内容も、今の自分たちのテストの流れ(テストの考え方/やり方)にできるだけ自然に埋め込めるように話し合います *4

おわりに

ここまで自分たちのチームで、バグを逃してしまったときどうするかを書きました。 どちらの場合も時間はだいたい30分ぐらい、長くても1時間ぐらいで終わります。 かなり頭を使って話すので時間にすると意外と早く終わります。何より1時間以上は頭が持ちません。

今回は逃してしまったバグについて書きましたが、「このバグよく見つかったね」というのも↑のように考えたりします。 ものにもよるんですがラッキーで見つかったようなバグは特に。 運も実力の内とは言うけど、そういうのは次回は実力で見つけたいですよね。

そしてここまで淡々と書いてきたのですが、バグを逃すことはもう本当に絶対1番やりたくないことだなぁと思います。 申し訳ないし、悔しいし、もうその他色んな感情が吹き出して未だに取り扱いに困ります。 でも、そのバグを逃さないように新しく取り組みを始めたせいで、これまで普通に見つけれていたバグが見つけれなくなるのも嫌です *5。 テストのデグレ、イヤですね。 なので今できていることは守りつつ、ちょっとずつ丁寧に対策していけたらと思っています。

*1:根本的に変えないといけないこともありますが最近はあまりないです。どうやっても難しいときはあきらめてやります。

*2:なんでそのテストしたのか/どういう事考えてテストしたかなどその場面を事細かく覚えているのはテスターあるあるな気がする(もちろん覚えてないときもあるけど)。

*3:「余裕がなかった」で終わるふりかえりは苦手なんですが、「なんで余裕がなかったんだろう」を考えるのは好きです。でも「時間がなかった」「考慮漏れ」というワードが出てくるのはなんか苦手です。

*4:それぞれの役割で考えます。 テスト実行する役割だったら/テストを指示する役割だったらなど。

*5:チームメンバーのsaeさんが「新しく取り組むのは良いけどそれをやると今できていることができなくなる気がする。そのほうが嫌」と言ったことがあって確かに!と思った。