CAT GETTING OUT OF A BAG

What the tester is thinking.

自然とそうなる仕組みづくり(テスト実施者の名前を記録しないとどうなるか)

先日の航空機事故を受けて書籍『失敗の科学』を読んでいます。第1章 失敗のマネジメント(「ミスの報告」を処罰しない)に、次のようなことが書かれていました。

学習の原動力になるのは事故だけではない。「小さなミス」も同様だ。パイロットはニアミスを起こすと報告書を提出するが、10日以内に提出すれば処罰されない決まりになっている。また現在航空機の多くには、設定した高度などを逸脱すると自動的にエラーレポートを送信するデータシステムが装備されている。データからは、操縦士が特定されない仕組みだ。

この「操縦士が特定されない仕組み」は、忍者式テスト*1の「テスト履歴」を思い起こさせました。履歴として記録するのはテストした日付と結果(OK、NG)のみ。誰がテストしたかは記録しません。といっても、NGの場合はその詳細が報告されるので誰がテストしたかは自ずとわかります。OKの場合はわかりません。この記事の最後に忍者式テストの履歴(例)を載せましたのでご覧ください。*2

咳チームにJoinする前は、テストを実施した人の名前を記録するのは普通というか当たり前でしたので「あとから誰がテストしたのかトレースできないの?」とびっくりしました。「省力化なのかな? 咳チームのチケットシステム*3はログイン操作もないし、いちいち名前をタイプするのは面倒だからやめたのかも」くらいの浅い認識だったと思います。

テスト実施者の名前を記録しない

たったこれだけのことが、テスト実施にたいする心理的負担をなくす効果とテスト本来の目的に意識を向けさせる力がある、と知るのは、咳チームにJoinしてから数か月後です。

テスト実施にたいする心理的負担がなくなる

咳チームはひとり毎日1時間、忍者式テスト専用のアルゴリズムによって抽出したチケットに書かれているテストケース「本日のおすすめテスト」を元にテストします。前述したように、テストした人の名前を記録しないので、誰がどのチケットのテストを確認したのかはわかりません。今日、Aさんは6チケット分テストしたかもしれないし、Bさんは1チケット分しかテストできなかったとしても、誰もそれを知ることはできません。

わたしたちのラボ(仕事場)にはテスト用のPCがずらりと並んでいて、テストの時間割にあわせてプログラマーがつぎつぎと現れます。だから「テストしているな」はわかります。でも、数を数えるような進捗管理はいっさいしないのです*4

わたしは数を数えるような進捗管理される• • •側だったことがあるのでわかるのですが、テストが思うように進まないと焦るんですよ。心理的なプレッシャーはテストにも影響します。テストに集中したいのに残りの時間が気になってしまい、本来その人が持つパフォーマンスが出せない、なんてことも少なくないのではないでしょうか。なお、数を数える進捗管理が悪いという話ではありませんので、お間違えのないよう。

テスト実施者の名前を記録しない、から浮かびあがるメッセージは「進捗はいっさい管理しません。1時間でできるテストを自分の思うようにやってください」であり、これはまた「テストをサボる人はいない(みんながみんなを信頼している)」という暗黙の了解も含まれていると感じます。

テスト本来の目的に意識が向くようになる

テスト実施にたいする心理的負担がなくなると、テスト本来の目的に意識が向くようになります。テスト実施者の名前を記録しない仕組みはここにつながるのか!と理解したときは、感動して心が震えてしまいました。

テストの目的は所属する組織やチームごとに、また同じチームでもテストレベルやテストタイプによって異なります。忍者式テストの目的は以下です。

私たちのテストは、ストーリーに書かれているテーマを起点として「本当によいシステムになっているのか」について、本物のシステムを使って確かめる過程である。操作手順のような基本シーケンスだけでなく、チケットに書 かれた開発日記(要求の背景、開発の経緯など)を読み直し、実際に今日のシステムで操作して、問題がないか、さらには、本当によいものになっているのかを実験する。単に不具合を見つけたいだけでなく、使いづらさや誤解をまねく仕様や手触りの良し悪しなども含めた理想との違いを知りたいのである。その理想さえも市場や環境の変化に応じて変わっていく可能性がある。

ストーリーに書いてあるテストを実施して分かるのは“テストケースに書かれている前提や操作においてうまく動くか、動かないかである。変更による意図しない副作用を検出するためのリグレッションテストとしての効果はある。しかし、私たちが手に入れたい問題を発見するには、このテストケースだけでは足りない。そのために、書かれているテストケースを出発点として、さらに新しいテストケースを考えながらテストしなくてはならない。

 

「テストからはじめよ」〜忍者式テスト20年の実践から〜 一部抜粋

わたしたちは未知の問題(まだ見つかっていない問題)を見つけて直すためにテストします。だからチケットには書かれていない未知のテストケースを自分の頭で創造しながらテストすることが求められます。進捗を管理しないということは「数をこなすことが目的ではないですよ」という強烈なメッセージを与えます。1時間でたくさんのテストをこなすよりも1つの未知の問題を見つけるほうが喜ばれる。自分にしかわからないような違和感を面白がってもらえる。メンバーひとりひとりがこれを体感するので、自然とそうなる(目的にそった行動をしてしまう)のは当然といえば当然ですね。

忍者式テストの履歴(あるストーリーの例)

 

*1:忍者式テストについては一つ前の記事をお読みください

*2:テスト実施記録(テストレポート)のフォーマットや扱いは、所属する組織やチームの開発プロセス、テスト対象の特性、テストレベル、テストタイプ等で異なります

*3:@m_seki によって20世紀に開発された世界一長生きなチケットシステム

*4:日付ごとにテストしたチケット数やOK、NGの数を数えることは可能ですが、その手の集計もしません