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


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

 

思考パターンについて

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

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

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

 

今回の問題を見てみよう

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

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

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

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

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

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

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

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

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

①実務者の英知の結集

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

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

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

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

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

 

解説おしまい。

 

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

 

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

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


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

f:id:miwa719:20160716204656p:plain

 

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

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

 

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

 

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

www.ryuzee.com

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

 

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

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

 

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

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

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

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

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

無職 「そしたら、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さんを含む5名のエンジニア+わたしでモニターを囲み、現象を見ながらデバッグしました。

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

 

www.ryuzee.com


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

 

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

 

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


明日もテストするよ!

 

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

*2:プロの無職 = @m_seki

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

テスターが開発現場にいることのメリット

MTBF平均故障間隔)とかMTTR平均修理時間)とか、世の中には品質をあらわすための指標が数多く存在するようですが「バグを発見してからプログラマーに伝わるまでの時間」という指標は、あるのかな?

わたしたちのチームは、これが圧倒的に早いです。

といっても、どこかと比較したことはないのだけど、どれくらい圧倒的に早いのか、最近のツイートに補足しながら説明します。

テスターが開発現場にいるときの場合


テストしていると(はて、これはこういう仕様なのか、それともバグなのか?)と思うことがあります。その点、クラッシュは分かりやすいですよね。

一瞬で恋におちるような経験はないのだけど、クラッシュも何の前触れもなく突然起きることが多いので、まずは心を落ちつかせて、画面全体をスクリーンキャプチャします。

その後、テスターは担当のプログラマーに連絡し、クラッシュしているナマの状態を見てもらいながら、それまでにやっていた操作や、クラッシュする直前の状況を話します。プログラマーはエラーログや解析に必要なデータを採取していきます。テスターがバグを発見してからここまで5分くらいです。

それからテスターは、システムを再起動する間にチケットを発行します。このときはあるストーリーについてテストしていたので、既存のチケットに追記しました。(記載時間1分)

そして休憩したあと、別のテストに取り掛かります。

 


このときはですね、プロの無職が騒いだので、周りで作業していたプログラマーがわさわさと集まってきました。(担当のプログラマーは不在でした)
みんなで(メモリーリークする処理は)どこが考えられる?のような話をしていて、そのうちにプログラマー(←もうひとりのエース級)がコードを見ながら、解放もれの箇所とリークするであろうサイズを、実際の増加量と比較して、特定。

プロの無職が騒ぐ1分くらい前に(あれ?メモリー使用量がどんどん増えていくぞ)と思っていたので、テスターがバグを発見してから、プログラマーが原因を特定するまで5分くらいです。チケットには、それまでメモしていた、機能を実行する前と実行後のメモリー使用量(と増加量)を3回分、記録しました。(記載時間2分)

 

テスターが開発現場にいないときの場合

「バグを発見してからプログラマーに伝わるまでの時間」は、比較にならないので省略しますが、もしわたし(テスター)が開発現場から離れた場所(組織やプロセス的にという意味で)にいたら、どのようなことをするのか想像してみます。過去にそういうチームに所属していたこともあるので、かなりいい線いってると思う。

はじめのケースでは、クラッシュした直後、プログラマーが解析するのに必要なエラーログなどを取り、その他に参考になりそうな情報(もし何かを登録するような機能だった場合は、その登録処理自体はうまくいってるのか/いってないのか、など)を確認します。なお、わたしが思う「参考になりそうな情報」なので、ハズしている場合もあります。

その後、システムを再起動し、現象が再現するかどうか、もう一度同じような操作をしてみるはずです。(テスターとしては「確実に再現する手順」をプログラマーにお届けしたい)
で、すぐに再現すればよいのですが、単純な操作手順ではなく、そのときのシステムの状態や状況に起因していたりすると、再現しないのですな。わたしは非再現のバグに関しては(どちらかというと)執着するほうなので、再現するまでがんばっちゃう。プログラマーがエラーログを見たら、すぐにわかるかもしれないのに、ね。

次のメモリーリークのケースは、このときは3回でやめてますけど、念のため(?)10回くらい実施してメモリー使用量の「ばらつき」を見たりするかもしれないですね。増加量の平均値とか出したりしてね。パッと見てわかるようにグラフとか書いちゃうかも。それから、与えるデータの大きさによってリークするサイズが変わるのかもしれないとか、いくつか気になることを試すと思います。すべては「バグの解析に役立つかもしれない」と思ってやるのですが、ハズしていることもあるよね。

そうやって試すことが増えていくと時間もかかりますし、報告する内容もそれなりに増えていくので、チケットを書く時間も当然かかります。


さいごに

特にまとめませんが、テスターが開発現場にいないことのデメリットというよりは「もしテスターが開発現場にいると、こんなメリットがあるのよ!」ということを、少しでも感じてもらえたらいいな、と思っています。

 

チームでテストを共有した話(ペアテスト)

探索的テストを含む「テスト」をチームで共有したときに、やってみたことを紹介します。キーワードはこの4つ。

・テストの地図
・ペアテスト(今回はこれ!)
・テストの渡航記録
・朝会とテストの夕会


ペアテストはその名の通り2名(以上)で行うテストですが、テスターだけのものではありません。一般にはテスター×テスターの組み合わせが多いのかもしれませんが、わたしは同僚のプログラマーと一緒にテストすることもあるし、開発環境の入っていないテストPCの前に2、3名のプログラマーが集まり、みんなでテストしているのも、よく見る風景です。


ペアテストはもうそれ自体が(実施者間での)テストの共有であり、ペアテストの実施内容(どのようなテストをして、どうだったのか)は、ペアテスト直後に一番知りたがっている人たちに話しますし、朝会やテストの夕会、また日常の会話の中でも話題にしています。

ですので、今回はテストの共有というよりは「ペアテストそのもの」について書いてみたいと思います。


どんなときにペアテストをするのか
わたしがこれまでペアテストしたのは、こんなときです。


ヤバいやつがコミットされたとき
「ヤバい」という言葉は、あまり使いたくないのだけど、他に言いようがない…というか、この場合はぴったりハマるので使います。ヤバいやつですよ、ヤバいやつ。プロセスやスレッドが何本も走っていて、複数の装置が絡んでいて、これまでも似たような機能で多くの不具合が見つかっていて、、、もうみんなが「これはヤバい!」と思ってるやつです。

そんなヤバいやつがコミットされたと知った朝会のあと、同僚(テスター)に目で合図します。

「今日やろう!」
「何時からやる?」

ペアテストはお互いに試してみたいことを、順番にやっていくことが多いです。(わたしがそうであるように同僚もまた、朝会などに参加しながら、試してみたいことを日々メモしているようです。)

わたしたちのテスト対象は、いくつかの装置が絡んでいて、注目するのは目の前のディスプレイモニターだけではないことが多いです。ペアテスト中は二人とも、自分が何をどう操作しているのか、装置にどのようなパラメータを与え、何を観察しているのか、いま何がどうなっているのか、それは正しい動きなのか、そうではないのか、お互いの言葉を聞き、相づちを打ちながら、ひとつのテストが終わるまで、ずっとしゃべり続けています。ふたりで同じモニターを見ていても「これはこうだから大丈夫」と、いちいち指を差し、声に出します。

そして、その結果(手応え)によって、確認する内容や順番を、その都度相談しながら変えていきます。

同僚とペアテストをすると、かなり高い確率でバグが見つかるので(ヤバいやつなので予想通りだから驚かない)「早めに見つけられて良かったねー」とホッとするのですが、他にも良いことがあります。

ペアテストをすると、同僚が何を心配していて、それをどのような手順で確認しようとしているのか、どこを気にして、何に注目しているのか、テストの息づかい、テストに関するノウハウ、テクニックのようなものが、それはもう手に取るように分かります。テストを共有している感覚は、まさにここにあり、とても勉強になります。(同僚もまたわたしから何かを得ていると良いのですが、どうでしょうか。)


テスト対象を知らないとき
現在のチームに異動したての頃は(ある程度のドメイン知識はあったものの)テスト対象のシステム、ソフトウェアについては、ほぼ知らない状態でした。

毎日1時間、プログラマーのYさんに「これはどのような機能なのか」を、レクチャーしてもらいながら一緒にテストしました。毎日テーマを変え、2か月くらい付き合ってもらいました。この間に、すこしずつテスト対象を理解していき、最低限のテストができるくらいにはなったと思います。ありがたかったなー。


いじめ方の程度を伝えるとき
例えば、テストケースに「◯◯ボタンを押してモードを変えた直後に◯◯スイッチを素早く押す」と書いてあったとします。おそらくテストする人によって、操作する速度が変わってきますよね。

このテストは「◯◯ボタンを押してモードを変えると、接続されている別の装置に命令が飛んでいき、その装置の状態も変わるのだけど、その状態が変わりきる途中(隙間)に、別のルートから◯◯スイッチが押されたよ、という信号が送られても、状態はまだ変わってないので、スイッチの信号は無視されること」を確認したい。


だからここでは「モードを変えたら間髪入れずに◯◯スイッチをものすごい速さで押す」という操作を求めています。単に「早い」くらいの操作では、狙いたいテストにならないのですね。

「間髪入れずに」「ものすごい速さで押す」のは、どういう操作なのかを実演し、表には見えないけどその裏では、どんなシーケンスが流れていて、何を心配しているのかを話しながら、新人テスターと一緒にテストしました。

これは1つの例ですけど、このシステムではどれくらいシビアないじめ方をテストに要求しているのか、が感覚的に伝わったようで、その後、その新人テスターはかなりひどい操作をしてくれるようになりました。(このときは、テストの共有というよりは「伝承」のような気持ちになりました。)


一人では確認できないとき
例えば、エレベーターの中と外でそれぞれのボタンを同時に押すようなテストをする場合ですが、これはペアテストというよりは、テストする上での準備に近いですね。


おわりに
わたしが経験した「ペアテスト」について、いくつか紹介しました。
若干大げさなものを取り上げて書いてしまった感もあるのですが、一番多いのは、いつものテストの最中に「これ一緒に見てもらえる?」「これおかしいと思うんだけど、どう思う?」と、同僚のテスター(たいてい隣にいます)に声をかけ、5~10分くらいで行う、とてもカジュアルなペアテストです。


「ペアテスト」について興味のある方は @miwa719 にメンションしてください。4月23日(土)に開催するとちぎテストの会議に参加していただけると、もっと丁寧にお話しできます!

 

『基本から学ぶソフトウェアテスト』の読み方

 

基本から学ぶソフトウェアテスト

基本から学ぶソフトウェアテスト

 

 

この本に出逢ったのは10年くらい前なのだけど、今でもたまに取り出しては、読んでいる。
かなりボリュームがあるので「はじめからおわりまできっちり読む」というよりは、「気になるところから”軽い気持ちで”読みはじめる」のが、おすすめ。

読者の想像力(妄想力)を駆り立てるような文章になっていて(←わたしが、そう感じるだけかもしれないけど)読むたびに発見がある。きっと、そのときの自分が置かれている環境や状況、気分によっても感じ方が変わるのだろうな。

興味がなくパラパラと読み飛ばしていたページも(どんなことが書かれているのかな?)と、あるときフワッと好奇心がわいてきて、その結果、すっと読めてしまうのが、この本のすごいところ。(ただし、全部読むのに数年かかっています…)

巻末の付録「よくあるソフトウェア不具合」は「付録」とは思えないくらい読み応えがある。素晴らしい。(前回のエントリーに出てくる「テストの地図」のある部分の元ネタは、これを参考に再構築した)

現在は「ある特定の項目について読む」よりも、「ランダムに開いたところを読む」ことが多くなったかな。読んでいると不思議と気持ちが落ち着く、聖書みたいな本。持ち歩くには重すぎるのが難点。

わたしと同じように毎日毎日テストしていて、遠く離れていても、何か通じるものを感じる某テスターのウィッシュリストに、この本が入っているのを見つけて、ぜひ読んでもらいたくて贈りました。

お誕生日おめでとう!