CAT GETTING OUT OF A BAG

What the tester is thinking.

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

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


その時に使ったスライドは公開できないのですが、こんな内容です。(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年くらい前なのだけど、今でもたまに取り出しては、読んでいる。
かなりボリュームがあるので「はじめからおわりまできっちり読む」というよりは、「気になるところから”軽い気持ちで”読みはじめる」のが、おすすめ。

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

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

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

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

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

お誕生日おめでとう!

チームでテストを共有した話(テストの地図)

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

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

チームでテストを共有した話
「テストの地図」はテストチャーター(のようなもの)を想像してください。
つくりはじめるタイミングは、ざっくりしたユーザー要件と、大雑把な仕様が出てきて「これから○○という機能を作りはじめるよー」というくらいのときです(プログラマーが実装してからだと遅い)。「テストの地図」は、国境と国名と主要な都市くらいしかない、白地図のようなものから、はじまります。

「こんなものを作るんだよね?」
「ここはこんなふるまいをするのかな?」
「仮にユーザーがこういう使い方をするとして、どうなるのがいいんだろう?」
「これまでのデータの持ち方を変えたりする?」
「前にこんなバグ、あったよね」
「もともとある○○機能には手を入れないの?」
「こんな問題が起きそう」
「わたしならこういうテストをしたくなるかも」

これからつくるモノのイメージを、チームのみんなでディスカッションしながら具体化していき、白地図にどんどん書き込んでいきます。当然(あれ、ここの仕様はどうなっているんだろう?)と分からないところも出てきます。それらは「不明点」として地図に残し、仕様が明らかになった時点で書き換えていきます。

このディスカッション自体が「テストの共有」です。わたしはテスターなので「テスト」を共有したつもりでいるのだけど、これから開発するモノに対してのすべて(要件、機能仕様、ふるまい、テスト、スケジュール、リソース、みんなの疑問 etc)を共有しているのかもしれません。こう書いてみると当たり前というか(なあんだ)という感じですが、こういったアナログで地味な活動がとても大事。他にも良いことがあるので、列挙しておきます。

完璧な仕様(書)がなくてもはじめられる
だから「ドキュメントがないからテストできない」「テストの計画、設計ができない」という事態に陥りません。わたしは自社製品の組み込みシステムを開発しているからできることなのかもしれないけど。でもそんな環境でも、開発チームとテストチームが分かれていたりすると、そういうことが容易に起きたりします。ドキュメントができてからだと遅いんですよ。完璧なソフトウェアがないように、完璧なドキュメントもないんです。(ああ、こんなことを書いたらまた叱られちゃうかも、、、)

暗黙の要件が見つかる
仕様書には明記されないけど一般的にはこう動くべきだよね、といったものを「暗黙の要件」と(わたしは)呼んでいます。この「暗黙の要件」について考えたり、実装そのものや、それに関するテストがポロッと抜けてしまうことがあるんですよね。例えば、マウスダウンのときに動作すべきなのか、それともマウスアップのときに動作すべきなのかとか、そういうの。

つくるモノの要件や仕様がガシッと決まってから考えはじめると、どうしてもそっち(決まっているもの)にみんなの目が行きがちなのかもしれない。

心配ごとが次の行動の入力になる
起きたら嫌なこと(心配ごと)は、それが「起きない」要件なり、テストに展開して、地図に追加していきます。テスターの心配ごとを聞いたプログラマーは、それが起きないように設計、実装していくだろうし、テスターはプログラマーの心配ごとが起きないことを試すために、どうテストしていくのかを考えたり、準備する。データの互換性が心配なら「今のバージョンでデータを取っておいてテストデータにしよう」「どのような種類のデータを取っておけばいいかな」のようにね。

おわりに
「テストの地図」を使い、チームのみんなでディスカッションをしながら「テストを共有」した話をしました。「テストの地図」はディスカッションするためのツールです。「テストの地図を作ること」を目的にしてしまうと、うまくいかなそうなので注意してくださいね。

そうそう「テストの地図」を使ってテストを共有したのは、わたしがいま所属している(ハズれ値かもしれない)チームではない!ので、導入しやすいプラクティスのひとつかもしれないな、と思っています。

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