テスターから見た「テストの合間にプログラミングする」

druby.hatenablog.com

この記事を読んだときに、この「テストの合間にプログラミングする」という感覚が、はたして読み手に伝わるのかしら、、と思いまして、テスターの立ち位置で、いくつかツイートしました。
今回はそれを引用して、さらに補足します。

2009年にも言ってたみたい。というかずっと言ってたけど記録が残ってるのは珍しい。


元の記事にも書いてあるように、咳マニアとか、咳フリークと言われる(または自覚がある)人たちにとっては、わりとおなじみのフレーズなのかもしれませんね。「テストの合間にプログラミングする」って、どのような風景を思い浮かべているのでしょうか。とても興味があります。 

バグを見つけたら、スッと立ち上がり、そのストーリーの担当プログラマーを探します。(うちのチームは『全員同席』なので、大抵すぐに見つかる)

miwa719.hatenablog.com

そのときのプログラマーのシチュエーションは、こんな感じです。

  • コードを書いてる(ひとりで)
  • ペアプロしてる(2、3名で)
  • 数人のプログラマーが集まって、小さなホワイトボードに何かを書きながら話してる
  • テストしてる(プログラマーも1日1時間、テストの時間があります)
  • すでに誰かに割り込まれてる

バグを見つけたら、と書いたけれど、ちょっと違和感があるようなとき(例えば、この操作をしたときだけ、反応が少し遅い)や、質問や相談ごと(こういうテストをしてみたいのだけど、どうやったらその状態が作れますか?)も、プログラマーに話しに行きます。

miwa719.hatenablog.com


「テストの合間にプログラミングする」の「テストの時間」は、誰かのテストで見つかった問題、疑問、相談について、割り込まれて作業するのも「テストの時間」であり、1日1時間のテストの時間だけが、プログラマーにとっての「テストの時間」ではありません。

そのような「テストの時間」が、1日にどれくらいあるのかは、人それぞれですが、うちのチームのエースプログラマーを見ていると、1日のほとんどが「テストの時間」なんじゃないかな。でも、プログラミングもしてる(ストーリーが仕上がってくるからね)。この辺は、元の記事にも書いてありますね。

(速い人ほど)多くの時間テストに関わっていることになる。


わたしは、これまでいくつかの組織、チームに所属してきましたが、こんなにテストに時間を使っているプログラマーがいるチームは、見たことがありません。

 

さて、今回この記事を書くにあたって、久しぶりに過去の記事を読み返しているのですが、こんなのも見つけました。プログラマーを褒めるためにも、割り込んでる!

miwa719.hatenablog.com

テスターなので、普段からかなり意地悪なことをするんですけど、それでも壊れない、不安定さを感じない、これは頑丈に作られているなと、テストしていて(これは、素晴らしい・・・)と、思う瞬間があるんですね。プログラマーが、様々なユースケースを想定した上で、丁寧に設計、実装してきたのが、分かるんですよ。そんなシステム、ソフトウェアの動きを目の当たりすると、これはもう、一言言わずにはいられない。ストーリーを担当したプログラマーのところに行って「こんな(ひどい)ことしたんだけど、ちゃんと動いてた!すごい!感動しました!」て、割り込むんですね。

「割り込む」という言葉は「無理に押し割って入ること」「横入り」のように、どちらかというと、悪いイメージや印象を持つことが、多いかもしれないですね。でも、うちのチームは「これ」が推奨されています。(とは言っても、他人の作業に割り込むのは、練習しないと出来ません。わたしも出来るようになるまで、数ヶ月かかりました。)

割り込まれたプログラマーは、コードを書く手を止めます。ペアプロも、設計レビューも中断します。うちのチームで「割り込み」は、優先度が高いものとして扱われているので、コンピュータの世界での、割り込み(インターラプト)「実行中の処理を中断して、優先度の高い別の処理をする仕組み」に、似ていますね。


そうそう、プログラマーだけでなく、テスター同士でも、お互いのテスト中に割り込んで、いろんなことを話します。

  • 昨日コミットされた◯◯だけど、さっきこんなバグを見つけたよ(目の前で見せる)
  • おおお
  • それが出るなら、これはどうかな(おもむろにペアテストがはじまる)
  • うーん(深く)触るのは、このバグを修正してからの方がいいかもね

  • ◉◉のテスト、シミュレータ環境では動いたけど、これ、実機環境でも確認したい
  • うんうん、ハードウェアの制御も絡んでくるし、タイミングが微妙に変わってくるかもしれないよね
  • じゃあ、午後、テストベイで一緒にテストしようか
  • OK


もちろん、テスターも(テスト中に)プログラマーに割り込まれます。

  • 昨日のバグが再現しないので、一緒にテストして欲しいです
  • ◯◯について、テストの作戦を立てたいんだけど、今からちょっといいですか?
  • **の件、直してみたんですけど、こんな感じでどうですか?(コミットする前に、プログラマーの開発環境で見せてもらい、動作確認することもある)

そう考えると、プログラマーにとっては「テストの合間にプログラミングする」だけど、テスターにとっては「テストの合間にテストする」ですね。(わかりづらい!)

 

「テストの合間にプログラミングする」を、テスターの目線で補足しました。うちのチームの開発風景と「テストの合間にプログラミングする」この感覚が、すこしでも伝わりましたら、うれしいです。

 

間違えたことを大切にする


これはバグだと思ったけど、調べたらそういう仕様だったとき、あなたはどうしてる?


f:id:miwa719:20171223135220p:plain

つい二、三日前にそんなことがあって、仕様だと分かったのは、Bugチケットを発行した後だったのだけど『そっ閉じ』しないで、チームのみんなに見てもらったよ。

"そういう仕様で作ったから、そうふるまうのは正しいよね"

と、認識を合わせた上で

"バグだと思ってしまったのは何故なのか?"

に、論点(興味)が移るのが、うちのチームの素晴らしいところ。(今回の記事はチームの自慢が目的ではないので、ああ、そうなんだね、くらいに読んでね。)

  • たしかに、この操作でこれが出来ないのは、分かりづらいかもね
  • なんでこうしたんだっけ?
  • ここは、◯◯のふるまいも気にして決めたんだよね
  • ちょっと無理があるのかな
  • そもそも、●●の制約を入れた時点で負けじゃない?
  • もう一度(全体的な仕様を)考えてみようか
  • じゃあ、続きは二次会で


f:id:miwa719:20171223135220p:plain


何かを「間違える」のは、どちらかと言うとネガティブなイメージが強いから、間違えたことを恥ずかしく思ったり、隠したい気持ちになるんだけど、単に自身の勉強不足や注意散漫、だけでは済まされないコトが「間違える」には含まれている。


だから、あなたが何かを間違えたら『そっ閉じ』しないで、まずは、あなたの周りの人に話してみるといいと思います。

これは、開発現場だけの話ではなく、日常生活の中で起きる「間違い」全般に言えることなんだけど、わたしは(組み込みシステムの)テスターなので、冒頭のような例を出して説明しました。

「間違える」は、とても分かりやすくて、じぶんで気がつくことができる便利なシグナルだから、ぜひ、今日から練習してみてね。


じぶんの間違いを大切にできるようになると、周りの人の間違いも大切にできるようになるよ。

f:id:miwa719:20171223100219j:plain

とちぎRuby会議07 ふりかえり #toruby

とちぎRuby会議07で、主にわたしが担当した『』を中心に、ひとりふりかえりをしました。

ランチセッションの「からあげ弁当」

  • 量が異常。
  • Twitterのタイムラインが「からあげ」だった。

 

  • ちなみに、からあげ弁当は36個購入したので、参加者の7割の方が食べた。
  • 異常だったのは量だけで、からあげ弁当自体は、おおむね好評だった。
  • 今後は値段に騙されないようにする。(小盛り450円であの量は想像できなかった。テスターなのに!)
  • 月1の勉強会で試食して、事前にお弁当の量を確認する。
  • ランチセッションとパーティーを組み合わせるときは、お弁当の量に気をつける。(今回は全く気にしてなかった)
  • お弁当を渡すとき、無料と有料の列を分ければよかった。
  • 講演者は無料だったのに、お金を貰っちゃった人がいるかも。ごめんなさい。
  • 次回以降の #toruby イベントで使える『お弁当無料券』を発行することで、対応したい。

コーヒーマシン

  • アンジェリカさんにお借りした。とても良かった!
  • 挽きたてのコーヒーは、香りもいいし、美味しい。売れ行きもよかった。
  • 前回はパーティーのときに、大きなコーヒーマシンを持ってきてもらったのだけど、操作が難しくてうまく使えなかった。今回は操作が簡単なものを、開場前に設置してもらい、使い方を教えてもらった。
  • 操作は、水とコーヒー豆を補充して、コーヒーかすを捨てれば良い。楽だった。
  • コーヒーマシンが人間に何をして欲しいかは、ディスプレイに表示される。分かりやすかった。
  • 時々チェックしてたんだけど、@youchan さんにコーヒーかすを捨ててもらったりして、助かった。他にも気付いてやってくださった方がいるかもしれない。ありがとうございます!

他に用意した飲み物

  • ペットボトル(2リットル)18本
  • ウィスキンソン ジンジャーエール(辛口) 24本
  • あたたかい飲み物(緑茶、紅茶、ココア)電気ポットはホールのものを使用。
  • ペットボトルはほとんど残らなかった。この時期なら、あと5、6本あってもよかったかも。

パーティー(Deli & Dolce リトルアンジェリカ)

  • お料理の搬入などはスムーズで特に問題なかった。
  • ホールの搬入口は開いていたけど、施錠してあるときもあるみたい。搬入時間近くになったら、開錠してあるかどうか見にいったほうが良い。(今回は午前中から、わたしたちが使っていて、単に開けっ放しだったという可能性もある…)
  • 前回、同じ規模でやったときに、ピザやご飯モノがあっという間に売り切れてしまったことから、今回は前菜ぽいもの(グリーンサラダやカポナータのようなもの)を少なめにして、その代わりに「お腹にたまるもの」を多めにしてもらったのだが、それが裏目に出てしまった。
  • みんな、からあげ弁当のせい。
  • 今回もアンジェリカさんのお料理は、ひとつひとつ丁寧に作ってあって、とても美味しかった。並べ方も大変きれいだったのに、写真を撮るのを忘れた。
  • ドルチェも本格的なものを2種類作ってもらった。甘さ控えめのエスプレッソのプリンとパウンドケーキ。
  • ワインを赤と白1本ずつ持ってきてもらった。赤ワインはわりと早いうちになくなった。白ワインがグラス1杯分残ったくらい。
  • アルコール類の準備はよく分からないので(飲まない人もいるし)今までどおり、飲みたい人が休み時間に買いに行くスタイルでよいと思った。

  • 急遽、テイクアウトにも対応してもらった。
  • アンジェリカさんが「ラップとかアルミホイル、お店から持ってきましょうか?」て言ってくださったんだけど、(たくさん余ってしまったのは、絶対からあげ弁当のせいなので)申し訳なくてあるもので対応した。あるものって、アンジェリカさんが持ってきた紙皿なんだけど、それを大量に使わせてもらった。本当に申し訳なかった。

  • いつまでも、みんなのこころに残る、アンジェリカさんのごちそう。

 

 

その他

  • 特にお菓子類は用意しなかったんだけど、テーブルにお土産のお菓子がたくさん並んでいた。ありがとうございます!

  • はじめから会場のうしろに、椅子を5つくらいフリーで並べておけばよかった。
  • 並べた後、少ししたら大場さんちのお子ちゃまが寝た。眠かったんだよね。気が付くのが遅くてごめんね。
  • 子供用ベッド?にするには椅子が3つ必要。落ちないようにもう1つくらい要る。長座布団があるとなおよい。
  • 大人が座ってもいいし、次回ははじめから多めに並べておこう。
  • #toruby 初参加の方には、LTのときに一言しゃべってもらって、プレゼントを持っていってもらえばよかったかもしれないね。
  • 酒匂さんの扱いが雑だった。ごめんなさいごめんなさい。

  • そういう扱いは 本当に偉い人 に対してはOKらしい。知らなかった。

 

  • 閉会後の片付けをたくさんの方に手伝ってもらった。ありがとうございます。
  • アンジェリカさんのお料理をたくさんの方にテイクアウトしてもらった。ありがとうございます。

参加率は94%くらい

  • 今回は前払いだったから入場チェックはしなかったんだけど、勉強会のときに数えたら(数え間違いがなければ)51名だった。
  • 参加申込みが50名、招待講演が3名、急遽 @chomado さんに呼び出された!マイクロソフトの @okazuki さんもいれて、全員参加で54名。
  • なので、参加率は94%くらい。
  • だいたいいつもと同じだった。

 

ひとりふりかえりは、こんな感じです。続きは9月の #toruby 勉強会で!

 

正しそうなことを疑うこと(統一感を例に)

f:id:miwa719:20170312093225p:plain

システムを組み合わせた状態でテストしていると、自ずと「システム全体として統一感がとれているか?」のような視点でも確認しますよね。わたしの場合は ”わざわざ確認する” というよりは、テスト対象を触っていて、統一感がとれていない事象に遭遇したとき、それが違和感となって現れることが多いです。なんとなく気持ち悪かったり、不安になったり、混乱したり、意図しない挙動を見たり、操作を間違えたりするんですね。

ユーザーインターフェースの見た目や操作感、画面遷移、使われる用語やメッセージの文言、データの取り扱いなど、統一感をキーに注目するところは沢山あると思います。

そういえば昨日も1箇所直してもらったなー。数値と単位の間に隙間(半角スペース)がある画面とない画面がありまして、動作には全く影響しないのだけど。(そういった些細なところにもわたしたちは気を配って日々モノを作っている)


さてさて、統一感があることは良いことなのですが、いつでも、どんなときも、それが当てはまるわけではない、というのがちょっと難しい。統一感がある=良い!と思ってしまい、問題に気づけないことがありそうで、これがこわいのです。

例えば、あるシステムではコマンドボタンにフォーカスがあるときにreturnキーを押しても実行できるようになっていたとします。

システム内のすべてのコマンドボタンを触りreturnキーを押して実行できれば、その操作方法は「統一感がある」ということになります。

もし、あるコマンドボタンだけreturnキーを押しても実行できなかったとしたら(あれ?イベント処理を書くのが漏れたかな?)と思い、担当のプログラマーに報告するのでしょうね。


確かに漏れた場合もあるのですが、このコマンドボタンが「X線の曝射ボタン」だとしたらどうでしょうか?(あくまでも例です。ライフラインや人体に危険を及ぼす可能性のあるボタンを想像してください。)

そう、ここではユーザーが”間違って”曝射ボタンを押さないように、わざとreturnキーでは実行できないようにしています。ここに操作の統一感はありません。

それでは、逆に考えてみます。

X線の曝射ボタン」がreturnキーで実行できたとして、果たして(これだと、まずいのでは…)と思えるのか。

曝射ボタンの場合は(あくまでも例)もう分かったのでいいのですが、まだ見つかっていない問題に、わたしは気づけるのでしょうか。

それに気づくためには、 一般的に正しいと言われていること(今回の場合は、統一感がとれていること)にさえも、惑わされてはいけないのだなぁと思います。

本当に正しいのかな?
それは自身の価値観や固定観念を疑うことでもあります。

テスト脳を鍛える

ある処理の応答時間を計測し、何秒以内だったら Pass/Fail を判定するようなテストケース、ありますよね。
最近、わたしたちのチームでこんなことが起きました。期待している時間内に応答が返ってきたので、テスト結果は ”Pass” になったのですが、合否判定係りから「計測結果がやけに早すぎるから、念のためもう一度計測してみてください」と物言いがつき、取り直し(再テスト)になったのです。

電子計算機の世界に居りますと「応答時間は早ければ早いほど良い」と思いがちではないでしょうか。でも、早すぎてお客様をドキドキさせてしまうことがあるかもしれないし*1、他の処理と待ち合わせしてるようなものですと、早いほうが待ちきれずタイムアウトしてしまい、その結果やりたいことが出来ない、なんてことが起きるかもしれない。そういった問題(処理が早すぎる)ではなく、テスターが実施したテスト(手順やデータや環境)が間違っていて”早い結果が出てしまう”可能性もありますね。今回の場合は、それ(テスト手順の間違い)でした。

では、より間違いにくいテスト手順に書き直して、テストしたとしましょう。さて、応答時間が同じように早かった場合に、テスターは(あれ?おかしいかも?)と気づけるのでしょうか。「よし、3秒以内に返ってきたからOK!」となってしまい、気づけないかもしれませんね。それならば、判定基準に「何秒以上」の記載を追加すればよいのではないか、となるのかもしれません。

ところで、わたしたちが開発している製品は、お客様に何を提供するものであるのか、お客様に使っていただく前に、この製品をテストする者に求められている感知力、想像力は、どの程度であるべきなのでしょうか。そのようなことを考えていますと、なんでもかんでもテストケースに書いておけばいい、そんな単純なことではないのかもしれないなぁと思うのです。まあ、書いてあれば確かに気づけることもありますので、そういった意味では書いておいたほうがいいのでしょうけど、書いたことで安心してしまい、テスターとしての嗅覚が鈍ってしまうのではないか。それがとても心配です。

今回の物言いの件は、わたしたちが毎日行っている『テストの朝会』で話題になりましたので、テスター全員が知っています。ですから今後、特に計測するようなテストを行うときは、今回のことを思い出し「早すぎないかな?」という観点でも見ることができるようになるかもしれない。テストケースだって絶対正しいとは限らないのだから「自分が今やってるテストは本当にやりたいテストになっているのかな?」と、テストそのものや、自分自身を疑うことができるようになるかもしれない。

いま起きているホットな問題をみんなで話し、みんなでちょっと考えてみる。1日1つでいいと思います。時間にしたら5分もかかりません。わたしが(あなたが)気づいた問題や心配ごとを隣のテスターに話すのです。そういった表には見えづらい地味な日々の活動に、わたし自身のテスト脳は鍛えられているような気がします。

*1:切符の自販機や銀行ATMの音声ガイドが苦手です。早く選んで!早く入れて!早く取って!と急かされているような気持ちになってしまい、いつもドキドキしている。

フラットシューズのこと

わたしはフラットシューズが好きで、真冬の季節を除いた10か月間、ほとんどの日をフラットシューズで過ごしています。一日中履いていても足が痛くならないので、その分、違うことに集中でき、精神的にも楽になれるのが好きな理由です。

とはいっても、靴選びは難しく、自分の足のカタチに優しくフィットし、履いていてストレスを感じない、それでいて、デザイン(見た目)も自分好み、そんなフラットシューズには、なかなか出逢えません。でも、出逢ってしまったら、次のお気に入りが見つかるまで、色を変え、柄を変え、もうそればかり履いてます。

今夜はクリスマス。そろそろフラットシューズともお別れの季節なので、その前にお気に入りのフラットシューズのことを書いておこうと思います。

 

f:id:miwa719:20161225210952j:plain

こちらのCARNETのブラックエナメルは現在2足目。とても柔らかくて履いてることを忘れるくらい、足に負担がかかりません。そうそう、わたしは車で通勤しているのでフラットシューズは都合がいいのです。ドライビングシューズに履き替えなくても大丈夫!

f:id:miwa719:20161225211304j:plain

色(柄)違いのレオパードはだいぶヘタってきました。こちらはスエード調なので、新調するのは夏の終わり頃でもいいかな。それまで持つようにできるだけ丁寧に履こうと思います。

f:id:miwa719:20161225211400j:plain

エナメルの赤はもうこれだけでかなり目立つので、シックな装いに合わせて履きたいと思っているのですが、毎朝玄関を出るときに2、3秒で靴を決めてバタバタと出ていくので、トンチンカンな組み合わせになることも…。車を運転しながら(あーあ)なんて思うのだけど、こんな日ほど面白いバグを見つけられたりします。

 

似たようなデザインでイタリアのシューズブランドPELLICOのフラットシューズや、パリのダンスブランドrepettoのバレエシューズがありますね。こちらも履き心地が大変良さそうなんですが、PELLICO1足でCARNETが4足買える!repettoならCARNET3足!と思うと、なかなか手がでません。

 

mamiamamiyashopping.hatenadiary.jp


こちらは雨宮まみさんがおすすめしていたフラットシューズ。メッシュ風なので春夏用なのかもしれないけど、ブラックとブルーを購入したので、冬でも気にせずに履いてます。なめらかな曲線のカットが綺麗です。大切に履きたいと思います。

 

気軽に思考パターンを取り替えたいから『お面をかぶる ( put on a mask ) 』

 

 

わたしもテストしている最中に同僚のテスターの顔を思い浮かべ(◯◯さんならどんなことを試すだろう?どんな意地悪をするだろう?)と想像するときがあります。実際に◯◯さんになりきってテストすることもあります。本当の◯◯さんはそんなこと試さないかもしれないけど、それはそれでいいのです。


仕事中、些細なことでイラッとしたときも、一通りイラッとした後に(こんなとき◯◯さんならどう対処するのかなぁ)と想像してみたりします。この場合は、わたしと同じようにイラッとしてしまう人を思い浮かべてしまうと、イラッに拍車がかかってしまい、仕返しの相談など、余計な想像もしてしまうので、なるべく温厚そう?な人を思い浮かべます。よく思い浮かべるのは秋山さん(@akiyama924)。本当の秋山さんは温厚ではないかもしれないけど、それはそれでいいのです。


なにかに悩んだりしたときも、ひとしきり悩んだ後に(これ◯◯さんに相談したらどんなアドバイスをしてくれるかな)と◯◯さんになりきって想像します。想像上のアドバイスは◯◯さんの表情や声で再生されるので、わりと本格的です。悩みの種類によって◯◯さんは変わります。#toteka で出逢い、とても良い影響を受けた椎葉さん(@bufferings)であったり、岩切さん(@kohsei)であったり…。本当の◯◯さんはそんなアドバイスはしないかもしれないけど、それはそれでいいのです。

 

ロールプレイングゲーム - +b

「理想のプログラマ」といった「理想の何か」になるために、本来の自分を変えて別な自分になる必要があります。しかし変身は痛みを伴うものです。本当に理想のプログラマになろうとすると、あなたの本来の性格や価値観、信条と衝突してしまうことも少なくないでしょう。

(中略)


一時的に別のロールをこなしたり、思考パターンを取り替えたりするときに「帽子をかぶる」と表現することがあります。この「帽子」を使って、そのコンフリクトを回避するのです。

 

@m_seki のブログに書いてあるような「理想の何か」のように、そこまで重くはないけれど、日常生活の中で、思考パターンを「気軽」に「安く」取り替えたいときがあります。そんなとき、わたしは『お面をかぶる ( put on a mask ) 』のです。同僚の◯◯さん、尊敬してやまない◯◯さん、いつかこんな人になりたい…と憧れている◯◯さんの顔を思い浮かべます。そして、◯◯さんになりきって、目の前の課題や問題に再び向き合い、別解を見つけるための手がかりを探すのです。