Back on September 9, 1947, Grace Hopper, a Harvard computer scientist, was running tests on a calculator and found calculation errors. She did some investigation and found a moth that had landed between two solenoid contacts, shorting out an electromechanical relay. Apparently, the bug had been attracted by the warmth of the machine.
We now commemorate this occasion every September 9, Tester’s Day.
９月９日はテスターの日なんですって。今年のテスターの日は過ぎてしまったので、来年（だいぶ先だけど）テスターの日にあわせて、バグ供養的な Developer Meetup なんてどうでしょうか。
このエントリーは こちらの記事 を Google 翻訳を使って雑に読んだときに、わたしが何を考えていたかのメモです。マニア向け！
システムやソフトウェアで扱っている日時を標準時に変換してから計算すれば良さそうなんだけど（計算した結果を、どうお客様に見せるかはまた別）
— miwa (@miwa719) 2018年8月15日
テスターだと内部処理がどうなってるか分からないことも多いので、サマータイム開始日、終了日をお題に、心配な事を考えるのは脳内が活性化されて良い。
サマータイムが話題ですね。システムやソフトウェアに手を入れなければならないようなサマータイム導入には反対ですが、サマータイムをお題に「起きたら嫌なこと」や「気にしたいこと」を想像するのは面白い。思いついたことをメモしていこうと思います。*1
*1:わたしはテスターとして組み込み系製品の開発に従事しています。
miwaさんの笑顔の端から滲み出てるの何かと思ったら、このドS成分かあ。（適当な先入観だけど）サディスティックなキャラクターはテストする（ソフトウェアをいじめる）のに向いてそう / “ベテランプログラマーとバグの調査をしたときの…” https://t.co/6IJAg7gDDm
— ぎゃばん@並列プログラミング (@ledsun) 2018年8月5日
“Sadistic Miwa Test” Tシャツできたら呼んでください。
— track8 (@track8) 2018年8月7日
suzuri製です。Tシャツをクリックしてみてね。
うれしい。ありがとうございます！
隣のチームのベテランプログラマーSさんとバグの調査（どの操作が引き金になってるのか）をしたんだけど、特定するまでの時間が（わたし一人でやるより）断然早くて素晴らしかったな。しかもSさん、いちいち悲鳴あげるから（ああ、こういうのがソフトウェアにとって嫌なのか）が分かって良かったです。
— miwa (@miwa719) 2018年8月3日
これ、ツイートではさらっと書いてますけど、とても複雑な状況だったんですよ。非常に多くの入力項目があり、さらにROI*1 も設定できる。わたし自身、どの操作（入力）が引き金になったのか、予想もつきませんでした。すぐに、隣のチームのベテランプログラマーSさんを呼んで、現象を見てもらいました。*2
おかしな状態になる前に、どんな操作（入力）をしていたのか。たまたま、関係しそうな画面を４枚ほどキャプチャーしていたので、それを１枚ずつ見せながら、Sさんに説明しました。
その後も
Sさんのリアクションは、控え目に言って最高でした。こういうのって（テスターにとって）ものすごく有難いんですよ。
このような情報は、当然、設計ドキュメントには載ってない。だから大変貴重です。*3
わたしがやったことを一通り話した後に、どの操作が引き金になっているのかを探りました。*4いま思うと、もうこの時点で「この現象が起きるのなら、どの操作（入力）が関係しているのか」が、Sさんにはある程度わかっていたんだと思います。話を聞きながら、Sさんの頭の中には、プログラム（コード）が浮かんでいたのでしょうね。
今度はSさんの話を聞きながら、わたしが手を動かします。ペアテストに似ていますね。
すこしずつ条件を変えながら「これだ！」という操作（入力）に迫っていきます。いくつかのパターンを試しました。引き金になる操作を特定したのは、それから１０分後くらい。やっぱり早いわー。
今回のケースは、入力値だけでなく、操作順も関係していたので、再現手順を見つけるのが大変なバグでした。同じ値を設定しているのに、再現するときと、再現しないときがあるのです。こういうのは難しいですね。Sさんのナビゲーションがなければ、１時間かけても、たどり着かないかも…。*5
わたしの脳内に「Bはヤバい、Bに注意」が刻まれました。こういう情報も、テスターにとっては貴重です。
Sさんの予想どおり、Bにある値を入れた直後に処理を実行すると、再現しました。Bにある値を入れた後に、違う項目（例えば C）に値を入れてから処理を実行すると、再現しませんでした。
こんなのを目の前で見せられると、プログラマーすごいなあ、これは真似できない、と思いますね。鮮やかでした。素晴らしかった！
確信はないのだけど、前々から（もしかしてそうなのかな？）と思っていることがあります。それは「ベテランプログラマーほど、不安なところを包み隠さず、丁寧に教えてくれる」（傾向がある）ということなんですけど、今回のことで、うちのチームだけではなく、隣のチームでも観測することができたので（やはり、そうなのかもしれない）と思っている、今日この頃です。*6
今回の「再現手順を見つけるのが大変なバグ」を説明するのに、簡単な画面を作りました。でも、文章で伝わりそうだから、いらなかったですね。せっかく作ったので、貼っておきます。（ラベルの枠のコーナーを丸くするやり方を覚えました！）
大層なタイトルをつけてしまいましたが、先日 Twitter に連投したことをブログに残しておきたいだけのエントリーです。（すこしだけ、補足しました）
つい最近「内部設計情報」をプログラマーに聞いて（そういう風に実装してるなら、こっちもテストしないとなー）ということがあったんだけど、ツイートだと複雑すぎて伝わる気がしない。
— miwa (@miwa719) 2018年7月26日
すごーく簡単にして、連投してみるけど、伝わるかな？ https://t.co/Xtxwlorf0j
例
— miwa (@miwa719) 2018年7月26日
Buttonを押すとText1〜3に設定した値を登録します。
これまであったA(First)という条件に加えて、機能追加でB(Second)の条件が増えました。
説明用に画面を作った！すごい！ pic.twitter.com/tQFNDcfst6
Text1〜3の値の持ち方が気になってプログラマーSさんに聞きました。A、Bを切り替えた時にどう表示してますかって。
— miwa (@miwa719) 2018年7月26日
① Text1〜3に内部変数の値を設定し直す
② B用のText1〜3をもう1セット増やした（ので、切り替えた時に設定し直さない）
③ それ以外
①と②なら、①の方が心配事が増えます。ある程度動作が保証されているAについても、機能追加したBと同等のテストをしたいなと思う。
— miwa (@miwa719) 2018年7月26日
値を設定するところが間違っていたら嫌なので、AとBのText1〜3に全部違う値を設定して、登録後の値1つ1つを丁寧に確認したいです。
「今回、Aについては動作的には何も変わりませんよ」と言われたら、機能追加したBしかテストしないかもしれないし、Aについても「登録できるよね」くらいのテストしかしないかもしれない。
— miwa (@miwa719) 2018年7月26日
でも、作り方(内部設計情報)を知ったら、テストしたいところが変わってくるのを、何度も体験してます。
わたしの場合は、どちらかと言うと内部設計情報を聞いて、テストが増えることが多いかもなあ。で @m_seki に「そこまでやんなくても大丈夫。なぜなら◯◯という素晴らしい機構があって、その心配事は起きないようになってるから」と言われて、やめさせられる。
— miwa (@miwa719) 2018年7月26日
そうは言われても、心配してることが本当に起きないのか、自分の目で見ないと気が済まないときは試しているな…。
— miwa (@miwa719) 2018年7月26日
それでやっぱり心配してる事が起きたじゃん！と言うのは、今のところ無い。
内部設計情報を知ることで、明らかにやる必要のないテストを減らすことはできると思う。時間は有限なので、その中でより価値の高い（この場合は積極的にバグを見つける）テストをするためのヒントにもなるよね。
— miwa (@miwa719) 2018年7月26日
近くにプログラマーがいるなら、心配事を聞いてみるといいと思います。
おしまいです。
今回ツイートしたのは「画面に表示する項目と内部変数の関係」ですが、このように「内部設計情報」を知ることで、心配事が変わる（テストが変わる）のは、わりとよくあります。（だからと言って、なんでもかんでも知りたい、という感じでもないのですが…）
どんなところの「内部設計情報」を知りたいと思うのか。すこし考えてみたのですけど、一つ言えるのは、テストが大変そうなところ（似たような項目が多いとか、何かの種類が多いとか、状態がたくさんあるとか）は、特に知りたいです。*1また、知りたいと思ったときは、すでにその時点で、２種類くらいのやり方を予測*2していることが多いように思います。
ただこれは、プログラマーがどのように設計したのか、を当てることを目的とした予測ではありません。ですので「内部設計情報」を知ることができないときでも、システムやソフトウェアを動かして得られる結果から、それを予測し、テストに活用します。*3
これは、テスターによく見られる習性なのでしょうか？
いつも使っているお気に入りのアプリでも、こんなことをしていますね。（以下のツイートを参照）
Amazonのほしい物リスト
— miwa (@miwa719) 2018年7月8日
検索機能で "ワイン" を探そうとしたんだけど、うまく動かなかった…!!
英数字なら見つけてくれるから、日本語対応、忘れちゃったのかな。
半角記号も嫌みたい。 pic.twitter.com/9NJdhb9tYx
これ Safari でも同じ結果でした。
— miwa (@miwa719) 2018年7月8日
(はじめのはiPhoneアプリ)
UIは違うけど、検索処理のコアな部分は同じところを通ってるのかな。
Amazon社のエンジニアに「内部設計情報」を聞くことはできませんので、動かして得られた結果から「内部設計」を予測しています。（これ、Safariでもうまく動かなかったのですが、そのうまく動かないっぷりがiPhoneアプリと同じだったので、ほっとしました。）
そうそう、秋山さんからこんなコメントをいただいたので、いつかお返事したい。
「内部設計情報を知る（理解する）ためにかかる時間」と「知ることによって減らせたテストで儲けた時間」とのトーレドオフになりますので、
— akiyama924🏝 (@akiyama924) 2018年7月26日
1. 聞く側が事前に知っておくと良いこと
2. 聞く内容（取得すべき内部設計情報）
3. その内部設計情報の活用の仕方
を知りたいと思いました。
以前、ある方から「普段、当たり前にやっていることって何ですか？」と質問があり、その場では即答できなかったのですが、最近になって（これ、当たり前にやってることかも）と思うことがあったので、紹介します。
わたしは、テスターとして組み込み系製品の開発に従事しています。ですので、この記事は、その「テスト」に関して「当たり前にやっていること」のひとつになります。
わたしは、１日の大半をテストに費やしているのですが「テストする順番」を、かなり（無意識に）気にしてるようです。ただ、急ぎでやらなければならないもの（緊急性の高いもの）は、先にやるので、ここでは除きますね。
どのように順番を決めているのか。その順番にしている理由、順番を決めるときの材料やシグナルなども織り込みながら、１日を３つに分けて紹介します。
問題が出たら嫌なところ、複雑なところをテストします。もうすこし具体的に書くと、こんな感じです。
わたしたちのチームは、朝会（９時１５分〜１０時）で、チケットの読み合わせをしています。これをやることで、テスターのわたしも、今、開発してるものが、どんな状況にあるのか（どこが、なぜ、うまくいってないのか、昨日困っていたあれはどうなったのか、内部の設計や実装など）を知ることができます。同時に、今日からテストできるもの（昨日コミットされたチケット）もわかります。プログラマーひとりひとりの表情を見ながら、その言葉に耳を傾け、場合によっては質問し、テスト可能なチケットを整理しながら「テストする順番」を決めます。ソフトウェアは毎日変化しているので、それに合わせてテストも毎日調整します。
午前中に「問題が出たら嫌なところ、複雑なところをテスト」をするのは、いち早く重大な問題を見つけて、チームのみんなにお知らせしたい、のも理由の一つなのですが、それよりも（これは多くの方がそうだと思いますが）朝会の後のこの時間が、１日の中で最も脳内がスッキリしていて、冴えているからです。おかしさを見つけられる感度が、就業時間の中で最高のはず。おそらく身体能力も相当高い。*1
その他にも午前中にテストするものがあります。それは、前日までに一度はトライしようとしたけど、挫折してやめてしまったテストです。
などなど。理由はいろいろありますが、要は、気分が乗らなくて後回しにしたテストです。人間だからそんな日もあるよね。
これは、もう自分で分かっていますからね、午前中にやらないとダメですね。今日も午後に回したら、また挫折します。これはもう仕事だから仕方ない、今日こそはやるぞ！と思ってやります。*2
それほど頭を使わなくてもできるテストに充てます。例えば、画面に表示する文字（ラベル）の位置、色、メッセージなどの変更、アイコン（絵）の貼り替えとか。まあ、そんなところでも、あとから問題が見つかって（そんな作りになっていたとは！）となることもあるんですけどね。この時間帯は、どうしても集中力が低下してしまうので、自分自身のテストのミス（見逃し）も多くなります。人間だから仕方ない。だから、頭を使うような難しいテストや、混み入ったことは、極力やらないようにしています。
上記に書いたもの以外をテストします。午前中の続きをやることも多いです。また頭が冴えてきますからね。乗ってきて過集中になるのも、大抵この時間帯ですね。そうそう、集中して物事に取り組むのは良いことですが、集中してること以外（外側）は「散漫」になっているんですって。それを聞いたときに（確かに、そうだわ）と思って、ちょっとゾッとしました。だから、集中しすぎないために１時間ごとに休憩するよう、心がけています。*3
また、午後５時以降に取りかかったチケットは（大丈夫だろう）と思っても close しないことにしています。これも「疲れ」から誘発されるかもしれないミスを防ぐためです。翌日にもう一度、軽く確認してから close します。（週末の夜にコミットしないのと、似てるかもしれませんね。）
わたしたちは、複数の製品（バージョン）を同時に並行開発しているので、スケジュール（締め切り）を気にします。締め切りが早いものは、できるだけ先にテストできるように調整します。締め切りが遅いものは、重要な機能であっても後回しです。（例外はありますが）
それから、担当プログラマーが今日いるかどうかも気にします。例えば、テストできる状態にはなっているけど、今日は休暇でいないような場合は（内容にもよりますが）優先順は下がります。これは、もしテストしてクラッシュするようなバグが見つかっても、その場ですぐに見てもらえないからです。明日来るんだから、わざわざ今日テストしなくてもいいか、みたいな感じですね。
普段、わたしが「当たり前にやっていること」のひとつ「テストする順番を気にする」を紹介しました。
いつも無意識にやっていることを、改めて見つめ直し、言語化したら、これまで見えてなかった「何か」が浮かび上がってくるのかな…と、淡い期待もあったのですが、そうでもなかったですね。本当に当たり前のことだったわ。*4
*1:視力とか、腕力とか、聴力とか。
*2:それでも、どうしてもダメなときは、同僚のテスターに「何時から一緒にやろう！」とお願いしている。もう逃げることはできないので、午後でも大丈夫。
*3:Apple Watchが教えてくれるので、少しは改善している。
*4:公開するのも躊躇うレベルですが、せっかく書いたので放流します。
