誰がテストしているのか？
あなたの会社では誰がソフトウェアをテストしていますか？
テストをおこなう人たちは、テストに必要なスキルのトレーニングを受けた人たちでしょうか？また、テストケースを作成し、テストケース通りの操作をおこなうよう教育を受けた人たちでしょうか？もし、テストに必要なスキルのトレーニングを受けてなかったとしたらどうでしょう？もしくは、テストをおこなうための作業手順を与えられていたとしても、その作業手順に従った通りのテストをおこなっていなかったら？
また、その人たちが、「テスト」を実施することを期待されていないとしたら? その人たちが、ITやソフトウェア開発の現場で働いていないしたら? それでもその人たちを 「テスター」と呼べるのでしょうか?
ここ数年、多くの企業では、テストに必要なスキルのトレーニングを受け、テスト関連の仕事を期待されている人たちがテストするのではなく、他の人たちがテストをおこなうようになってきています。
Tea Time with Testers 誌がまとめたレポート「State of Testing, 2020」では、この興味深い傾向が報告されています。より多くの組織が、「テスター」ではなく、ビジネスのニーズや機能を理解している人にソフトウェアのテストを依頼しているのです。ある意味、これは非常に理にかなっています。
本記事では、この傾向を最大限に活用する方法をご紹介します。
ビジネスの専門性の価値を見極める
この傾向についての、多くの「伝統的な」テスターやソフトウェアの専門家の意見は、「まあ、確かに。しかし、彼らはテスト手順書に従って作業する訓練を受けていないですし、本当に技術的な仕事はできませんよ」というものでした。しかし私たちは、テスターに対して、「テスト手順書どおりに作業する」ことを要求したいのでしょうか？「テスト手順書に従う」こと自体が良いテスト作業につながるのでしょうか？
技術的な面に関しては、データベースに対して SQL クエリーを実行することに抵抗のない「手動」テスターはどれくらいいるでしょうか？ UI に現れない動作の証拠を見つけるために、システム ログを調べることに抵抗はないのでしょうか？ あるツールから別のツールへと移動して、「テスト手順書に従う」ことでは調べられないシステム箇所を調べるのに心穏やかなのでしょうか？
多くの人は実体験によって物事を学びます。新しい携帯電話やノートPCを手に入れたとき、付属のマニュアルを読みますか？ユーザー ガイドやクイック スタートガイドが同梱されていない場合に、オンラインで探しますか？デバイスを使用する前に、その使い方のヒントや TIPS を、先にすべて読むでしょうか？
恐らく、多くの人は読まないでしょう。その代わりに、以前に経験した知見を活用し、目の前のデバイスがどのように動作するのかを確認します。私たちは電話の使い方を知っています。ノートPCやデスクトップPCの使い方も知っています。
私達は、新しいデバイスを使い始めるとき、他のデバイスでの経験や予想と比較します。経験のモデルと照らし合わせて新しいデバイスの動作を確認します。事実上、私達は新しいデバイスをテストしているのです。
さまざまな役割で働いた経験を持つ人たちは、自分のニーズや期待を満たすように動作するかどうかという観点で、ソフトウェアを評価することができます。彼らは、達成する必要があるビジネスプロセスの理解に基づいてソフトウェアをテストできるのです。
トレーニングの落とし穴を避ける
経験豊富なビジネス ユーザーがテストをおこなう際によく言われるのは、ソフトウェアを使用するために「トレーニングを受ける必要がある」ということです。新しいソフトウェアの動作が、彼らがこれまで経験してきたものとは根本的に異なる場合には、トレーニングが必要になるケースもあるでしょう。しかし、用意された膨大なテスト手順書に従っても、ソフトウェアの実動作のテストにはほとんど意味がありません。
古いシステムとの違いを含め、新しいシステムがどのように動作するのか、各部分がどのように相互作用するのかについての短いチュートリアルがあれば、多くの場合、より効果的なトレーニングになります。違いを説明した上で、大まかに決められたシナリオに沿って作業を進めていく様子を見守り、優しく指導することで、新しいソフトウェアの学習をより成功させ、ソフトウェアのテストをより効果的に行うことができます。
しかし、多くの組織は、「トレーニング」と「テスト」を組み合わせて同じ活動にしようとします。「テスター」はテスト手順書に従ってソフトウェアを「テスト」するように指示されます。理論的には、彼らは新しいシステムを正しく使うことを学ぶことになります。
ここで問題なのは、「ソフトウェアが何をすることになっているか」ではなく、「彼らが何をすることになっているか」に焦点を当てていることです。彼らは実際にソフトウェアをテストしていないのです。
ここにトレーニングの落とし穴があります。何かをする方法を人に示す場合には、はじめに作業のデモンストレーションをおこない、仕事のために何をする必要があるのか、学習したり実体験したりしてもらいましょう。そうすることで、デモンストレーションで見たことを実際の仕事に応用する機会が得られます。
ビジネスニーズとワークフローを理解している人は、あらかじめ決められたテスト手順に従って「学ぶ」必要はなく、その知識をもって、新しいシステムのテストを直ちに実施できます。
組織によっては、このコンセプトがテストプロセスを管理する上での課題となっています。詳細な作業手順は、テストの進捗状況や有効性について測定可能な証拠を常に提供するという考えは根強くあります。つまり、特定のテスト手順において何らかの不具合を見つけることができれば、その作業が有用であったと示せるということです。
新しいソフトウェアのテストにビジネスの専門家を使用している企業に対してこのような提案をしたときに受ける最も一般的な反応は、それらの企業には、何がおこなわれているか、どの領域に問題があるかを測定するための良い方法がない、ということです。
詳細なテスト手順書なしで進捗を測定する
ここで、測定のニーズの対応についてご紹介します。
まず、彼らの作業のために必要な作業リストを用意します。高レベルと中間レベルの作業の「パンチリスト（片付けなければならない作業のリスト）」を作成するために、おそらく複数のビジネス領域の人々と話す必要があるでしょう。この対話により、「自分はどのように、この作業をおこなうのか」に焦点を当てて作業できるリストが得られます。また、仕事そのものを深く理解することができ、まだトレーニング資料がない場合は、ターゲットを絞った資料を作成することができます。
高レベルと中間レベルの作業リストは、進捗状況とシステムの準備ができているかどうかの指標にもなります。ソフトウェアのテスターは、そのソフトウェアが本運用された際に使用する人たちと同じです。必要な各機能が正しく動作することにテスターが満足していれば、それらの作業のテストは完了です。
「Just In Time」のアイデアを借りて「Just Enough」トレーニングを作成し、デモンストレーションと基本的な演習を行った後に、質問に回答できる新システムの専門家を用意します。また、テストの専門家に回答してもらうことで、発見された問題を開発チームに伝える手助けにもなります。
ビジネスの専門知識をテストの自動化に適用する
アプリケーションをテストするビジネスの専門家は、シナリオベースの自動テストに組み込むことができる実際のシナリオも提供しています。これらは、回帰テストやシナリオベースのスモークテストのモデルとして作成し、使用することができます。
ビジネスとテストの専門知識を組み合わせることで、ビジネスにとって最も一般的で最も重要な関心事をカバーする現実的なテストシナリオを作成できます。テスターは、テストの経験がなければ考えられなかったであろう領域を探し、作業を構成するのに役立ちます。しかし、テストの大部分は、自分や顧客にとって何が必要なのかを見極めた上でおこなうことになります。
このような作業環境は、IT とテストグループ、およびソフトウェアを毎日使用している人たちとの間において、関係性を改善し、パートナーシップを構築します。それぞれが直面している課題と、それを克服するためにどのように助け合うことができるのか、両者がより密接な関係性を感じ、仕事や製品、組織の改善につながるのです。
作者について：
Peter G. Walenは、ソフトウェア開発、テスト、アジャイルの実践において25年以上の経験があります。彼は、自分たちのソフトウェアがどのように動作し、他のソフトウェアやそれを使用する人々と相互作用するかをチームが理解できるように支援することに尽力しています。彼は、アジャイルアライアンス、スクラムアライアンス、米国品質協会（ASQ）のメンバーであり、ソフトウェアミートアップに積極的に参加し、頻繁にカンファレンスのスピーカーを務めています。
（この記事は、開発元 Ranorex 社 Blog 「Exactly Who is Doing the Testing?」2020年10月6日の翻訳記事です。）
