概要
How to Think Like a Testerという記事の翻訳です。
Google翻訳 + DeepL + 意訳の闇鍋翻訳です。
内容の大筋さえあってればヨシ！の翻訳なので、正確さについてはご了承ください。
社内勉強会で使用したものを公開します。
はじめに
テストをする能力は生まれつきのものではなく、才能でもないのです。我々は生まれながらにしてテスターではないですからね。
テストは誰もが虎の巻を使って習得できるような技でもないし、一連の作業手順を記憶できるようなものでもないです。
また、テストはスルメな分野であり、うまくやるには実践と経験が必要です。また、「できた人」がうまくやれることでもあります。そういった人たちは「テスターのように考える」、つまり「テスター精神」を持っているのです。
ではその心得とは？そしてどのようにそれを育み、成長させることができるでしょうか？
私は5つの心得を見つけました。その心得があるかないかが、玄人と素人の違いです。しかも、理解するは易し、行うは難しといったものです。でも、時間と労力さえ費やせば誰でも習得できるものです。それをここに記そうと思います。
注：これ以降、私の記事の中で「テスター」という単語を使用する場合は、テストを行う人全般を示すことにしたいと思います（個人的にはすべての人たち、といいたい）。この記事は、「テスター」と呼ばれる専門的な人々やテスターだけがテストすることを提唱しているわけではありません。その問題はまた別の議論です。
推論と反証
私は最初の上司からこんなことを言われました。
「ソフトウェアをテストするときは、バグがあることを前提に動かすべし。逆にソフトウェアが動くことを前提として動かしたら、期待通りの動きをしちゃって、バグはあまり見つからないものだよ。だけど、バグがあると仮定して、バグはあるものだと自分に言い聞かせれば、どこからどもなくバグが湧いて出てくるんだ」
このちょっとしたアドバイスは、「推論と反証（＝ソフトウェアが動くことを証明するのではなく、動かないことを証明すること）」という考え方の的を射ています。ソフトウェアをテストするときは、ソフトウェアがうまく動かないことを想定することから始めなければなりません。事実、テスト前のソフトウェアなんて動くはずもないのです。これっぽっちもです。バグがあるだけでなく、完全に間違っているのです。実際に誰かさんは、テスト前のソフトウェアを「これ動くよ」と偽ってテスターを騙そうとします。ドッキリに引っかかるようなものです。
このことをしっかりと念頭に置いたうえで、ソフトウェアが間違っていることを無理にでも証明しましょう。ソフトウェアがハリボテでないことを、ありとあらゆる方法でまったく疑うことなく納得できるまで、すべての操作を実行し、すべての動作がうまくいくことを証明するのです。そして、ちゃんと動作するソフトウェアが、ウルトラスーパーハイパーミラクルによってでき上がります。
言い換えれば、ソフトウェアに対してだけは「疑わしきは罰しろ」です。
優れたテスターは、この逆転の発想でソフトウェアにアプローチします。テスターは最悪の事態を想定した上でテストを始めるのです。健全な懐疑主義、建設的な悲観主義なんていい方もできるかもしれませんが、結局のところ言いたいことは、ソフトウェアは動作しないという仮定から始めるということです。そこから、ソフトウェアにその仮定は違うと証明させる、つまり正しく動作すると証明させることによって、テスターは先入観に囚われず他の人が見過ごしてしまうようなバグを見つけることができるのです。
逆転の発想とはソフトウェアテスト固有のものではなく、数学から投資まですべての考え方のいいアクセントになり、また支持されてもいます。この心得は誰でも学べるものです（ノーテンキな開発者でもね！）
共感とロールプレイング
他人の視点で世界を見たり、他人の経験を理解したり、他人の感じていることを自分のことのように感じたりすることは、簡単ではありません。それができるということは感受性が高いということであり、ソフトウェアをテストするときに非常に価値のある心得です。
優れたテスターはユーザーの立場に立って考え、何をするか、どのように操作に戸惑うか、なぜイライラするのかを予測できます。テスターはユーザーを深く理解し、行動を真似することで、実際のユーザーに問題を引き起こす前に、バグを発見できるのです。
ユーザーへの共感とは、「ユーザーは本を注文したいのだから、本を注文する操作をしよう」ということだけではありません。ユーザーの心理状態、動機、背景、目的を理解することであり、リサーチと想像力の両方が必要です。
このスキルに似ているものがあります。作り上げるタイプのロールプレイです（例：演技、TRPG、即興コメディなど）。これらはすべて「他人の立場にたって、相手を自分のようにイメージし、それに応じて行動する」ものです。ある意味、共感の練習とも言えます。
つまり、ドワーフの聖職者をロールプレイして、パーティで『バートルの9つの地獄』を探索すれば、よりよいテスターになれるということです（※:おそらく「ダンジョン&ドラゴンズ」というTRPGの内容を比喩している）
思い込みの打破
このフレーズはテスターの心得を説明するのによく使用されるため、決まり文句になっていて、形骸化しています。思い込みを打破することは、拗ねた5歳児みたいにひたすら「なんで？」と駄々をこねることではありません。先にあげた2つの心得と同じように練習が必要です。
「思い込みの打破」とは、「すべての思い込みを打破する」という意味ではありません。すべてを窓から投げ捨てて、ゼロから始めるという意味でもありません。我々はバートランド・ラッセルのように、360ページを費やして1 + 1 = 2を証明する必要もないのです。
実際、自分の思い込みが何なのかを知った上で活用することは、よりよいテスターになるための重要な要素です。重要なアプリの新機能をテストするときに、バグにつながる可能性のある操作パターンはほぼ無限です。思い込みは、まさにこの無限のテストのうち、もっとも合理的にバグを発見できる組み合わせへと絞り込むために使用するものです。思い込みは範囲を狭めるための貴重なツールなのです。
重要なのは、自分の思い込みは正しい方向性のものか、それとも迷わせているものかどうかを正確に判断できるようになることです。その思い込みは良いものなのか悪いものなのか、より高リスクな部分のテストを優先して低リスクな部分を見送らせるようなものなのか、疑うべき箇所なのにそんなテストは必要ない、そんなことは起きるわけがないと勘違いしてしまうものか？こういったことを判断するのです。
「思い込みの打破」という決まり文句は、このことを単純化しすぎています。やみくもに思い込みを打破してはいけません。どの思い込みを、いつ、どのように打破するのかを、あらゆる手段を駆使し理解することが大切です。
思い込みの打破の悪い例はこのような感じです。「うちのアプリケーションはこのOSSライブラリを使用している。このライブラリも動作すると思い込むのではなくテストしてみよう！」こんなことをするのはおそらく時間のムダなので、思い込んだままでいいです。そんなことするより、ライブラリについて少し調べてみるほうが、よっぽど価値があるはずです（すでに何百万人もの人が使用しているのか、素人の大学生が作ったものなのか、アクティブなコミュニティがあるか、バージョンが凍結されているのか、それともまだ開発中でバージョンアップする可能性があるか、など）
思い込みを常に認識して、テストに対して有用なものなのか、テストを誤解させるものかを判断することが、心得其の参です。
ただし、正しく思い込みを判断できると思い込まないように。
直感的な思考と探索行動
テストが単純な操作のみでまとめられるものであれば、テスターはいらないです。入力のパターン（たとえば、受け入れ基準やSUT(System under test:テスト対象システム)）に基づいて、期待値と結果がわかりきっているようなテストケースにできるものであれば、テスターはいらないです。テストとは、複雑で予測できないものです。テストには前提を疑う思考と創造性、そしてカンが必要です。大概、テストはアドリブでやるものです。テストを始めた時点では、その後どのようなテストを行っていくかわからないものです。優れたテスターは、テストとはカンに頼ってアドリブでやっていくものだということを知っています。
どういうことかわからない？ならその逆の考え方を見ればわかりやすいでしょう。具体的にはこうです。「境界分析、同値類分析、組み合わせ分析などの決まりきったテストケースで、OK,NGをつける(AC = All Clear)テストケースのリストを作成する。そして一定の基準に基づいてそのリストのテストをすること。まとめると、テスターはそういったテストケースの全リストを作成し、OKとNGを記録するだけでよいということ」ちなみに、この考え方はまだ巷にはびこっています。
こういう考え方をしている人にとって、テストとは単純で予想がつくようなものです。テストケースを作成する際にはある程度スキルが必要ですが、それさえ作成できてしまえば、テストなんて誰にでもできるようなことになってしまいます。つまり、どんなテストをするのかわかりきっているということです。
上述したように、この考え方は今でも業界内でのさばっています。テスト経験者の大半はこの考えに反対しているのですけどね。きっと一部のマネージャーは、テストというものはコモディティ化でき、細分化して安い労働力を使ってやらせることができるものだと信じているのです。
テストがアドリブ的な性質を持っていることは、すでに先駆者たちが詳しく解説しています。ですので、詳しく知りたい方はそういった記事や書籍をご参考あれ。例えば、Exploratory Software Testing （Elisabeth Hendrickson, James A. Whittake著）や、Agile Testing、More Agile Testing（Lisa Crispin, Janet Gregory著）などです。このあたりの書籍はテストのアドリブ的な性質について言及していますが、それ以外にもアジャイルチームにおけるテスターの役割といった、より大きな視点でも説明しています。JamesBachとMichalBoltonも、よくこのトピックについて熱く語っています。特にこの記事がオススメです。
それをディープテストと呼ぼうが、構造化探索テストと呼ぼうが、関係ありません。この心得は、テストをやりながらテストのやり方と方向性を考え直していき、知見を得ていくというものです。テストは、受け入れ基準のアルゴリズムで想定することも、事前に計算することもできません。
テスターなら、地図も持たず当て所ない旅路に出る覚悟があります。予測不可能で未知なものとは、ときに不安なものです。ですが、優れたテスターはこの心得を重視しているようです。
人間性の認識
ソフトウェアは長いプロセスの結果できあがるものだと心に留めておいてください。多くの人たちが時間をかけて協力し、1人で作ることができないような、大きく複雑なソフトウェアをつくりあげます。そのプロセスの一部として、テスターはテストをしていくのです。
ソフトウェアのバグは単に発生するだけでなく、そのプロセスに問題が発生していることも知らせてくれます。つまりテスターは、できあがるソフトウェアに関心を持つのと同じくらい、ソフトウェアの開発プロセスとそれに関わる人たちの行動に目を向ける必要があります。
人間性について研究すると、人間は完全な記憶力や、モチベーション、察知能力を備えたロボットとはほど遠いことにすぐ気づくでしょう。実際、そのとおりですし。
人間は、気が散り、忘れ、飽きるものです。イライラしたり、腹が立ったり、疲れたりもします。他人の成功に嫉妬もします。我々はそれぞれ自分の人生の目的とか野心、目標を持っていますが、「この会社でこのソフトウェアを開発するんだ！」というものは、おそらく目標ランキングトップ10にも入らないでしょう。働く理由はお金のためだったり、最新の技術に触れるためだったり、会社の事業内容に惹かれたためだったり、社会貢献のためだったりと人によってさまざまです。
これに加えて、人間は発見していく生き物であり、原始時代には生き残るのに役立つショートカットやパターンを見つけて繁栄してきました。しかし、ソフトウェア開発においてはその限りではありません。行動科学者は、このショートカットのことを「認知バイアス」と呼んでいます。たとえば、人間は自分が信じたいものを信じる傾向があったり（確証バイアス）、一度かけた費用をもったいないと思って合理的な判断ができなくなったり（サンクコストバイアス、コンコルド効果）、インパクトが強い事柄を重要視したり（アベイラビリティバイアス）、最初に見たものに囚われたり（アンカーバイアス）します。これらはたくさんあるバイアスのうちの、ほんの一例です。
人間の行動におけるこれらの欠点は、ソフトウェア開発でも同様です。これらの欠点は、開発者が開発するとき、ビジネスアナリストが分析するとき、経営幹部が企業戦略を実行するとき、および中間管理職が仲立ち役をやっているときなどに見えてくるものです。
ソフトウェアをテストするときは、こういうバイアスを乗り越えてできたものを見ているということを理解しましょう。探しているバグは、開発者が既知のアルゴリズムや仕様を間違って実装しているというより、バイアスによって発生している場合がほとんどです。つまりバグを発見したいのなら、
そのソフトウェアを開発した人がどんな人間なのかを知ればよいのです。
ソフトウェア開発とは根本的に人々による共同作業である以上、厄介なものであり、人間性による失敗が多発するもの、という心得をもとにテストをしましょう。
感想
こういったマインドセット的内容はQAエンジニアだけでなく、開発者や営業担当などいろいろな人が応用できるものだと思います。
特に開発者はユニットテストを書きますので、テストを書いて製品の品質を高めていく上で、上記のようなQAの考え方を意識するといいのかもしれません。
よりスムーズに、かつ漏れのないテストケースの作成に一役買うのではないでしょうか。