こんにちは！ テストエンジニアのマツキョーです。みなさん読書はお好きですか？
最近はもっぱら実用書ばかり読んでいますが、たまに小説を読むと文章の楽しさを再確認します。小説の楽しさは様々ですが、私は文章の行間に隠された登場人物の行動や感情を読み解くことに楽しさを感じます。なぜなら、文章の行間には著者が読者に気づいてもらいたいことがあると思うからです。それに、もしかしたら著者も意図していない気づきだってあるかもしれません。
人間が書く文章には、意図している、していないにかかわらず、行間が生まれてしまうものだと思います。私たちテストエンジニアにもなじみ深い開発ドキュメントも例外ではありません。そして開発ドキュメントの行間には、隠された仕様……「暗黙の仕様」が眠っている可能性があります。
「暗黙の仕様」とは、開発ドキュメントに記述されていない仕様のことです。この「暗黙の仕様」は、仕様に書かれていないため開発段階で考慮されないリスクがあります。考慮されていなければ当然ながら実装から漏れることになり欠陥が混入することになります。
QAでは、このようなドキュメント上の欠陥を検出するプロセスとしてレビューなどの静的テストを行います。JSTQB FoundationLevel シラバスでも、シフトレフトアプローチとして以下のように記述されています。
テストをする観点から仕様書をレビューする。このような仕様書のレビュー活動では、曖昧さ、不完全さ、矛盾など、潜在的な欠陥を発見することが多い。
JSTQB-SyllabusFoundation_VersionV40.J01 > 2.1.5 シフトレフトアプローチ
この記事ではドキュメントの行間を読み解いて「暗黙の仕様」を明らかにするためのアプローチを5つ紹介します。
ドキュメントの行間を読み解くとは？
ドキュメントの行間とは？
テスト設計をするとき、仕様ドキュメントに書いてあることをコピペすればテスト項目書が完成するわけではありません。なぜなら、ドキュメントに書かれていることが仕様のすべてではないからです。ドキュメントに書かれていなくても、存在するはずの状況や条件があります。たとえば、「～になると活性する」という仕様記述があれば、当然「非活性」の状態も存在するはずですよね。このような明記されていないけれども存在する仕様が開発ドキュメントの行間です。
行間を読み解くとは？
ドキュメントの行間には様々なパターンが存在します。以下はドキュメントの行間の一例です。
・仕様記述にない条件・状況・パターン
・複数のドキュメントの隙間にある観点
・テスト対象のシステムとその動作環境との相互作用
このようなドキュメントに明記されていない情報を見つけだしていくことが行間を読み解くということです。
ドキュメントの行間を読み解くにはどうするか？
行間を読み解くのに必要不可欠な能力として想像力があります。想像力により文字から実際の動作をイメージすることで隠れた仕様である「暗黙の仕様」を見つけ出します。しかし文字から動作をイメージするというのは意外と難しいものです。想像力を補って動作のイメージを助けたりヒラメキを得やすくして「暗黙の仕様」を見つけだす可能性を高めるためには工夫が必要です。
ここからは、実際に私も使用している行間を読み解くためのアプローチを紹介します。
ドキュメントの行間を読み解くアプローチ５選
図表を作って可視化する
ドキュメントの行間を探すには、頭の中ではなく目で見える状態にするのが効果的です。情報を目に見えるかたちで表現することで、曖昧さや抜け漏れが見つけやすくなります。ロジックツリー、マインドマップ、ダイアグラムなどの手法を使うと、情報が整理されてより行間を見つけやすくなると思います。それぞれの手法については、詳しく紹介しているWebサイトなどを参照してください。
思考法を活用する
フレームワーク思考、仮説思考などの思考法はビジネスパーソンにとって必修科目となりつつあります。もちろんドキュメントを読み解く行為においても、思考を補助して素早い理解と疑問の洗い出しを可能とする思考法は効果的です。情報を可視化する手法と組み合わせることで、さらに大きな効果が期待できます。それぞれの思考法についても、詳しく紹介しているWebサイトなどを参照してください。
他者と会話する
テスト設計などでドキュメントを読み込むとき、1人で読む人が多いのではないでしょうか。1人で読んで完全に理解したと思った時でも、一度他者と会話してみることをオススメします。人間には主観や認知バイアスといった思考を縛る特性があります。完全に理解したと思ったドキュメントでも、他者と話したり質問されることで理解不足や新たな視点に気づくキッカケになることは多くあります。また、会話は最も手軽なアウトプット手段でもあります。チームメンバーと積極的にコミュニケーションすることでより深く正確にドキュメントを読み解くことができると思います。
実際に動かす
すでに動作するモックや類似システムがある場合は、実際に動かしてみることで理解が深まることがあります。感覚的にシステムを触ったあとで、ドキュメントを読み直すことで曖昧だった部分が鮮明に理解できたり、新しい発見を得られることも多くあります。
私がまだ駆け出しのころ、仕様ドキュメントからの情報のみでテスト設計をするべきだと思っていた時期がありました。もちろん仕様ドキュメントをベースとすることは重要ですが、理解するための補助という点では実際に動かす方が圧倒的に早く理解を深められます。ただし実際の動作を想定された仕様だと錯覚しないように注意が必要です。
時間を空ける
ドキュメントを長時間読み続けている時、一度ドキュメントを読むという行為から離れて少し時間を空けることも効果的です。見たり読んだりした情報は脳で処理されて理解に至りますが、情報によってはすぐに理解まで至らない場合があります。そんな時、さらに情報を詰め込んでいくのもいいですが、一度頭をクールダウンすることでいつのまにか頭の中の情報が整理できていたり、ふっと新鮮な発見が思い浮かんだりすることがあります。
さいごに
これらのドキュメントの行間を読み解くアプローチを活用すれば、様々な工程で課題を早期発見できる可能性が高まります。ドキュメントの行間に隠れた「暗黙の仕様」には、明記されていないという性質から欠陥が潜んでいる可能性が高いからです。そのためドキュメントの行間から「暗黙の仕様」を見つけ出すことは、QAエンジニアに求められるスキルの1つであると私は考えます。「暗黙の仕様」は多くの場合、予定している工数に含まれないため、読み解いた「暗黙の仕様」からテストを設計する時はステークホルダと相談して効果的に取り入れていきたいですね。また、要件や仕様レビューなどの上流工程であれば、ドキュメントの行間を読み解くことで課題の早期発見となり、大幅なリスク軽減とコスト削減が期待できます。今回紹介したアプローチを活用し、想像力を働かせて開発ドキュメントを読み解き、品質向上に貢献していただければと思います。
