【第2回】テストを設計する専門性|技術を土台にして自分なりのQAエンジニアを組み立てる

技術を土台にして自分なりのQAエンジニアを目指す本連載では、まず「テスト設計」を取り上げたいと思います。

例えば、情報処理技術者試験でテスト技法が問われるほか、テスト設計コンテストというイベントが開催されます。そのため、日本においては最も馴染み深いソフトウェアテストの技術の一つと言えるでしょう。

この記事では、私自身の経験を通じて得た「テスト設計」に対する考えを言語化し、皆さんにとってのヒントになることを目指します。

▼前回の記事はこちら
【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる

この記事におけるテスト設計

「テスト設計」という言葉の意味や扱い方には、実は組織や人によって大きな違いがあります。
この記事では、以下のような定義をしたいと思います。

テストをする理由を具体化し、テストケースを作成することが目的のアクティビティ

一般的に、この記事で「テスト設計」としているプロセスは「テスト分析」「テスト設計」「テスト実装」といった複数のアクティビティに分割されます(ソフトウェアテスト技術者資格であるJSTQBの定義などが代表的です)。

それぞれを区別することには合理的な理由がありますが、この記事では説明を分かりやすくするため、これら一連の流れをあえて「テスト設計」という単一のプロセスとして扱います。

テスト設計という技術の捉え方

テストエンジニアとしてのキャリアをスタートさせたときに、最初に魅力的に感じたのはテスト設計でした。

テスト設計は「テストすべきこと」を捉え、構造的に整理して、テストケースに書き下す一連の活動です。これらは私自身が得意とする分析的な思考を活かせる活動だと感じたからです。

「テスト設計プロセス」という壁

一方で、「テスト設計プロセス」という考え方は、駆け出しだった私にはとっつきにくい概念でした。

まず現場において、テストの土台となるテスト計画がなかったり、「テストすべきことを段階的に詳細化する」という概念がない場合もあります。そのため、テストを設計するノウハウやリソースが十分でないこともあるでしょう。

また、「テストすべきこと」を発散させ、テストスイートやテストケースの形に収束させる作業は、簡単なものではありません。当時の私はそれにも気づけていませんでした。

テストケースを捉えることで壁を見通す

「テスト設計」というものを自分なりに深く理解するきっかけとなったのが、「テストケース」という概念を捉えたことでした。

テストケースとは、「テストを扱いやすい単位で定義するための成果物である」と私は捉えました。

「テスト」という活動は、多くの時間やリソースを要するにもかかわらず、曖昧で捉えどころがないものです。テストケースとは、その巨大で曖昧な活動を、プロジェクトや組織にとって扱いやすい単位に分割し、共通理解を促すために定義するものだと理解したのです。

テストケースは構造を持っています。そしてそれ自体が暗黙の前提や期待を形として表すものとして機能する性質があると捉えました。

テストには普遍的な課題があり、それを解決するための「テストケース」があり、課題とテストケースの間に「テスト設計」というプロセスがあると捉えることが、私にとっての最初のブレイクスルーでした。

壁を超えたとまでは言えませんが、「見通すことができた」という実感が湧いた瞬間でした。

※発信する媒体やコンテキストによって「テストケース」の表現を変えることはあります

テスト技法についての自分なりの理解を深める

「テストケース」を中心にテスト設計プロセスを捉え直すと、「テスト技法」についての理解が深まりました。

当初、「なんとなくルールにしたがって図を書いたり表を書いたりする」程度の理解をしていましたが、「テストケースを作るためにテスト設計は存在する」と考えると、様々なものが私の中で繋がりました。

「テストのスコープと網羅性を定義するための合理的な手法が存在し、それらを満たすテストケースを導出するものがテスト技法である」という理解をしました。

自分なりの理解をすることで、単に「それっぽい図を書く」ではなく、「目的意識を持って必要なテスト技法を使う」という、テスト技法の活用に対する主体性を手に入れることができたのです。

テスト対象の特性を理解する

テスト設計する際には、「テストすべきこと」を考えることが必須となります。ちなみに、「テストすべきこと」はテスト観点、テスト条件、テスト要件など、現場によってさまざまな表現がされます。

これらはブレインストーミングとしてアドホックに導出することは有効ではありますが、様々な特性や手法を意識して導出することもひとつの方法だと考えています。

この中で重要だと考えているのは「テスト対象の特性を理解する」ということです。

テスト対象の特性としては、アーキテクチャスタイル/パターンや入出力の特徴や取り扱うデータの性質などが挙げられます。

これらの特性はテスト設計の方針やテストケースの形にも影響を与えます。

テスト対象の特性を踏まえた上でどのようなバグが発生しうるか、などはテスト設計の際に必ず考えておきたい点です。

専門性の組み合わせ

本連載のテーマのひとつである「専門性の組み合わせ」について、今回は「テスト設計」を軸に、テストエンジニアの基本的なタスクである「テスト実行」との関連を解説します。

続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。

SHARE

  • facebook
  • twitter

SQRIPTER

山下 友輔(やました ゆうすけ)

記事一覧

ソフトウェアテストに専門性を持つ、大阪在住のバキバキQAエンジニア。なによりDirty Testerでもある。
2018年に第三者検証会社に第二新卒として入社後、派遣テスターとして業務をこなしつつTPIというテストプロセス改善技術について学ぶ。
現在はWeb系SaaS企業のQAエンジニアとして、パーフェクトQAパーフェクトスタイルを模索している。

JSTQB TA/TM/TAE

プロフィール画像は妻が描いてくれた。

RANKINGアクセスランキング
#TAGS人気のタグ
  • 新規登録/ログイン
  • 株式会社AGEST
NEWS最新のニュース

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST