【翻訳】テストにおいて避けるべき、6つのペルソナ - ソフトウェアの品質を学びまくる

　Kristin Jackvonyさんのブログ「Think Like a Tester」に掲載されたポスト『Six Testing Personas to Avoid』を、許可を得て翻訳してみました。

thethinkingtester.blogspot.com

　「ダメエンジニアの類型」みたいな記事って、バーナム効果的に「どれも自分に当てはまるかも・・・」となって面白いので、反省のために読んでしまいますね。

テストにおいて避けるべき、6つのペルソナ (翻訳)

　エンドユーザ向けのソフトウェアを作っている会社で働いていれば、「ユーザペルソナ」について聞いたことがあるでしょう。ユーザペルソナとは、アプリケーションのエンドユーザの一つの側面を表現したものです。
　たとえば、自宅を改善するための製品のウェブサイトを作っている会社で働いているとしましょう。この場合、最初の家を購入したてで、自宅のこまごまとした点を直す経験はあまりない、「新居を買ったばかりのNick」が、ユーザペルソナの一つとなりえます。他には、家を自分でなんでも直せる経験をもつ、「DIYのDora」もペルソナになるかもしれません。

　わたしは最近、テストにおいてもペルソナというものがあるのではないか、と思いつきました。ただこれらのペルソナは、ユーザペルソナとは違って、わたしたちが避けるべきものです！当てはまるペルソナがないか、読んでみてください。

1. テスト手順派のTed (Test Script Ted)

　Tedはテストを手動で行い、終わったときにチェックマークを付けることが大好きです。テストが通ったことを見ると、満たされた気持ちになります。
　アプリケーションがどう動くかを理解しているかどうかについては特に気にしていません。言われたことをすることで満足してしまっています。アプリケーションがどう動くかを理解していないので、時に重大なバグを見逃します。おかしな動きを見かけても、テスト計画の中で扱われていないので、問題なしとしてしまうのです。彼の仕事はテストすることであり、物事を理解することではない、というわけです。

2. 自動化のAnnie (Automation Annie)

　Annieは自分のことを、自動化エンジニアを見なしてます。手動テストは大きな時間の無駄であり、もっと難しいこと―――自動テストの作成と保守にのめり込みたいと考えています。
　新しい機能が作られても、探索的テストに時間を割いたりはまったくしません。すぐにコーディングを初めて、自分の素晴らしい自動化によってどんなバグでも見つかると考えています。

TedとAnnieの共通点

　TedとAnnieは、違う理由で同じ失敗をしています。二人は、アプリケーションがどう動くかを真に理解するために時間を費やしていません。二人とも、理解不足からバグを見逃しているのです。Tedはフィーチャを動かすコードを理解せず、Annieはアプリケーションのユースケースを理解していません。

TedやAnnieにならないために・・・

　しっかりとしたテスターたるもの、フィーチャがどのように動くかを理解するために時間を使うことが重要です。手で試して、その制限を探索してみましょう。他にテストしようがないかを探るために、コードを覗いてみましょう。理解できない部分があれば、質問を投げてみましょう。

3. プロセス屋のPatty (Process Patty)

　Pattyは品質に情熱を持っています。物事が正しく動いていることを好みます。ですがそれ以上に、プロセスと基準があることを愛しているのです！
　テスト計画とメトリクスを持ち込み、自分のチームは一語一句それに従うと思っています。探索的テストの前にリグレッションテストが完了していなければならず、そのリグレッションテストは大量にあります。問題は、隔週でリリースするにあたり、探索的テストを行う時間がないということです。プロダクトをテストする新しいやり方はないか、見逃していることはないかと立ち止まって考える余裕もありません。リグレッションテストがすべて終わっていることが必要なのです。

4. 深掘りしすぎのRay (Rabbit Hole Ray)

　Rayもまた、品質に対して熱い思いをもっていて、バグを見逃したくないと思っています。ですので、IE10でアプリケーションを動かしてみて何かおかしな点が見つかれば、何が悪いのかを解明しようと心に決めます。調査に何日もかけ、ログを見て、別の構成のシナリオでも再現しないか試します。フィーチャがリリースされようというときに、標準のリグレッションテストを終わらせずに放置していたとしても、関わりたがりません。IE10を使っているのが顧客のわずか1%だということなど、気にもしません。謎を解こうとするのです！

PattyとRayの共通点

　PattyとRayはともに、時間を無駄にしています。第一の目的、つまり「最低限の欠陥で、良いソフトウェアを、期日通りにリリースする」こと以外にフォーカスしているのです。
　Pattyはプロセスに捕らわれ過ぎて、新しいバグを見つけうる探索的テストの重要さをわかっていません。Rayは自分が探索している難しいバグに取りつかれ過ぎて、もっと多くのユーザに影響を与える重要なテストを無視してしまっています。

PattyやRayにならないために・・・

　新しいフィーチャをテストしたり、既存のフィーチャのリグレッションテストを行う場合、もっとも大きなインパクトを与えるテストが何かを考え、それに応じてテストを計画することが重要です。プロセスに捕らわれ過ぎないように気を付けましょう。また調査中の捉えづらいバグがエンドユーザに大きな影響を与えそうにないのであれば、放っておきましょう。

5. 仕事の安定が一番のJim (Job Security Jim)

　Jimは今のポジションで何年も働いており、自分たちのアプリケーションのことを知り尽くしています。もっとも古いフィーチャがどのように振る舞うかといったどんな疑問に対しても、頼りになります。会社が自分を手放すことはできないとわかっています。わかり過ぎていると言えるでしょう。
　ですので、新しいスキルを学ぶ理由はあるとは思っていません。今のところ、彼の知識で十分やっていけるのです。仕事が終わった後に、最新のプログラミング言語やテストツールについて勉強したりすることなど、時間の無駄にしか思えないでしょう。

6. カンファレンス好きのConnie (Conference Connie)

　Connieは技術が大好き！最新のテスト技術や開発のトレンドについて話を聞くことが好きです。ウェビナーに参加登録し、カンファレンスに行き、ブログ記事を読み、オンラインコースを受講します。あらゆることについて、ちょっとだけ知っているのです！
　ですが新しく学んだことを実際に導入したことはまったくありません。カンファレンスやウェビナーに行くのに忙しくて、通常のテストのタスクをこなす時間しかないのです。それに加えて何かに取り組むというのは大きな仕事。他の人がどのように取り組んでいるかを見るだけの方が、楽です。

JimとConnieの共通点

　JimとConnieは一見、まったくの逆に見えますね。Jimは新しいことを何も学びたくはないし、Connieは新しいことなら何でも学びたい。ですが抱えている問題は同じです。テスターとして成長していないのです。
　Jimはすでに知っていることだけで満足していて、それ以上何かを学ぶ理由が見つけられません。ですがある日、会社がソフトウェアの書き直しを決め、突然新しいスキルが必要になったら・・・・彼はショックを受けることになるでしょう。
　Connieもたくさんの良いアイデアを持っているのですが、試してみないことには何の意味もありません。知識を実業務で使おうとしていないのですから、会社に何の利益ももたらしていないのです。

JimやConnieにならないために・・・

　新しい言語、ツール、技術について学ぶことで、テストの技術を維持することが重要です。世の中のすべてを学ぶ必要はありません。今の会社に一番メリットがあると思えるものをいくつか見繕ったうえで勉強し、一つ二つの領域でそれを実践してみましょう。あなたが導入したソリューションに、チームメイトは感謝してくれるでしょう。次のポジションに向けて、あなたの市場価値を向上させることにもなります。

ペルソナではなく、素晴らしいテスターでありましょう！

　わたしたちは誰でも、時にはこういったペルソナになってしまいます。ですがそれを意識していれば、自動化のAnnieや深掘りしすぎのRayや、他のどれかに陥りそうになっても気づくことができます。
　素晴らしいテスターは誰よりもアプリケーションについて学び、どんなテストをいつ行うかを正しく決め、テストをより良いものにし続けるために、自分のスキルをアップデートを継続するのです。