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

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

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

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

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

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

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

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

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

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

ソフトウェアテスト技法

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

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

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

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

2019年、娘ちゃんは社会人になった。

2020年がはじまってだいたい24分の1が過ぎた。これといってなにもせずになんとなく過ぎてしまった。こんな感じで1月もあっという間に終わるのだろうと思ったけど、なにもしてないわけはなくて毎日ちゃんとなにかはしてる。

2019年は娘ちゃんが社会人になった年でもあった。あのちいさかった娘ちゃんがわたしとおなじ社会人になった。とても不思議な感覚だ。10か月経ったけどまだ慣れない。

20年前のちょうどいまくらいの季節だった。右手をぎゅっと握りしめ、幼稚園バスから降りてきた光景をはっきり覚えている。差し出された手のひらには赤いボタン6個と糸くずがあった。ミキハウスの赤いPコートに視線をうつすとボタンが1つもついてなかった。娘ちゃんがじぶんで取ったところまではわかった。

いまのわたしならいつもどおりの口調で「どうしたの？」と聞くことができる。当時はそれができなかった。思い出すたびにこころが締めつけられる。いろいろいっぱいいっぱいだった。仕方なかった。

わたしの脳内の記憶領域の索引のひとつは娘ちゃんだと思う。胎児、新生児、乳児、幼児、小学生、中学生、高校生、大学生、大学院生。それぞれの学年や季節ごとの行事や日常の些細な出来事や小さな事件などにリンクして、いろんなことを思い出せるのだ。

2019年、娘ちゃんは社会人になった。

娘ちゃんは職場近くのアパートに引っ越した。何かあったときに車で駆けつけられるようにと普段なら絶対にしない長距離運転を2回した。入社式や新人研修や新人歓迎会の話を聞いて、自分が新入社員だった頃を思い出した。仕事やチームの話を聞くにつけ、職場の雰囲気や上司や先輩はこんな人たちなのかなと想像している。休日はたまに同期の仲間と遊んでいるらしい。娘ちゃんの名前が印字してある名刺をもらった。感動した。わたしの名刺と交換した。はじめてもらったお給料でなにか買ってくれると言うので、ずっと使えそうなバッグを選んだ。うれしかった。数日後あらためてバッグをみて泣いた。そして2020年のお正月は、はじめてお年玉をあげなかった。

娘ちゃん社会人1年生が新たな索引となってわたしの記憶に色濃く残りそうだけど、社会人2年生、3年生……は、果たしてどうなるのだろう。

実はすこし前から気づいていることがある。これまで娘ちゃんにわたしが好きで自分勝手に捧げていた（もしかしたら鬱陶しく思われていたかもしれない）パワーが消費しきれずに余っているのだ。ちょっとくらい無駄になってもいいので楽しいことに使いたい。*1わたしはもともとあまり体力がないので、それでも人並み以下なのだろうけど、これまで意識的に（無意識かもしれないが）選択してこなかったことをすこしずつやってみようと思う。

変わらないのは娘ちゃんが生まれる前も、50歳になったいまもソフトウェア技術者で、この職業を選んでよかったということだ。製品開発は本当に面白い。

*1:娘ちゃんにお金がかからなくなり、わたしの預金額も急速に増えていってる。こっちは無駄に消費せず老後のために貯蓄しなくてはならない。

ソフトウェア技術者のためのバグ検出ドリル（問題4：文字変換表のバグ）

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

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

要求仕様フェーズのバグ（問題4『文字変換表のバグ』）

先日、この問題を技術顧問 @m_seki に出題したところ一瞬（だいたい2秒くらい）でバグを見つけられてしまいました。わたしはというと問題文を丁寧に読みはじめたところでしたので唖然としました。そして（このドリルは独りでやろう…）と思いました。このような練習問題をみんなで解く面白さも勉強会などで体験してますが、自分でバグを見つけたい気持ちの強い人はまずは独りでやることをおすすめします。今回は仕方ないので気を取り直して本書に載っているプログラムを実際に動かしてみました。

ソースコード（C言語）を写経する

本書には問題に応じてソースコード（C言語）や実行結果が載っています。著者の山浦恒央さんは以下の手順で解いてほしいと言っています。

1. まず、机上デバッグで、バグを見つける。
2. 見つからない場合、実際にプログラムを動作させ、マシン・デバッグで見つける。
3. 見つけたバグを修正する。

問題4もソースコードと実行結果が載っています。バグのある要求仕様に基づいて実装したのでソースコードも間違っていますし、実行結果も期待したものではありません。
それではうまく動かないっぷりを実際にプログラムを動かして自分の目で見てみましょう。たまたま Visual Studio Code を開いていたのでそれを使ってソースコード（PrintAsciiCode.c）を写経しました。

プログラムを実行する（間違っていることを確認する）

$ clang PrintAsciiCode.c
$ ./a.out

おおぅ、Terminal に printf() の "¥n" がそのまま文字で出力されてしまった…。Mac だと改行コードはどう入れるのだ？と調べたら「option + "¥"」で "\" を入力すればよいのですね。ソースコードを直してもう一度実行し、期待どおり実行結果が間違っていることを確認しました。

この間違っている状態を自分の目で見ておくことは普段の開発でも大切にしています。特に自分以外のテスターやプログラマーが見つけたバグで操作手順や条件や状態が複雑なもの、朝会で聞いたけどどのようなバグかよくわからなかったものは、その日のうちに聞いたり目の前で操作してもらい、そのバグを自分でも出せるように練習しておきます。そうしておかないとバグが直ってきたときに「よし、直ってる」ということに強い確信を持てないからです。実際に手を動かしてバグを実感しておくと記憶に残りやすく未来のテスト（Testing）に活かせるという利点もあります。

プログラムを修正して再実行する

要求仕様に書かれているとおりに出力できることをプログラムを動かして目で見て確認しました。

おわりに

炎上覚悟で言いますが*2 この問題4のタイトル自体がバグだと思います。だってタイトルどおり「文字変換表のバグ」なんだもん。これではバグを見つける面白さが半減してしまいます。*3

はっ！もしかしてこれで安心させる作戦なのかな？実は他にもバグがあるのかも、、、

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

*2:最近、Twitterでこのフレーズをよく見るので一度使ってみたかった

*3:ちなみに @m_seki にはタイトルを見せないで出題したので本当にすごいと思いました。恐れ入った。

ソフトウェア技術者のためのバグ検出ドリル（問題3：入場料計算画面のバグ）

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

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

この問題で著者の山浦さんが用意した解答は2つ。表現の違いはあれど意図したバグ（改善点）は検出できた。うれしい。しかし片方は検出するまでのアプローチがこんなにも違うのか！と思うくらい違う。でも山浦さんの言ってることはわかるしそうだねって思う。まるで開発してるみたいだな。こういうのがとても面白いです。

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

ソフトウェア技術者のためのバグ検出ドリル（問題2：小学生用算数アプリケーションプログラムのバグ）

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

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

 

本書に載っている解決案が非常に勉強になりました。ソフトウェアの中で「ほぼ」の概念を扱うことのむずかしさと考えなくてはならないことが書いてあります。

普段の開発でも要求仕様の「おかしさ」を見つけたあとに「最適解を導き出す」のが本当にむずかしいと実感しています。どうにもできなくて制約や運用でカバーするのは負けだよね。設定で「どうにでもできるようにしておく」ことがあります。それが最適解なのか、それとも最適解を考えるのを放棄した結果なのか。自分自身に問いかけていきたい。

「最適解を導き出す」で任天堂の宮本茂さんの言葉を思い出したので貼っておこう。

アイデアというのは、複数の問題を一気に解決するものである 

www.1101.com

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

ソフトウェア技術者のためのバグ検出ドリル（問題1：コンピュータ・ゲームのバグ）

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

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

昨年の12月に iPad（10.2インチ Wi-Fi 128GB）と Apple Pencil（第1世代）を購入したので練習もかねて手書きしました。GoodNotes 5 というノートアプリを使っています。*2

1問目から解けなくて大丈夫だろうか…。 

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

*2:iPad と Apple Pencil は自分へのクリスマスプレゼントではありません。12月某日、まったくもっておかしな仕事が降ってきまして、当然抵抗したのだけど分かってもらえず（しかも一緒に抵抗してほしいと思っている人がやってあげようとする側にいて一体何を考えているのだと怒りに震えていた）カッとなってお昼休みに購入したのでした。おとなだから自分の機嫌は自分で直すのだ。しかしわたしの機嫌が直ることとその仕事が本当にやるべきものかどうかはまた別の話しである。結局もっとえらい人に言いつけて（いろんな人のがんばりのおかげで）そのおかしな仕事は１日しかやらずに済んだ。よかった。購入した理由はあれだけど iPad と Apple Pencil かなり良いです。手書きの文字をくるっと点線で囲み、別の場所にすーっと移動したときは感動しました。オブジェクトの移動なんて当たり前の機能だけど長年愛用しているほぼ日手帳ではできないので。

『ソフトウェア技術者のためのバグ検出ドリル』をやってみることにしました

わたしの中でドリル本と言えば『ソフトウェアテスト技法ドリル―テスト設計の考え方と実際』ですが、昨年11月にバグを検出することに特化したドリル本『ソフトウェア技術者のためのバグ検出ドリル』が発売されました。

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

さっそく購入してパラパラと眺めたのですが、これは面白そう！

本書は『山浦恒央の“くみこみ”な話 - MONOist（モノイスト）』の内容を大幅に改稿したものとのこと。掲載されているバグ検出問題はぜんぶで31問。どれも著者の山浦恒央さんが体験したバグを元に作ってあるそうです。

monoist.atmarkit.co.jp

わたし自身、これまでバグの生成を含む数々の失敗からたくさんのことを学んできましたが、開発現場で出会えるバグには限りがあります。時間は有限ですし、そもそもバグをなるべく作らないためにチームみんなで尽力しているのでね。だから他人が経験したバグを使い、あたかも自分が出会ってしまったかのような擬似体験ができるのは大変貴重です。ありがとうございます。

6つの開発フェーズ（要求仕様、設計、コーディング、デバッグ、テスト、保守）をカバーしたリアリティのある良質な問題を解き、含蓄に富んだ解説を読みながらソフトウェア開発に必要な4つの能力を鍛えたいと思います。

1. バグを見つける嗅覚
2. 他人の作ったプログラムを読む読解力
3. 必ずバグを見つけるという強靭な精神力
4. 自分の専門外でも仕様をもとにバグを見つける汎用的な技術力

そうそう、各問題には制限時間（最短は10分、最長は4時間）が設けられています。解けても解けなくても時間がきたらおしまいです。残業しない感じが普段の仕事っぽくていいな。