CAT GETTING OUT OF A BAG

What the tester is thinking.

テスト脳を鍛える

ある処理の応答時間を計測し、何秒以内だったら 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:那須地方では、瞬間停電を”瞬電”という人が多い

秋山さんの【試験に出ないJSTQB】問題72について


うっかり問題72の自分の回答を晒した上に、その回答が間違ってることも分かっちゃって、解説する羽目になったぞ!
正解はまだ発表されてないのですが、秋山さんの解説を読んでしまったら、きっと(うんうん、そうだよね)て思ってしまうので、今のうちにわたしなりの解説をまとめておきます。

 

思考パターンについて

本題に入る前に、この【試験に出ない】問題を解くとき(選択肢を選ぶとき)の思考パターンですが、大体こんな感じです。みなさんはどうですか?

  1. これが正しい(または間違っている)と素直に選べる
  2. 全部正しそう、または回答が1つに絞れない。
    この場合は、もう一度問題と選択肢を読み直し、言葉の意味をよく考えながら、どちらかと言うとおかしなところを探すのだけど、そうすると今度は全てが疑わしくなってしまい、結果詰む。
  3. なんだかよく分からなくて、どれも選べない。
    知らない用語が出てきたり、聞いたことはあるけど理解が曖昧だったりするときに、こうなることが多い。この場合はいくら考えても分からないので、とりあえず今回はこれで!みたいな気持ちでポチする。

    なお、これまでの正解番号の比率は下図のような感じなので、気軽に選べます。

 

今回の問題を見てみよう

あれ、もしかしてブログにアンケートを貼ると自分で何度でも投票できたりするのかな?

今回の思考パターンは「2」でした。(そういえば、正しいものを1つ選ぶよりは、今回のように【でないもの】【間違っているもの】を1つ選ぶときのほうが悩むなー)

パッと見、全部正しそうに思えたので読み直してみました。はじめに引っかかったのはこれです。

④開発成果物のサイズとの相関性がよい

この「開発成果物のサイズ」は何を指しているのかな?

もしLOCやFPの数のことを指しているのだとしたら、それは見積りとは相関性がないときもある。いくらその数(サイズ)が小さくても、設計が複雑だったり、これまでの開発でも不具合が多く検出されているところだったり、プロダクトリスクがあるようなところは、みんなとても気を遣って丁寧に開発しますよね。(実はつい最近、数値に惑わされて失敗したので「数値で何かを判断すること」に関して、いつもより敏感になっている)

ほうほう、数えられるものか、、、。
この時点で④が「優れた見積り」から外れるかもね、と思ったのですが、その直後に、わたしの考えていることを見透かしたようなツイートが届きました。

そうですか。数えられないものも含まれる…となると、④は特徴のひとつ、として考えてもいいような気がします。

ここから先は、ひとつひとつ思ったことを書いていきます。

①実務者の英知の結集

やはり実際に開発に携わっている人(実務者)は、それまでの経験もありますし、現在のプロダクトやプロジェクトの状態や状況がよく分かっています。チームのメンバーひとりひとりの得意、不得意のような力量的なこと、ちょっと先の、でもそれほど遠くない未来に関係してくるであろう開発、のことまで気にしています。そんな人たちが集まり、それぞれが知恵を出して作られた見積りは(そうではない人たちが作ったそれよりも)優れたものになるだろうと思います。

②コスト、リソース、人等についての詳細

わたしが選んだ回答はこれでした。選んだ理由は「詳細」という言葉が気に入らなかったからです。これは③にも少し関係してくるのですけど、見積りをするのに、あまりにも詳細なことまで気にするのはどうなのか。これは自分自身の過去の反省でもあります。あるテストチームのテスト計画を立てることになりまして、その見積りの「根拠」を示すために、詳細にすればするほど、見積ること自体に時間がかかってしまうんですね。しかも、見積りどおりに進まないんですよ。活動中に何度も見積りし直したりして(一体、何のための見積りなのだろう)と思いました。
今思うと「優れた見積り」とか「正しい見積り」に囚われすぎていたのかもしれませんね。見積りは見積りなので、当たり、外れではない。活動が止まってしまうのでは困りますが、見積りは「ほどほどでよい」と思っています。(だからと言って、諦めの気持ちで「外れてもいい」とは思ってないですし、所詮見積りなんだからテキトーで構わない、と言うことではありません)

③活動に対し、可能性の高い見積りを算出する

これは裏返しにして考えました。今あるリソース(人、技術、資金、設備など)や、スケジュールに合わない「実現する可能性の低い見積り」を出されても困ります。ですので反対に、実現する可能性の高いものは、見積りとしては優れている、と思いました。でも、それを算出するために②で述べたようなことに陥らないような工夫、が必要だと思っています。

 

解説おしまい。

 

いろいろ書きましたが、わたしが選んだ②は不正解なので、正解はどれなのかと、秋山さんの解説が楽しみです。