この記事は『ソフトウェア技術者のためのバグ検出ドリル』についての思考メモです。本書で問題を解いたことのある人、これから解いてみようかなと思っている人向けです。当然ドリルの問題は載せられないので消化不良を誘発する内容になっています。*1
要求仕様フェーズのバグ（問題4『文字変換表のバグ』）
先日、この問題を技術顧問 @m_seki に出題したところ一瞬（だいたい2秒くらい）でバグを見つけられてしまいました。わたしはというと問題文を丁寧に読みはじめたところでしたので唖然としました。そして（このドリルは独りでやろう…）と思いました。このような練習問題をみんなで解く面白さも勉強会などで体験してますが、自分でバグを見つけたい気持ちの強い人はまずは独りでやることをおすすめします。今回は仕方ないので気を取り直して本書に載っているプログラムを実際に動かしてみました。
ソースコード（C言語）を写経する
本書には問題に応じてソースコード（C言語）や実行結果が載っています。著者の山浦恒央さんは以下の手順で解いてほしいと言っています。
問題4もソースコードと実行結果が載っています。バグのある要求仕様に基づいて実装したのでソースコードも間違っていますし、実行結果も期待したものではありません。
それではうまく動かないっぷりを実際にプログラムを動かして自分の目で見てみましょう。たまたま Visual Studio Code を開いていたのでそれを使ってソースコード（PrintAsciiCode.c）を写経しました。
プログラムを実行する（間違っていることを確認する）
$ clang PrintAsciiCode.c $ ./a.out
おおぅ、Terminal に printf() の "¥n" がそのまま文字で出力されてしまった…。Mac だと改行コードはどう入れるのだ？と調べたら「option + "¥"」で "\" を入力すればよいのですね。ソースコードを直してもう一度実行し、期待どおり実行結果が間違っていることを確認しました。
この間違っている状態を自分の目で見ておくことは普段の開発でも大切にしています。特に自分以外のテスターやプログラマーが見つけたバグで操作手順や条件や状態が複雑なもの、朝会で聞いたけどどのようなバグかよくわからなかったものは、その日のうちに聞いたり目の前で操作してもらい、そのバグを自分でも出せるように練習しておきます。そうしておかないとバグが直ってきたときに「よし、直ってる」ということに強い確信を持てないからです。実際に手を動かしてバグを実感しておくと記憶に残りやすく未来のテスト（Testing）に活かせるという利点もあります。
プログラムを修正して再実行する
要求仕様に書かれているとおりに出力できることをプログラムを動かして目で見て確認しました。
