CAT GETTING OUT OF A BAG

What the tester is thinking.

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

 

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

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

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

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

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

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


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

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

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

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

はじめのツイートに戻りますが、わたしがこれまでに遭遇した「実装がまったく思いつかないバグ」は、プログラマーにとっても厄介であることが多いように感じます。ですので「◯◯のように直したら(バグが)出なくなりました」と言われても「おお、よかったー」で終わりにせず、「なにがまずかったの？」と、チームの話題にしてあげるのがよいと思います。*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. 全部正しそう、または回答が１つに絞れない。
    この場合は、もう一度問題と選択肢を読み直し、言葉の意味をよく考えながら、どちらかと言うとおかしなところを探すのだけど、そうすると今度は全てが疑わしくなってしまい、結果詰む。
  3. なんだかよく分からなくて、どれも選べない。
    知らない用語が出てきたり、聞いたことはあるけど理解が曖昧だったりするときに、こうなることが多い。この場合はいくら考えても分からないので、とりあえず今回はこれで！みたいな気持ちでポチする。

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

 

今回の問題を見てみよう

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

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

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

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

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

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

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

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

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

①実務者の英知の結集

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

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

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

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

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

 

解説おしまい。

 

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

 

良い製品、良いチームを作るためのヒント

チーム開発の中でテスターとして日々奮闘(?!)しているわけですが、普段、わたしが『いいな！』と思っていることが、実は『良い製品、良いチームを作るためのヒント』になるのではないか？と思い、先月とある場所で発表しました。


その時に使ったスライドは公開できないのですが、こんな内容です。（PDFはこちら）

f:id:miwa719:20160716204656p:plain

 

『いいな！』があると、具体的にこんなことができる、こんな行動につながる、こんな気持ちになる、、、を、一方的にお話しました。

その『いいな！』はどこから生まれるのか、どのような状況なら『いいな！』は生まれやすいのか、チームのみんながどうふるまうと『いいな！』が形成されていくのか、、、のような 一歩踏み込んだディスカッション もしてみたいな。 

 

でね、いつものように時間が全然足りなかったので、いつかどこかでちゃんと最後まで話してみたいです。

 

あなたは完璧主義者ですか？

www.ryuzee.com

10. 自分のことを完璧主義者だと思うか？

 

わたしは完璧主義者ではないので、この質問に答えるとしたら「完璧主義者ではないけれど、開発現場でそこそこ使えます」をアピールするために、仕事を通して思うことをいろいろと説明しなくてはならないのだけど、そもそもまわりの人たちの目にわたし（と、わたしのテスト）はどう映っているのでしょうね。

プロの無職にインタビューしてみました。*1

 

みわ 「わたしは完璧主義者に見える？」

無職 「完璧かいいかげんのどちらか？」

みわ 「うーん（そういう極端なやつじゃないんだよな…）

無職 「完璧主義者ではないと思う」

みわ 「ほうほう（そうだよね。完璧主義者ではないよなあ…）

無職 「そしたら、１つの機能もおわらない」

みわ 「うん」

無職 「その先のトラブルはあるのだ！ほどほどに！」

みわ 「うん」

無職 「うまくできてると思うよ」

無職 「好い加減に」

 

いいかげんではなく、好い加減。

原文には”Great QA engineers are perfectionists. ”と書いてあるからね（うはー、どーしよう…）と思っていたのだけど、すこしだけホッとした。*2

 

明日もテストするよ！

 

*1:プロの無職 = @m_seki

*2:「好い加減」って英語でなんて言うの？

『テストエンジニアの面接の際にするとよい20の質問』以前の話

先週の金曜日にこんなことがあった。

いつものように、あるストーリーをcloseするためのテストをしていたのだけど、確認している最中に、テスト対象のプロセスが突然終了してしまった。もうこれだけでNGなんだけど、このシステムは特に複雑でね、これまでも不具合の本質的な原因が”スコープ外”と言うのかな、わたしたちが開発している部分の外側にあることが少なくない。
でもまあ、システムを使うお客様からしてみればそんなことはどうでもよくて、やりたいことができないのは、大問題ですよね。


現象が発生した直後、プログラマーMさんに見てもらい必要なログを採取してもらったのだけど、午後もやっぱりおかしい。午前中に問題が発生したときと見た目の現象はほぼ同じなのだけど、プロセスは残っている。かと思えば、うまく動くときもあってね。これは厄介だな…。

周りを見渡したらMさんはいなくて、プログラマーSさんに午前中の状況も話して見てもらった。SさんもMさん同様にログを採取してくれたのだけど、二人とも「異常終了」というかなりシリアスな場面なのに、盛り上がっていない。（なんでなんだよー）


はじめにも書いたように、不具合の本質的な原因が”スコープ外”ということもあり得るので、まずはログを解析してから…ということだったのだと思います。*1

それにね、MさんもSさんも、いま別のストーリーを絶賛開発中なのですな。どの機能のどこの部分を作っているかもわたしは知ってる。横並びの席に座って、みんなで協力しあっていい感じで作っているんですよ。この光景はいつ見ても気持ちが良い。


そこへだ、わたしが不定期に「なんかおかしい」て割り込んでくるわけでしょう。だからわたしの思い通りにタスクスイッチなんかされないのも分かる。分かるよ。分かるんだけど、でもなー、今回のコレはなんかやっぱり変なんだよなー。

いますぐ見てもらわないとダメなような気がしてならないので、仕方がないからプロの無職に現象を説明しに行きましたよ。*2


そこからは早かったね。

プロの無職が、エースプログラマーYさんとスコープ外のWさんを連れてきて（実際は連れてきてないんだって。自然とそうなる系のやつかな）、Mさん、Sさんを含む５名のエンジニア＋わたしでモニターを囲み、現象を見ながらデバッグしました。

その結果、問題はスコープ内で起きていることが判明して、プロセスが落ちる原因であろう関数名まで特定できたみたい。よかった、よかった。

 

www.ryuzee.com


@ryuzee さんが翻訳してくださった『テストエンジニアの面接の際にするとよい20の質問』を、この週末に読みました。

 

４. あなたが出した結果に納得しない開発者に対して対抗することを厭わないか？

 

ああ、今回の件は「開発者が納得しない」のではなく「開発者の反応にわたしが納得しない」というケースじゃん。うわー、もうなんていうかテスターとしてこれでいいのでしょうか…。わかんなくなっちゃった。*3


明日もテストするよ！

 

*1:スコープ外だとしても異常終了ではなく、異常を検知した上で正常に終了してほしいけれども

*2:プロの無職 = @m_seki

*3:開発者のひとりだからいいか！