技術を土台にして自分なりのQAエンジニアを目指す本連載では、まず「テスト設計」を取り上げたいと思います。
例えば、情報処理技術者試験でテスト技法が問われるほか、テスト設計コンテストというイベントが開催されます。そのため、日本においては最も馴染み深いソフトウェアテストの技術の一つと言えるでしょう。
この記事では、私自身の経験を通じて得た「テスト設計」に対する考えを言語化し、皆さんにとってのヒントになることを目指します。
▼前回の記事はこちら
【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる
この記事におけるテスト設計
「テスト設計」という言葉の意味や扱い方には、実は組織や人によって大きな違いがあります。
この記事では、以下のような定義をしたいと思います。
テストをする理由を具体化し、テストケースを作成することが目的のアクティビティ
一般的に、この記事で「テスト設計」としているプロセスは「テスト分析」「テスト設計」「テスト実装」といった複数のアクティビティに分割されます（ソフトウェアテスト技術者資格であるJSTQBの定義などが代表的です）。
それぞれを区別することには合理的な理由がありますが、この記事では説明を分かりやすくするため、これら一連の流れをあえて「テスト設計」という単一のプロセスとして扱います。
テスト設計という技術の捉え方
テストエンジニアとしてのキャリアをスタートさせたときに、最初に魅力的に感じたのはテスト設計でした。
テスト設計は「テストすべきこと」を捉え、構造的に整理して、テストケースに書き下す一連の活動です。これらは私自身が得意とする分析的な思考を活かせる活動だと感じたからです。
「テスト設計プロセス」という壁
一方で、「テスト設計プロセス」という考え方は、駆け出しだった私にはとっつきにくい概念でした。
まず現場において、テストの土台となるテスト計画がなかったり、「テストすべきことを段階的に詳細化する」という概念がない場合もあります。そのため、テストを設計するノウハウやリソースが十分でないこともあるでしょう。
また、「テストすべきこと」を発散させ、テストスイートやテストケースの形に収束させる作業は、簡単なものではありません。当時の私はそれにも気づけていませんでした。
テストケースを捉えることで壁を見通す
「テスト設計」というものを自分なりに深く理解するきっかけとなったのが、「テストケース」という概念を捉えたことでした。
テストケースとは、「テストを扱いやすい単位で定義するための成果物である※」と私は捉えました。
「テスト」という活動は、多くの時間やリソースを要するにもかかわらず、曖昧で捉えどころがないものです。テストケースとは、その巨大で曖昧な活動を、プロジェクトや組織にとって扱いやすい単位に分割し、共通理解を促すために定義するものだと理解したのです。
テストケースは構造を持っています。そしてそれ自体が暗黙の前提や期待を形として表すものとして機能する性質があると捉えました。
テストには普遍的な課題があり、それを解決するための「テストケース」があり、課題とテストケースの間に「テスト設計」というプロセスがあると捉えることが、私にとっての最初のブレイクスルーでした。
壁を超えたとまでは言えませんが、「見通すことができた」という実感が湧いた瞬間でした。
※発信する媒体やコンテキストによって「テストケース」の表現を変えることはあります
テスト技法についての自分なりの理解を深める
「テストケース」を中心にテスト設計プロセスを捉え直すと、「テスト技法」についての理解が深まりました。
当初、「なんとなくルールにしたがって図を書いたり表を書いたりする」程度の理解をしていましたが、「テストケースを作るためにテスト設計は存在する」と考えると、様々なものが私の中で繋がりました。
「テストのスコープと網羅性を定義するための合理的な手法が存在し、それらを満たすテストケースを導出するものがテスト技法である」という理解をしました。
自分なりの理解をすることで、単に「それっぽい図を書く」ではなく、「目的意識を持って必要なテスト技法を使う」という、テスト技法の活用に対する主体性を手に入れることができたのです。
テスト対象の特性を理解する
テスト設計する際には、「テストすべきこと」を考えることが必須となります。ちなみに、「テストすべきこと」はテスト観点、テスト条件、テスト要件など、現場によってさまざまな表現がされます。
これらはブレインストーミングとしてアドホックに導出することは有効ではありますが、様々な特性や手法を意識して導出することもひとつの方法だと考えています。
この中で重要だと考えているのは「テスト対象の特性を理解する」ということです。
テスト対象の特性としては、アーキテクチャスタイル/パターンや入出力の特徴や取り扱うデータの性質などが挙げられます。
これらの特性はテスト設計の方針やテストケースの形にも影響を与えます。
テスト対象の特性を踏まえた上でどのようなバグが発生しうるか、などはテスト設計の際に必ず考えておきたい点です。
専門性の組み合わせ
本連載のテーマのひとつである「専門性の組み合わせ」について、今回は「テスト設計」を軸に、テストエンジニアの基本的なタスクである「テスト実行」との関連を解説します。
テスト実行を通じてテスト設計にフィードバックする
テスト設計とテスト実行を繋げるような技術としては、テスト実行とテスト設計を短いスパンで繰り返すような探索的テストというスタイルがあります。
探索的テストを明示的に選択していなくても、テスト実行で得られた気づきや知見の中で、「テストすべきこと」につながるものを見つけることがあります。こうした気づきについてフィードバックを行ったり、自らそれらをカバレッジする合理的なテストケースをすぐに作って実行できるようになります。
合理的に切り分けを行ったバグ報告ができるようになる
「テスト設計」とは「適切な形に分割する」という側面があることに言及しました。この専門性を別の角度から捉えると、バグ報告や調査の際に適切な切り分けができることに発展する可能性があります。
現実に起こっている事象から、構造的に理解して、バグの影響範囲や原因特定に必要な情報を提供することは、前提となる情報が仮説か事実かの違いだけで、実際にはテストケースの設計と同じような同じ思考プロセスを辿っています。
おわりに
この記事では、テスト設計という技術について私がどのように向き合ってきたかを述べました。
なお、実務や学習においては「テスト設計」という単一のアクティビティという理解から、何をテストすべきかを見極める「テスト分析」、合理的なテストケースを導出する「テスト設計」、テストを実行可能にする「テスト実装」など、それぞれのアクティビティを意識することが、専門性をさらに高める鍵になります。
「テスト設計」を単に与えられたタスクとしてテスト観点やテストケースを書くのではなく、自分なりに必要性や目的意識をしっかりと理解して実施することは、自分自身の確かな土台となるはずです。
▼前回の記事はこちら
【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる
