CAT GETTING OUT OF A BAG

What the tester is thinking.

ソフトウェア技術者のためのバグ検出ドリル(問題5:迷路探索プログラム)

この記事は『ソフトウェア技術者のためのバグ検出ドリル』についての思考メモです。本書で問題を解いたことのある人、これから解いてみようかなと思っている人向けです。当然ドリルの問題は載せられないので消化不良を誘発する内容になっています。*1

ソフトウェア技術者のためのバグ検出ドリル

ソフトウェア技術者のためのバグ検出ドリル

 

f:id:miwa719:20200125092705j:plain

この問題で著者の山浦さんが用意した解答(バグ)は3つ。この問題はうまく解けた感があります。うれしい。*2

本書では1つ1つのバグについて以下が記載されています。

  • バグ名
  • 分類番号(Boris Beizer 氏のバグ分類による)
  • 不良分類名
  • 作り込みフェーズ
  • 検出フェーズ
  • 重要度

検出フェーズというのは「最悪ここまできたら検出できるよね」というフェーズのことなのかな。今回の問題の3つのバグの検出フェーズはそれぞれ「テスト」「コーディング」「コーディング」と書かれています。

プログラマーの経験がないとコーディングフェーズのバグは見つけられないか?というとそうでもないと思っています*3。今回の問題のコーディングフェーズのバグは、どちらも仕様書(ドキュメント)をよく読めばわかります。座標 (x, y) の記載が途中で (y, x) になっていたらプログラマーの経験がなくてもおかしいことに気づけるのではないでしょうか。そしてこんなことを考えるかもしれません。迷路探索がどのようなものであるかは大抵の人が想像できるだろう。部分的に座標がちぐはぐだけど他の記述を読めばこのプログラムで期待している動きは明らかだなって。些細な記載ミスで誰もそこについて何も言ってこないけど、みんなわかっているよね。そしてこの後にもディスカッションすべき議題が控えている。

そこであえて「おかしいよね」と本物の開発の現場で言えるかどうかが、わりと鍵なんじゃないかなと思っています。

 

Boris Beizer 氏のバグ分類で思い出して自宅の本棚にある『ソフトウェアテスト技法』を久しぶりに手にしたけど、翻訳者が山浦さんでした。知らなかった。

ソフトウェアテスト技法

ソフトウェアテスト技法

 

うちにあるのと表紙がちがう。

 

*1:勘の鋭いエンジニアなら問題を逆引きできそう

*2:うまく解けた感があるときは、うまく解けてないかもしれない…。

*3:もちろんプログラミングできることで見つけられるものもたくさんあります。ここで言いたいのは(自分はプログラミングできないから…)とあきらめなくていいことまであきらめてしまうのはもったいないなぁと感じているということ。