この記事はPeter G Walenによるゲスト投稿です。

私たちがソフトウェアをテストする際の非常に難しい課題の1つが、重要かもしれない現象を何一つ見逃さないようにするということです。もちろん、難しさの一端は、何が重要かが分かっていない、重要でないものと重要なものを区別できない場合も多いという点にあります。

他人が書いたスクリプトを実行するとき、よく言われるのが、各ステップまたはアクションの「期待される結果」に集中しなさいということです。たいていの人がそのとおりにします。非常に狭い結果に意識を集中させます。指示がそれを要求しているのです。

多くの場合、それ以外のことをすると批判や叱責を受けます。厳密にステップに従うようにと言われるでしょう。バリエーションは悪であり、変化させたり逸脱を導入してはなりません。指示されていないことをする、指示された方法でやらないのも等しく悪です。

もちろん、そうやってテストされたソフトウェアが運用環境でエラーを起こしたら、叱責と応酬はとどまるところを知りません。なぜテスト時に問題を見つけられなかったのだと、テスターに多くの非難が寄せられます。ずさんでプロ意識のない仕事だと、「テストチーム」に多くの非難が寄せられます。

絶対的な厳密さで従うべきスクリプトに、そのエラーを検出するのに必要なステップがいっさい含まれていなかったことなどおかまいなしです。問題を発見するのに必要な条件は示されていませんでした。スクリプトに書かれた内容に従うなら、エラーを検出できるわけがなかったのです。

なぜ狭い範囲に集中するか

多くの組織は、このような厳格さで「テスト」を実施するよう指示してきました。今は「自動テスト」も同様に行っています。作業量についても各テストにかかる時間についても、計測と見積の予測がつくパスに労力を集中しています。

このようなアプローチがいくつかの問題をもたらします。

1つは、「テストは誰にでもできる」、「テストは簡単だ」という見方の維持につながることです。もう1つは、多くのテスターに技術的スキル ーSQLで書かれたDBクエリーを読むことから、顧客が接するソフトウェアを動かすコードを読み、理解することまでー が必要とされなくなることです。また、テストをソフトウェア開発とは別の職務としつづけ、「テスト」を知識労働以外の何かに追いやることになります。

こういった要因が組み合わさると、テスターは組織に貢献しておらず、ツールや自動化で簡単に置き換えられる、あるいは、テスターは必要ないのだから、単に開発者にテストをやらせればいいという有害な意識ができあがります。

どうしてこんなことになるのでしょうか？

指示されたことだけやればいいという習慣は、効果的なソフトウェアのテストに必要とされる最も重要な特性の1つを人間から奪います。すなわち好奇心です。

テストを実施する人たちは、何か変わったことに気が付いても無視するように訓練されています。せいぜい、「実際の結果」の欄にメモを残して次に行くぐらいのものでしょう。もし完了済みのスクリプトを見てメモを確認する誰かがいるなら、申し分なく意味のある行為でしょう。私が見てきたたいていの組織では、そんなことはしません。

テストをする人間は、不審な動作を調査するのに時間を使ったりしたら、結局なんでもなかったときに「時間を無駄にした」と叱責されるということを学習します。実際に問題が検出された場合でさえ、まっさきに尋ねられるのは、「これはテストに含まれていたのか」ということが多いでしょう。

その理由は、「他のチーム」も他のテストをやっているからです。そうかもしれません。しかし、その「他のチーム」が同じ異常を発生させる条件と状況に行き当たる可能性はどれくらいあるでしょうか？また、なぜ複数のチームがソフトウェアの同じ部分に対して詳細なスクリプトを実行しているのかという疑問も生まれます。

多くの企業は、見たものを無視するような教育をしています。そうではない企業も、また別の失敗をしています。テストを行う人員に予期しない動作や結果を調査することを奨励してはいません。これは、作業の他の面やチームにも、さらにその作業をする人間にとっては将来の仕事にまで影響を及ぼします。

私たちテスト業界の人間は、ほとんど「見る」ことを教えていません。「観察」することを教えていません。

見ているが…

「見る」というのは面白い言葉です。一般的な定義はたとえば次のようなものでしょう。「目で知覚する。視覚によるもののように知覚または検出する」もちろん、他にも定義もあります。たいていの人は、最初の概念を把握して先に行くのではないでしょうか。

これは多くの人が教えられる「テストする」方法と同じです。分かりやすい概念や結果を大づかみしたら、次のステップに進みます。しかし、そうすることで、「意識する」といった、あてはまるかもしれない定義を見逃してしまう可能性があります。

これも、最初の結果が無視できるように見えるのとよく似ているかもしれません。いっぽうで、これは一部の組織、私の経験では多くの組織がテストに取り組むときの問題でもあるかもしれません。

テスターが何か普通ではないものを見ることはあるでしょう。もし「期待される結果」に加えて「普通ではない、あるいは場違いに見える何か」を探すよう言われていなければ、一部の、あるいは多くの人は、それをレポートするのを躊躇するでしょう。時間を浪費しただとか、テストに含まれない「余計な作業」をしたと批判されることは望まないでしょう。

先にも言ったとおり、「実際の結果」のところに注意書きを入れるかもしれませんが、詳細な結果を見る人が誰もいなければ、プロジェクトにとって何にもなりません。

これで、言うなれば手詰まりです。みな特定のことだけをし、異常を見つけても興味を持たないよう教育されています。異常を調べるよう口頭で言われることはあったかもしれません。しかし、アプリケーションに精通していなければ、見ている動作が異常なのか「通常」なのか分からないのではないでしょうか。

何度か「よくわからない現象を見ました」という報告をした後は、同じことを繰り返すのをためらうようになるかもしれません。肩をすくめて次のタスクに移るでしょう。

観察していない

「観察」もまた面白い言葉です。Oxford English Dictionaryでは、「(何かを)認めて、または知覚して、重要であると記録する」と定義されています。これは何かを「見ている」、あるいは存在に気付いているという以上のことです。一歩踏み出しています。そこに何らかの重要性があることを認識しています。

見たものを巡って何らかの思考または検討を伴う行為です。

面白いことに、私が手がかりやヒントを掴む方法を学ぶためのワークショップやトレーニングセッションを行うとき、やってもらう演習がいくつかあります。それは一連のパターン認識と認知の演習です。つまり、ソフトウェアやその他の「動作を観察する」とはどいうことかを知る助けになるものなのです。

私が参加者に伝えようとするのは、ささいに見える動作の陰に非常に大きな問題が潜んでいることもある、ということです。画面の小さなちらつきや、表れては消えるメッセージは、どこかよそで起こっている、それほど分かりやすくはない何かを示す手がかりかもしれません。

手がかりは、ときには画面上のメッセージの文言であるかもしれません。期待されるのとほんの少し違うメッセージは、見過ごされがちですが、実は他の問題に関する警告を与えてくれている可能性があります。重要性を理解するには時間がかかる場合もあります。また少しばかり練習が必要であるのが普通です。

テストを行う際、探すのを「期待されている」ものに集中するあまり、他の現象の重要性を認識できないことがあります。それが目の前にあってもです。

このことについて、私は19世紀後半に創作された架空の人物から大きな教訓を得ました。アーサー・コナン・ドイル卿によって創造されたシャーロック・ホームズです。

「きみは見ているが観察していない。違いは明白だ」

テストをするホームズ

ホームズを通じてドイルが提示したもう1つの考えを検討してみましょう。「世界は、誰もけっして観察しようとしない明らかなことで満ちている」

この考えは、先の引用と合わせ、不適切なテストにからむ問題の中心と思われるものを説明しています。人は何かを見ていても、その重要性や価値を理解していないことがあります。ときには、終始そこにあって、まったく隠されてもいない、それなのに誰もその正体を認識していないものもあります。

ソフトウェアのあらゆるバグや問題が不適切なコーディングの結果とは限りません。ソフトウェアのあらゆるバグや問題が容易に理解可能とも限りません。しかし、積極的に見るとき、ソフトウェアが動作していることろを観察するとき、ずっと目の前にあった問題を理解できるかもしれません。

ときどき出現する奇妙なエラーメッセージは、バスカヴィル家の犬とすこしばかり似た働きをします。それが現れること自体に不思議はありません。それがいつ現れないかが問題の手がかりとなるかもしれません。

目下のタスクに集中しながら、同時に周りで起きていることを意識し、注意するのは難しいこともあるでしょう。これはソフトウェアテスターでなくても直面する課題です。それどころか、この課題に直接的に注意を向けるのに役立つよう、「シチュエーショナル・アウェアネス」という言葉が作られました。

私たちは周りにあるものを意識する必要があります。単なる表面を超えて、その下にある動作とアクティビティを見る必要があります。従っているスクリプトにそうしろと「指示」されていなくとも、私たちはテストアクションによってどのような影響があるかを見る必要があります。

ほんの小さな手がかり、ホームズなら「些末事」と形容するかもしれない手がかりが、大問題を明らかにするかもしれません。私たちがテスト対象ソフトウェアの動作を研究し、学ぶなら、興味を引くが目くらましでしかないものの中から重要なものを見抜くことができるでしょう。テストを行うときは、できる限り多くを取り込み、適切にフィルタリングして意味のある解析を提示する必要があります。

教訓

こういった教訓は、通常、痛い経験を通じて学ぶものです。スクリプト化された期待値以上のものを見るようになると、テスターはスクリプトを書いたり設計したりした人たちを含め、他の誰も見つけられない動作を観察し始めることができます。単に見るだけでなく観察するとき、テスターはシャーロック・ホームズの教訓を活かし始めます。

Peter G. Walenは、ソフトウェア開発、テスト、アジャイルプラクティスで25年以上の経験を持っています。ソフトウェアがどのように動作し、他のソフトウェアと連携するか、またソフトウェアを利用するユーザーをチームが理解できるよう支援に尽くしています。Agile Alliance、Scrum Alliance、American Society for Quality (ASQ)のメンバーであり、ソフトウェアミートアップに熱心に参加し、カンファレンスでもたびたび講演しています。

（この記事は、開発元Gurock社の Blog 「You See But Do Not Observe: Sherlock Holmes on Software Testing」2020年9月2日の翻訳記事です。）