この記事はNishi Grover Gargによるゲスト投稿です。

私は最近、ソフトウェアテストコンサルタントのJames Bachがインドを訪れた際にお会いし、テスト技術について意見やアイデアを伺う機会がありました。テストの心理学について理解が深まっただけでなく、改めて自動化が行うのはチェックだけという見方を強くしました。テストのクリエイティブで人間的な側面はテスターにかかっている、そのことを私は数年前、自分自身も現場のテスターという立場で経験し、それについて書いたこともあります。

人間によるテスト

テストは単に多数のテストを実行し、クリックやアクションを行うだけではありません。テスターは独自の観点でシステムを理解し、さまざまな方法で検討します。時間が経つにつれて、テスターはアプリケーションとその複雑さ、統合、弱点、履歴を深く理解するようになります。そのため、テスターはシステムの故障ポイントを発見し、システムの健康状態についてコメントするのに最適な審判役となります。

製品リスクナレッジギャップは、私たちが製品について知っていることと、知る必要があることの差です。テストの目的は、このギャップを埋める、少なくとも減らすことです。

自動化されたチェックは、私たちが知っていること(そしてチェックするようにスクリプトを書いたこと)の問題を判断するのに役立ちますが、私たちが製品について知らないことのリスク領域では、それほど役に立ちません。そこでは探索、クリエイティビティ、直感、そしてドメイン知識が必要です。これがテストの人間的な側面です。

自動化されたチェック

通常、テスト自動化スクリプトは次の流れに従います。

自動化されたスクリプトには、事前定義されたテストデータという形で埋め込まれた何らかの手順と、追加された検証があります。これらの手順は、チェック、ダブルチェック、あるいは何度も繰り返しチェックする必要があるアプリケーション領域には役立ちます。また、このようなタイプのチェックは明示的に作成できるので、自動化が可能です。同じステップが繰り返し繰り返し同じように実行されるため、「テスト」というより「チェック」と呼ぶのが適切です。

テスト自動化のスキルはテスト業界で多大な関心を集めており、それなしではテスターは時代遅れになりかねない、需要の高いスキルとみなされているほどです。多くのテスターは、コードやテストスクリプトを書けないことで、チームにとって役立たずになることを恐れています。しかし、実際にはそんなことはありません。テスターは、使うツールによって定義されはしません。それは、開発者がプログラミング言語やIDEによって定義されないのと同じです。

コードを書いたり理解したりできること、あるいは自動化されたスクリプトを作成できることは、テスターにとって役に立つスキルですが、コーダーとそうではない人の思考傾向の違いについても注目する必要があります。

コーダーとそれ以外の人は違ったふうに思考し、同じソフトウェアを違ったふうに認識します。コーダーでない人は、ユーザー中心的な思考傾向を持っており、一般的によりユーザーに親和的です。ですから、コードを読み、理解し、分析できることを評価するいっぽうで、テストの人間的側面を否定することはできません。

２つを１つに

テストには暗黙のソーシャルスキルや人生経験、状況を把握する能力が必要ですが、これらのスキルを完全にコード化することはできません。テストは探索と実験を通じた学習によって製品を評価するプロセスであり、チェックを含んでいます。

人間によるテストに、自動化されたチェックを加えたうえでバランスを取ることが、テスト自動化の取り組みにおいてROIを獲得する最良の方法です。以下に挙げるのは、バランスを取る方法の例です。

• カバレッジ率や数字を追うのではなく、何を自動化する必要があるのかを理解する
• 本当に必要なものだけを自動化し、探索には人間によるテストを利用する
• むやみに技術的負債と格闘するのではなく、意識的に決定を行う

テストとチェックは、組み合わせることでベストな効果を発揮します。自動化されたチェックは製品の評価に向けたテスターの作業を補完する手段として働きます。

テストとチェックは真のパートナーシップであり、私たちの努力から最大の成果を達成するには、どちらも追求する必要があります。このパートナーシップは、バランスよく利用すれば、最大の結果を生み出します。

（この記事は、開発元Gurock社の Blog 「The Partnership of Testing and Checking」2020年1月21日の翻訳記事です。）