「テスト」と「チェック」の違い

2023/3/14 - 読み終える時間: 2 分

“Testing” Versus “Checking” の翻訳版です。

「テスト」と「チェック」の違い

2023年3月13日

著者: Nandish Kumar / HCLSoftware

私たちは皆、製品をとても早くテストしたいと思います。そのためにはどうすればいいのか？"道具を作って済ませよう！"と言いたくなりますよね。しかし、熟練した認知作業は、工場での作業ではありません。だからこそ、テストとは何か、ツールはその作業をどのようにサポートできるかを理解することが何よりも重要なのです。

ここテストセンター・オブ・エクセレンス（TCoE）では、テストプロセスの中で、機械ができることと、熟練した人間にしかできないことを区別しています。これは、通常の英語である "checking "という単語を、ツールでできることを指すようにすることで、言語的に実現しました。これは、"プログラミング "と "コンパイル "を区別するという、長い間定着してきた慣例と同じである。プログラミングとは、人間のプログラマーが行うものです。コンパイルは、特定のツールがプログラマーのために行うもので、コンパイラが行うことは、まさにプログラマーが行うことのように見えるかもしれません。自動プログラミングや手動プログラミングという言葉はありません。自動プログラミングと手動プログラミングの違いは、この比較で理解できるはずです。

テストとは、体験、探求、実験を通して製品について学び、製品を評価するプロセスであり、これにはある程度、質問、研究、モデル化、観察、推論などが含まれます。

テストはオープンエンドな調査であるのに対し、チェックは「ファクトチェック」の略で、特定の事実とその事実に関連するルールに焦点を当てます。私たちの業界でよくある問題は、"チェック "が "テスト "と混同されがちなことです。混乱を避けるために、こんな例えを試してみてください。チェックは記述可能ですが、テストはそうではないかもしれません。それは、チェックとは異なり、テストは暗黙知を含むからです。私たちは、チェックが本質的に悪いことだと言っているのではありません。それどころか、チェックすることは非常に重要なことかもしれません。しかし、チェックが良いものであるためには、適切なテストプロセスの中で行われる必要があると主張しています。チェックはテストの戦術である。

テスターは観光客以上の存在

テストでなくても、製品について学ぶために行うことはたくさんあります。製品を見学し、それが何でできているのか、どのように機能するのかを確認できます。これは非常に貴重なことですが、"テスト "とはちょっと違います。テスターと観光客の違いは、テスターの努力は製品を評価することに費やされ、単にそれを目撃することではないことです。

テストするためには、探検しなければならない

テストがうまくいくためには、その製品に携わらなければなりません。そのニュアンスに触れなければならない。これは探索的なプロセスであり、たとえ製品について完璧な仕様があったとしても同様です。心の中で、あるいは製品そのものを使って、その仕様を探求するまでは、私たちが考えるテストは表面的なものにとどまるでしょう。

また、製品を深く理解するために十分な探索を行った後でも、問題点を探索する必要があります。テストはすべてサンプリングであり、サンプルは決して完全ではないため、テストの価値を最大化するために、テストプロジェクト全体を通じて探索的思考が重要な役割を果たします。

探索とは、目的をもって歩き回ることであり、一般的な使命を持ちながら、決められたルートなしに空間をナビゲートすることを意味します。エクスプロレーションには、継続的な学習と実験が含まれます。バックトラックや繰り返しなど、素人目には無駄としか思えないようなプロセスも多くあります。探索には、多くの思考が必要です。探検は探偵の仕事です。オープンエンドな探索です。探検は、ある空間を移動することだと考えてください。前方、後方、横方向の思考が必要です。

ブラックボックステストは、無知に基づくテストではありません

ブラックボックステストとは、製品の内部に関する知識は、私たちのテストにおいて重要な役割を果たさないということです。ほとんどのテスターはブラックボックステスターです。ブラックボックステストをうまく行うには、まず、ユーザー、期待やニーズ、技術、ソフトウェアが動作する構成、このソフトウェアが相互作用する他のソフトウェア、ソフトウェアが管理しなければならないデータ、開発プロセスなどについて学ぶ必要があります。

ブラックボックステストの利点は、プログラマーとは異なる考え方をするため、プログラマーが見落としたリスクを予見できる可能性が高いことです。ブラックボックスで重視されるのは、ソフトウェアのユーザーや環境に関する知識です。テスターは基本的なコードに無知であるため、これを無知ベースのテストと表現することもあります。

製品についてより多くのことを学び、より多くの方法で知れば知るほど、より良いテストができるようになります。しかし、もし私たちの主な焦点がソースコードと、ソースコードから導き出されるテストにあるならば、私たちはプログラマーがすでにカバーした領域をカバーすることになり、そのコードに関する知識は彼/彼女のものよりも少なくなってしまうでしょう。

複雑な製品をテストするとき：飛び込んで、そしてやめる

複雑さに圧倒されることがあります。知的な麻痺を感じることさえあります。ですから、複雑で大変な機能セットをテストするときは、一気にやってしまいましょう。しかし、複雑な製品を一度に理解しようとは思わないでください。

30分でも1時間でも、そのプロジェクトに身を投じてみてください。そして、いったん中断して別のことをする。これは、"plunge in and quit "と呼ばれる方法です。この短時間は生産性が低くても気にせず、混乱しそうなら早めにやめる。

この方法の素晴らしいところは、製品の一部を選んで作業すること以外に、まったく計画が必要ないことです。何度か「やってはやめ」を繰り返すうちに、製品のパターンやアウトラインが見えてくるはずです。やがて、より整理された、具体的なテストや勉強の戦略が浮かんでくるはずです。

混乱はテストツールである

仕様書はわかりにくいですか？仕様書の曖昧さは、有力な利害関係者間の重要な意見の相違を覆い隠すためにあることが多い。

製品は混乱していますか？それは壊れている可能性があります。

ユーザードキュメントはわかりにくいですか？製品のこの部分があまりにも複雑で、特殊なケースや矛盾が多すぎて説明できない可能性があります。

根本的な問題が理解しにくいだけでは？自動化しようとするシステムの中には、本質的に複雑なものや、難しい技術的な問題を含んでいるものがあります。

製品、技術、テスト全般について学べば学ぶほど、混乱のコンパスは広がり、重要な問題がどこにあるのかを教えてくれるのです。

新鮮な目で失敗を見つける

何かを理解することは、新しい情報をすでに知っていることに同化させ、新しい情報に対応するために知っていることを修正する、豊かな知的プロセスです。ある製品や機能を理解した後、私たちはその製品に関するメンタルマップを手に入れ、頭があまり働かなくなります。このことは、テスターとして問題になることがあります。ある製品についてよく理解していると、その製品について仮定することができ、その仮定を確認する頻度も少なくなります。

• ある製品や機能を初めて目にしたとき、私たちが何に戸惑い、何に悩まされるかに特別な注意を払います。それは、ユーザーがどのように反応するかについても、何かを教えてくれるかもしれません。

• チームに新しい仲間が加わったときは、一緒にテストしてみましょう。彼らが製品を理解する過程で、どのような反応を示すかを観察するのです。

• テストのマンネリ化に注意する。厳格なテストスクリプトに従っていなくても、特定の機能に慣れ親しむあまり、テスト方法がだんだん狭くなってしまうことがあります。

• できる限りバリエーションを増やすか、他のテスターとテストの担当を交代しましょう。

テストプロセスの重要な成果の1つは、より優れた、より賢いテスターになること

優れたテスターは常に学習しています。プロジェクトが進むにつれて、テスターは製品に対する洞察を深め、そのプロジェクトで重要なあらゆる面で反射神経や感性を徐々に磨いていきます。製品を熟知し、リリースサイクルを1～2回経験した経験豊富なテスターは、製品のテスト方法について書かれた指示書を渡された経験の浅いテスターに比べ、指示がなくてもテストの効果を大幅に向上させることができます。

HCLSoftwareのTest Centre of Excellence (TCoE)の詳細については、HCLSoftwareまでお問い合わせください。