CAT GETTING OUT OF A BAG

What the tester is thinking.

デブサミに行ってきた(1)

目黒の雅叙園で開催されたDevelopers Summit 2020(デブサミ)に行ってきた。今回も大盛況で満員のセッションが多く、人気のセッションでは壁沿いに立ち見も出ていた。どの会場も入場待ちの長い列ができていて大変そうだったが、わたしはお金の力(個人スポンサー)で解決したので快適だった。二日間でいくつかのセッションを聴講した。特に良かったものを数回にわけて書き記しておく。

『起業家的?!エンジニアのススメ』玉川 憲さん(株式会社ソラコム)

玉川さんの講演を聴くのは二回目で、調べたら前回は2016年のデブサミ(SORACOM立ち上げ格闘記)だった。あれから4年たつのか。プロダクトが素晴らしいのは言うまでもないが、多岐の分野において実にさまざまなユースケースが生まれ、モノと繋がり新しいIoTシステムとして人々の役に立っているのが本当に素晴らしい。昨年11月に福岡空港の『ふくや』でご家庭の明太子が無くなる前に自動的にお届けする『ふくやIoT』の動画広告をみて「福岡すごいなwww」と思っていたのだが、これもSORACOMの仕業だったのを知る。

わたしたちが開発してる製品もかなりとても素晴らしいのだが、そういえばSORACOMに感じる「壮大なロマン」のような感情をもってないことに気づく。少なくともいまのわたしの中には無い。いいなあ、羨ましいなと思う。今回の講演のキーワードのひとつは『パッション』だった。玉川さんのそれは「テクノロジー民主化」とのこと。わたしはなんだろうな。開発しているモノ(医療機器)を通して「ひとりでも多くの人たちが健やかで幸せな人生を送れるよう手助けすること」だろうか。普段の開発では具体的な問題を解いていることが多く「世界中の人々の健康と幸せのためにテストしてバグを見つけるのだ!」と燃えあがるような感じでもないんだけど、根底にあるのはそれだと思った。

スピーカーラウンジ(控室)にて

最初の講演からとても良くて頭が疲れてしまったので休むことにした。個人スポンサーはスピーカーラウンジ(控室)が利用できるのだ。美味しいコーヒーとお菓子と電源とWiFiが付いてる。最高である。ジャガード織りのカバーのついた椅子に腰かけてぼーっとしていたら、斜め前のほうに玉川さんが座っているのを見つける。同行者の @m_seki に小声で「玉川さんがいるよ」と伝え、二人で話しに行く。聴講しながらiPadでメモしたものを見せたら喜んでくれた。「どこかに公開するんですか?もし公開したら教えてください。きれいに書いてあるから見たい!」と名刺を差し出す玉川さん。とても嬉しかったのに、自分の描いた絵を見せびらかしている子供のようだ(しかも初対面の人に)と思ったら急に恥ずかしくなった。「たいしたこと書いてないので…」ともじもじしてしまったが、そこに書いてあるのは玉川さんがさっき話した内容である。そういう意味ではないのだが、たいへん誤解をまねく表現だ。これからは気をつけよう。

玉川さんにはこんなことを聞いてみた。「普段仕事しているといろんなことがあって、例えば、嫌なことがあったときはどんな風に気持ちを切り替えるんですか?」

パッションだけでは乗り越えられないときってないのだろうか(きっとあるに違いない)と思ったのだが「ない」みたいだった。もうね、なんて言うかパッションがすごいのだよ、パッションが。それくらいでないと世界を変えることなんてできないのだと納得した。そしてちゃんとわたしのレベルに合わせて「睡眠の時間を十分にとったり、食事もちゃんとして、ストレスを受けにくいようにはしてますよ」とも話してくれた。なんて良い人なんだ…と感激した。

そしてこれが「たいしたこと書いてないので…」のやつである。

f:id:miwa719:20200215123230j:plain

ソフトウェア技術者のためのバグ検出ドリル(問題6:ミケランジェロの呪いー入退室セキュリティ・システムの不可解なバグ)

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

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

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

 

要求仕様フェーズの問題が解きおわり今日から設計フェーズです。問題6の制限時間はなんと4時間。手強い問題なのかな?とやる気満々で問題文を読みはじめたのですが、、、

f:id:miwa719:20200201144714j:plain

そのものずばりの解答が1行目に書いてあって、うっかり視界に入ってしまった…。ううう。これから解く人は注意してくださいね。わたしは再発を防ぐために解答を隠す用の便箋を挟みました。*2

答えは分かってしまったのですが、このバグから普段の開発でどのようなことに注意すると良さそうかを考えたいと思います。気が向いたら追記しますが、まずは注意喚起でした。

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

*2:電子書籍リーダーで見たくない部分をさっと隠す機能ってあるのかな。幸い?本ドリルの電子書籍版は今のところないようです。

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

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

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

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

 

f:id:miwa719:20200125092705j:plain

この問題で著者の山浦さんが用意した解答(バグ)は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

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

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

 

f:id:miwa719:20200111135909j:plain

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

 

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

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

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

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

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

 

f:id:miwa719:20200105101746j:plain

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

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


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

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

www.1101.com

 

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