こんにちは！ テストエンジニアのマツキョーです。
第三者検証会社のテストエンジニアは、様々なプロジェクトに途中から参画することが多くあります。プロジェクトに参画したテストエンジニアは、まず仕様把握という作業から着手していきます。
仕様把握では、テスト対象となるシステムの要件や仕様が記述されたテストベースが必要になります。すでに開発が進んでいるプロジェクトでは、当然ながらテストベースの量も膨大になっています。そのためテストエンジニアは、膨大なテストベースを確認・理解してテスト設計をする必要があります。
ですが、純粋にテストベースの確認と理解だけに使える時間は限られています。
プロジェクトの体制にもよりますが、多くの場合はキャッチアップ期間として1日～数日、それ以降はテスト分析・設計作業と並行して仕様把握を進めていきます。何も知らないところから、膨大なテストベースを短期間で読み解いて仕様を理解し、品質を担保するために最適なテスト設計を行うのです。
やりがいのある仕事ではありますが、テストエンジニアも人間なので当然プレッシャーが掛かります。むしろ、品質のプロだからこそ感じる不安がプレッシャーの原因と言えるかもしれませんね。
品質保証の業務に従事して10年以上経つ私でも、プロジェクトに参画して仕様把握を始める時は不安を感じます。
この記事では、仕様把握という作業について再認識するところから始め、テストエンジニアの正直な内心にフォーカスしたのち、それを克服して効果的な仕様把握を行うためのコツを紹介したいと思います。
日々品質の守護者として戦うテストエンジニアたちが、不安やプレッシャーに打ち勝ち、より良い品質のために行動する助けになれば幸いです。
仕様把握とは？
仕様把握とは、言葉のとおり仕様を把握していく作業です。
テストプロセスにおけるテスト分析の作業の1つで、テスト設計の情報源であるテストベースを読み解いて理解していきます。
文字に起こすと簡単そうですが、重要なのは「理解する」の部分にあります。この「理解する」という作業は、ドキュメントに書かれた内容を覚えるだけの作業ではありません。
- 仕様として明記されていない情報がないか？
- ユーザーの利用シーンはどのような状況か？
- 他の機能や外部システムとの連携はあるか？
このような問いを自分の中に持ち、想像力を膨らませながらテストベースを読み解いていく必要があります。なぜなら、テストベースに書かれていない部分に多くの欠陥が潜んでいる と考えられるからです。
そうして読み解いた内容からテスト設計に必要な情報を選別していき、テスト分析という工程を通じて「何をテストするか？」であるテスト条件を定義していきます。
品質を担保するために必要な情報を得るため、適切な広さ・深さで仕様を熟知していく作業 がテストエンジニアにとっての仕様把握です。
テストエンジニアの内心
プロジェクトに参画したテストエンジニアが、最初に取り掛かる作業が仕様把握です。仕様把握は、膨大なテストベースを読み解いてテスト対象への理解を深めていく作業です。
私たちはプロなので、お客様のご都合に合わせた期間で必要な情報を集め、理解し、テスト設計に活用して品質に貢献します。だからこそ、テストエンジニアは仕様把握を行うときに以下のような不安を感じます。
- 効率の良い順番でテストベースに手をつけられるだろうか？
- テストベースの内容をスムーズに理解できるだろうか？
- テスト設計に必要な情報を期日までに収集できるだろうか？
この不安の裏には、品質のプロとして 「テスト対象を深く理解してテストを設計し、高品質の実現に貢献したい」 という想いがあります。その想いが自身にプレッシャーという形で降りかかってくるのです。
プレッシャーというとデメリットのように捉えがちですが、テストエンジニアにとってはデメリットだけではありません。このプレッシャーに打ち勝つために、知識を身につけ、技術を磨き、創意工夫することで、私たちは成長していくからです。
仕様把握のコツ５選
仕様把握のコツを紹介する前に、まず 仕様把握 という作業を分解してみます。
仕様把握は、インプット、アウトプット、コミュニケーション という3つの要素に分けられると考えています。
- インプット … テストベースから情報を集めること
- アウトプット … インプットした情報を理解して整理し可視化すること
- コミュニケーション … 会話により情報への理解を深めたり共通認識を作ること
この3つの要素を繰り返し行うことで、テスト対象の仕様理解が進み、テスト設計に必要な情報が明らかになっていきます。
これら3つの要素を前提に、私が仕様把握をするときに大事にしているコツを紹介します。
1. ステークホルダーと密にコミュニケーションをとる
ステークホルダーとは「プロジェクトに関わる利害関係者」のことです。開発エンジニア、プロジェクトマネージャー、デザイナーなど、そのシステムの開発プロジェクトに関わる人たちを指します。私たちテストエンジニアもステークホルダーの1人です。
仕様把握を効果的に行うには、テストの目的、品質の目標、QA方針といったプロジェクト毎に存在する 決まり事 を知っておく必要があります。また、仕様把握やテスト設計を進める中で、疑問や不明点は必ず出てきます。
これらの 決まり事 を確認したり、疑問や不明点を解消するための、唯一の方法が 他のステークホルダーとのコミュニケーション です。私たちはコミュニケーションを通じて、情報の共有・質問・相談を重ねることで、仕様に対する理解を深め、曖昧さや抜け漏れを解消し、共通認識を作っていくことができます。
この後も仕様把握のコツを紹介していきますが、仕様把握において コミュニケーションを密にとる ということが最も重要なコツであることを、まずお伝えしておきます。
2. 主軸とするテストベースを決める
仕様把握はテストベースを読み解く作業ですが、手当たり次第にドキュメントを読み漁ればいいわけではありません。限られた時間の中で必要な情報を効率よく集めるためには、木の幹となるテストベースを決めておくことが重要です。
V字モデルを例に考えた場合、受入テストは「システムが要求を満たしているかを確認するテスト」なので 要求分析の結果 、システムテストは「システムが要件を満たしているかを確認するテスト」なので 要件定義 を主軸のテストベースとするのが一般的です。
このように、テストの目的に合わせて最適なテストベースを主軸に据えることで、確認するテストベースの優先順位を決めたり、どの程度の理解度が必要かの判断ができるようになります。
注意点として、受入テストやシステムテストといった用語は、組織やプロジェクトによって意味合いが異なる場合があります。なので、ここでもステークホルダーとのコミュニケーションで共通認識を作っておくことが重要になります。
3. 全体を俯瞰できるテストベースから着手する
主軸のテストベースが決まったら、早速そのテストベースから仕様把握を進めたくなりますよね。でも、焦ってはいけません。仕様を効率的に理解するには、どのようなテストベースから確認していくかも重要になります。
では何から着手するのが良いかというと、オススメは画面遷移図やDFD（データフローダイアグラム）といった システム全体を俯瞰して見ることができるテストベース です。
システムの全体像が見えていると、上から下、大から小といった流れでシステムの理解を進められます。このような流れで仕様把握することには、その画面や機能がシステム全体の中でどのような役割を持っているか、ユーザーがどのようにして利用するかといった部分の理解がしやすくなるというメリットがあります。
テストエンジニアは、テストベースに明記された仕様だけでなく 暗黙の仕様 にも配慮します。暗黙の仕様 とは、ドキュメントに明記されていない隠れた仕様のことです。
システム全体を理解することは、その画面や機能が果たす役割やユーザー視点での理解を助け、要件や仕様の抜け漏れ、隠れたユースケースといった 暗黙の仕様 の発見に繋がります。
システム全体を頭の中でイメージして、テスト対象の振る舞いをシミュレーションできるようになれば仕様把握の上級者です。
4. ドキュメントを読むだけでなく、アウトプットして整理する
仕様把握は、概ねがドキュメントを読む作業です。しかしドキュメントを読むだけで仕様を理解したとするのは、私の経験上おすすめできません。
私たちは、品質保証を目的としたテスト設計をするために仕様把握をしています。前項でも書いたように、ドキュメントに明記された仕様だけでなく暗黙の仕様にも配慮する必要があります。暗黙の仕様を見つけるためには、システム全体を理解しながら仕様把握を行うことが重要ですが、システム全体を頭の中だけで理解していくのは無謀な行いです。
効果的に仕様把握を進めるためには、理解したことをアウトプットして情報を整理していく ことが重要になります。アウトプットと言っても闇雲にメモすればいいわけではありません。ロジカルにアウトプットすることが仕様の理解を深める助けになります。
ロジカルシンキングという言葉を耳にしたことのある方は多いでしょう。ビジネススキルの定番とも言える思考法で、物事を論理的な繋がりで考えるスキルです。テストエンジニアにとっても優先的に身に着けたいスキルですね。
このロジカルシンキングには、基本的な概念とは別に、様々な思考を補助するツールや技術があります。詳しく書くと長くなってしまうので、ここでは概要と仕様把握におけるメリットに絞って、私がよく利用しているモノを紹介します。より詳しく知りたい方は、書籍やネットで調べてみてください。
ロジックツリー
ロジックツリーは、情報を特定のロジックでツリー状に分類して整理するツールです。仕様把握におけるメリットは、画面や機能をツリー構造で整理できることです。画面や機能の関係性が視覚化されてわかりやすくなります。
ですが、ロジックツリーだけでは暗黙の仕様を見つけるには少し足りません。暗黙の仕様を見つけるためには、暗黙の仕様を見つけるための 問い が必要だからです。この 問い を考える時に活用できるのが、次に紹介する2つのスキルです。
フレームワーク思考
フレームワーク思考は、情報をフレームにあてはめて分解・深堀りするためのスキルです。仕様把握におけるメリットは、仕様の抜け漏れを発見しやすくなることです。特定の基準で作った枠組み（フレーム）に仕様をあてはめながら整理するので、仕様に抜け漏れがあると枠が埋まらないため、すぐに気づけます。
例えば、時間に関する機能があれば「過去」「現在」「未来」というフレームを作り、テストベースの情報をそのフレームにあてはめて情報を整理します。最後まで空欄の枠があれば、仕様の考慮漏れや記述漏れの可能性がありますので、ステークホルダーに確認してみましょう。
仮説思考
仮説思考は、現時点の情報から可能性の高い仮説を立てて検証していくスキルです。仕様把握におけるメリットは、隠れた要件やユースケースを発見しやすくなることです。現時点の仕様から導き出した仮説から、明記されていない仕様について検討することで、隠れた要件やユースケースに気づくことができます。
例えば、ユーザーを管理する機能があるとしましょう。管理者が管理するユーザー数をシステム上の最大ユーザー数であると仮定した場合、性能要件がどうなっているか、検索機能や一括処理機能などのユーザビリティに配慮しているかといった疑問が浮かびます。テストベースからその疑問の答えが見つからない時は、隠れた要件やユースケースである可能性がありますので、ステークホルダーに確認してみましょう。
このようにツールやスキルを利用してアウトプットしながら仕様把握を進めることで、テストベースに書かれたことを理解するだけでなく、システムが実現したい本来の姿を明らかにできます。
今回紹介した以外にも、思考を整理したり、情報を分析するためのスキルやツールはたくさんありますので、ぜひ色々試して自分にあった武器を身に着けてください。
5. 自分ひとりで考えない
最後のコツは、誰かと一緒に考える ということです。
技術職の方には、自分ひとりで黙々と作業するのが好きな方が多いのではないでしょうか。集中して作業することはとても良いことですが、ひとりで考えていると壁に当たった時になかなか抜け出せないこともあります。
システム開発には多くの人が関わっていますので、チームの同僚やステークホルダーと積極的に話してください。
自分の考えたことや気づいたことを、誰かに伝えることで共通認識ができたり、別の角度からの意見が貰えることもあります。また考えがまとまらないときには、誰かに話すことでスルっと思考が整理されたり、新たな気づきを得られる場合もあります。
人と話すことは、最も手軽で効果的なアウトプット です。チームメンバーやステークホルダーに自ら話しかけ、協力関係を育んで、より良いプロダクト品質のために行動しましょう。
さいごに
仕様把握が効果的に行えると、それに比例してテスト設計の品質も高まります。
テスト設計の品質は、高度な仕様把握に基づいたテスト分析によって作りこまれるからです。
今日もどこかのテストエンジニアが、未知のシステムを前に勇気を出して仕様把握の一歩を踏み出していることでしょう。私のこれまでの些細な経験から得られたコツが、少しでも彼らの一歩の助けになり、世の中のプロダクト品質に貢献できれば幸いです。
