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

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

 

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

 

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

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

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

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

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

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


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

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

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

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

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

 

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

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


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

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


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

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


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

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

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


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


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

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


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

 

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

 

テスターは「良いこと」も伝えたほうがいいと思うのだ

一般的に、おかしなところを探すのがテスターのお仕事なのだけど、おかしくないところ(良いこと)も探すといい。積極的にそれを探す、というよりは、普段からそういうことも感じられるように、あなたの持ってるアンテナを1つ増やし、周波数を調整しておくといい。

もし、そのアンテナに「良いこと」が引っかかったら、あなたの心の中にしまっておくのではなく、インシデントを報告するときと同じように、チームの誰かに伝えるといい。

 

ストーリー220をテストする

用意されているテストケースは全てPassしたので、少し(かなり)意地悪な状況を作りました。わたしの頭の中には、シーケンス図のようなもの(複数のスレッドがこう動いているのかもしれない…という予想)があったのです。あの処理の隙間に◯◯をしたら、何か嫌なことが起きるかもしれない。だから、その隙間を狙うようなテストをしました。

結果は…というと、隙間を狙えなかった。処理が速すぎて、わたしの思い描いていたテストができなかったのです。

 

うはー、これはすごい!

 

ストーリー220を担当したプログラマーTさんを探したら、斜め後ろにいたので、話しかける。

miwa「いまストーリー220を確認しているんですけどね(画面を見せながら)ほら、こんな状況で◯◯しようとしたけど、処理が速すぎて出来ないの」
miwa「すばらしいです!」


Tさん、わたしの話をニコニコしながら聞いていました。「たまたまですよ」と言うので、そのあと何度かトライしてみたけど、◯◯は一度も出来ませんでした。

 

夕方から土砂降りの雨の日のテスト

この日はシミュレータではなく、本物の装置を使ってテストしていました。(ここから先は、本物の飛行機を使ってテストしているイメージで、お読みください。)

その時、雷による瞬電が起きたんですよ。格納庫でメンテナンスしている時ではなく、お空を飛んでる最中に!*1

 

飛行中に瞬電が起きるとどうなるのか。実際に見るのは初めてでした。

システムダウンはしなかったけど、目の前で起きているそのふるまいが、期待するものであるのか。よく分からなかったので、エンジニアHさんに連絡してすぐに来てもらい、瞬電が起きてからの状況を話しました。Hさんはわたしの話を聞きながら、ログファイルをスクロールしながら確認している。


結果は…というと、やるべき処理がきちんと動いていました。Hさんから説明を受けながら「ああ、よかったー」「さすがです!」と、自然に口から出てしまいました。


翌日のテストの朝会で、キャプチャーした画面を見せながら、みんなに話しました。

miwa「昨日、ちょうど飛行中に瞬電が起きたんですよ!ええ、あの時です」
miwa「結果から言うと、ちゃんと動いてました。よかったー」
miwa「あ、瞬電だ!と思った直後、すぐに画面にはこんなメッセージが出て、次にこうなります。これは内部的にはXXというシグナルを感知して…云々」

(かなり熱く語っていたのではなかろうか)

 

そうなるように設計して、そうなるように実装して、そうなることを確認してるのだから、そう動くのは当たり前なのかもしれないけど、でもやっぱり「すごいなー」と思うのです。作ったものを信じてないとか、そう言うのじゃないんですよ。うまく言えないけど。

 

さいごに

このテストの朝会は、テスターの他にも、数人の(わりと主要な)エンジニアが参加しています。ストーリー220のプログラマーTさんも、瞬電のエンジニアHさんもそうだけど、わたしが伝えたことを聞いてどう思ったのかは、実際のところ分かりません。

でもね、「良いこと」を伝えると、みんな決まっていい顔になるのです。それでまた、わたしは嬉しくなる。だから、これからも「良いこと」を感知したら、まわりのみんなに伝えます。

 

*1:那須地方では、瞬間停電を”瞬電”という人が多い