CAT GETTING OUT OF A BAG

What the tester is thinking.

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

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

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

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

 

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

コーヒーマシン

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

他に用意した飲み物

  • ペットボトル（２リットル）１８本
  • ウィスキンソン ジンジャーエール（辛口） ２４本
  • あたたかい飲み物（緑茶、紅茶、ココア）電気ポットはホールのものを使用。
  • ペットボトルはほとんど残らなかった。この時期なら、あと５、６本あってもよかったかも。

パーティー（Deli & Dolce リトルアンジェリカ）

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

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

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

 

 

その他

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

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

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

 

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

参加率は９４％くらい

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

 

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

 

正しそうなことを疑うこと（統一感を例に）

f:id:miwa719:20170312093225p:plain

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

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

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


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

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

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

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


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

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

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

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

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

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

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

テスト脳を鍛える

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

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

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

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

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

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

*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 ) 』のです。同僚の◯◯さん、尊敬してやまない◯◯さん、いつかこんな人になりたい…と憧れている◯◯さんの顔を思い浮かべます。そして、◯◯さんになりきって、目の前の課題や問題に再び向き合い、別解を見つけるための手がかりを探すのです。

 

テスターもバグの原因を知りたいのだ

 

テスターが見つけるバグには、狙い通りに見つかる(またはそれに近い)ものと、そうでないものがありますよね。

前者の「狙い通りに見つかるバグ」というのは、例えば、プログラマーが「いつも動く」を前提に作っていることを想定して、テスターは「動かないときもある」を起こして見つかるものです。

  • 使用するファイルをリネームしてみる
  • データベースのサービスを停止してみる
  • ネットワークケーブルを引き抜いてみる

同期処理なら、こんなことを考えながら、手を動かしていきます。

  • 何をしたら二人は永遠に待ち続けてしまうだろうか
  • お互いの状態を変数でフラグ管理しているのだとしたら、それらが正しく更新されないのはどんな時か
  • その更新が遅れる時はあるのだろうか、実際の状態と変数の値が矛盾してしまうとしたらどんな時か

そうやって見つかるバグは、その原因が何となくですけど、想像できます。


後者は「狙ってないけど出会ってしまったバグ」です。わたしたちのチームは、おかしな状況はプログラマーに見せることが一番喜ばれるのですが、すぐに見てもらえないときは、再現試験も兼ねながら、与えるパラメータを変えたり、怪しそうだなと思う操作のタイミングをずらしながら、同じバグが発生するのか、しないのかを確認します。

ここでも、原因が想像できるものと、そうでないものに分かれます。

何となく原因が想像できるものは（おそらくテスターならみなさんそうだと思いますけど）そこからさらに対象を変えるなどして、似たようなバグを見つけに行こうとします。

でも、原因が全く想像できないものは、それができません。テスターも（どんな実装をしたらこうなるんだろう？）と興味がありますし、バグの原因にもつながる実装寄りの事情（←コードそのものではありません）を知ると、さらにそこをついたようなテストができるようになります。見た目は大したことをやっているようには見えないのに、そんな複雑なことをしてたのかーーと知ったら、いじめ方も変わっていきますよね。

はじめのツイートに戻りますが、わたしがこれまでに遭遇した「実装がまったく思いつかないバグ」は、プログラマーにとっても厄介であることが多いように感じます。ですので「◯◯のように直したら(バグが)出なくなりました」と言われても「おお、よかったー」で終わりにせず、「なにがまずかったの？」と、チームの話題にしてあげるのがよいと思います。*1

 

*1:練度があがると「なにがまずかったの？」は「えー」で通じるようになります

開発ミーティングを途中退出する勇気


朝会、夕会を含め、製品ラインナップ別、さらにはバージョン別に、いろんな開発ミーティング（以降、ミーティング）が開催されます。ここから得られる情報はとても多いのですが、テスターとして全部参加するのは無理なので、選別しています。

いつも参加している定期的なミーティングでも、途中からプログラマー色の濃い、ディープな内容になるときもあって（今日はこのままずっとこの話題だなー）と思ったら、途中で退出します。


そんなことを繰り返していると、ミーティングのはじめの頃の話題が、テスターも知りたいような内容（おそらくテスターにも聞いてほしい内容）になってくるのです。不思議でしょ。

そうそう、ミーティングがはじまる数時間前に「今日は◯◯な話題ですよ」と教えてもらえるときもあります。これは主催者が（もしかしたら、今日の話題はテスターが知りたいレベルの内容ではないかもしれない）と思っているのですね。「それじゃあ、今日は欠席しますね」となる場合もあるし、「少しだけ聞いて、どうするか決めますね」となる場合もあります。


これは、ミーティング中にテスターが質問したり、言葉を変えて聞き直したり、退出することで、

  • どのようなことにテスターは興味を持つのか、知りたいのか
  • そこからどんな風に、テストに展開しようとするのか
  • どのような話題になると（興味を持たなくなって）退出するのか

を、主催者（というか参加者全員）が、自然に学習していると思うのです。


だから（あれ、これはわたしの知りたいレベルの内容ではないかも）と思ったら、最後までじっと聞いてないで、そっと退出するのがいいと思います。


せっかくミーティングに参加させてもらっているのに、途中退出なんてできない（今後、呼んでもらえなくなっちゃうかも…）と、躊躇してしまう方もいるかもしれませんね。わたしもそう思う時期があったので、その気持ちはよく分かります。

有限の時間の中で、やることを選んでいかなきゃならない。全てをテストすることはできません。テストとはそういう「選択の技術」でもあるのは、みなさんご存知のことと思います。ミーティングに対しても同じですね。


今回なぜこんなことを書いたかと言うと、こちらのエントリーを読ませていただいたからでした。

 

いろいろと考えさせられることが多く、とても興味深い内容です。この中で「数多い開発ミーティングに品質メンバーが参加する余裕が全然なかった」と書かれています。詳しい状況は分からないのですが、わたしのミーティングに参加するときのスタンスと、そこから生まれたメリットを紹介し、何かの参考になればいいな、と思いました。