私は普段QAエンジニアとして仕事をしていますが、「テストはすべてまかせて！」といった働き方はしていません。これまでの経緯や組織構造などを踏まえ、開発者が主体となってテストをし、その相談に乗ったりサポートをしたりする形で仕事をしています。
本記事では開発者やビジネスサイドの方など、本職のテストエンジニアやQAエンジニア以外の方がテストケースを作成する際によく発生する問題や困りごと、そしてその解決方法のひとつとしてマインドマップを用いる方法について説明します。
なお、ここではテスト対象の操作手順や期待する結果などについて記したものをテストケースと呼ぶこととします。テストケースはテスト管理ツールやExcelファイルなどで作成・管理され、テストを行う際に参照されます。
組織によっては、テストケースの他にテスト項目、試験項目などさまざまな呼び名があります。
目次
テストを考えるときの悩みと、解決方法
開発者や開発チームのリーダーから、よく以下のような相談を受けます。
・自分が開発を担当した範囲についてテストケースを考えているが、これで十分なのか自信が持てない。
・メンバーが作成したテストケースをレビューしているが、しっくりきていない。
これらの悩みは、テストケースの作成過程の考え方や意図が説明できない・読み取れないために生じていると考えています。
テストを作った人が「なぜこのテストケースを確かめる必要があるのか」「なぜこのテストケース群で十分なのか」がうまく説明できない状態だと、テストケースをレビューする側のリーダーやマネージャーも意味のある指摘ができません。
このような状況を解決するには、どうすればよいのでしょうか。
■正攻法：ソフトウェアテストを学ぶ
正攻法として、テストエンジニアやQAエンジニアが身につけているようなソフトウェアテストの基礎を学び、身につけるという方法があります。
いちQAエンジニアとしても、開発者など他のロールの方がソフトウェアテストのスキルを身につけ、実践してくれることは理想的です。しかし私は、すべての開発者やビジネスサイドのメンバーにとって必須ではない、と考えています。開発等の本職のスキルに加えてソフトウェアテストもマスターしてください、と求めるのは酷です。
■簡単な方法：マインドマップを使う
そこで、テストエンジニアやQAエンジニアなどの本職ではない方がテストを考える際に使えるマインドマップ活用法をご紹介します。完璧とは言わないまでも、今よりよいテストを行うための方法として有効だと考えています。
ここで1点注意があります。けっして「マインドマップを使えばOK」や「マインドマップを使うことが大切」と言いたいわけではありません。大切なのは、何をテストしたいのか（対象や性質）と、それを示すためには何が言えればよいのかを段階的に考えることです。こうした思考過程が大事だという前提で、それを簡易的に実現するツールとしてマインドマップをオススメしています。
マインドマップを使ってテストを考える
実際にマインドマップを使ってテストを考えるやり方についてご紹介します。
ただ、ここでの説明はあくまでも一例で、厳密に「こうしなければならない」というやり方はありません。とくに、テストの専門家以外がテストを考えるときのやり方を改善するという今回の目的に対しては、マインドマップという道具を使って思考するだけで一定の効果があると考えています。この先の説明を参考に、「何をすればよいかまったくわからない」という状態を避けつつ、チームや個人ごとの工夫やアレンジは自由にやっていただいてかまいません。
ここからはHOTEL PLANISPHERE – テスト自動化練習サイトを対象として、テストを考えてみます。
1. 背景や前提情報を書き出す
最初にやるのは、テスト対象に関する背景や前提情報を書き出すことです。
たとえば、以下が挙げられます。
・テストを考える際のインプットとなるもの
・仕様書や設計書、テスト対象システムの現行バージョンなど
・開発プロジェクトや、テスト対象の概要
・ユーザーが何をできるのか、どのような価値を提供するのかなど
・テストのねらい
・新規開発部分のテストをしたい、リグレッションテストを整備したいなど
以下がマインドマップの例です。スペースの都合で簡素な記載になっていますが、もっと多くの情報が出てくることもあります。
これらの情報を書き出しておくことで、テストケースを考える際の前提が明らかになるため、レビューやテスト漏れの対応を行う際などに参考になります。
2. インプットに基づいてテスト内容を考える
続いて、インプットを元にテスト内容を考えていきます。
仕様書などがある場合は、仕様書の見出しごとにマインドマップのブランチを作成するのも一つの手です。もしドキュメントがなかったり、簡素なものの場合は、機能や画面などの単位でブランチを作ると書き始めやすいです。
今回は例として、「機能」というメインブランチを作成し、その下に個別の機能についてのテストを考えています。
たとえば「会員登録」という機能について、登録情報を入力するフォームのテストを考えている途中のマインドマップです。
仕様書等があれば、まずは仕様書に書いてあることを拾って書いていきます。こうすることで、最終的なテストケースで「仕様書に書いてあるとおりの動作をすること」は担保できます。
しかし、テストとしてはこれでは不十分です。仕様書というのは、基本的にすべてが詳細に記載されているわけではありません。仕様や要求に漏れがある場合もありますし、仕様書を書いた人にとって当たり前すぎて明文化されない部分が含まれることもあります。
こうした、「仕様書に書いていないことは何か」という視点でもテストエンジニアはテストを考えることがあり、他のロールの方にもぜひやってみていただきたいポイントです。
また、マインドマップでテストすべきポイントを挙げていく過程でもう1点、異常系についても意識してみてください。正常系の動作は思いつきやすいので漏れも少ないですが、異常系や例外的な動作をする場合のテストは漏れがちです。上記のマインドマップ例でも、あえて「正常系」「異常系」というブランチを作って、異常系を考えるきっかけにしています。
その他、テストを考える過程で気付いたことや、「仕様書に書いていないけどこういう場合はどうなる？」といった内容もメモをしておきます。「？」マークをつけたり、独立した「気付いたこと・メモ」というブランチを作るのも有効です。
ある程度テストすべきことをマインドマップ上に展開できたら、次に整理を行います。マインドマップは思考の発散に向いたツールなので、ただ書き出しただけでは扱いにくい状態です。
・類似の項目をまとめる
・順番や親子関係を変える
などを行いながら、テストを整理します。テストを考えるのと並行して整理ができる人もいれば、一度書き出したものを整理する人もいます。これは自分に合った方法を選択しましょう。
3. テストケースとして書き起こす
マインドマップを使ってテストすべきことが書き出せたら、あとは普段テストケースを記載するために用いているツールで書き起こします。Excelや、テスト管理ツールなどが該当します。
テストケースとして書き起こす、つまり個々のテストの手順や期待結果などを記載していく過程で、マインドマップを書いている際には思いつかなかったテストが浮かんでくる場合もあります。
その場合は、マインドマップ上にも反映しつつ、テストケースを書いていきましょう。
このようなマインドマップ→テストケース時の発想が得られることもまた、この方法のメリットです。
いきなりテストケースを書くのではなく、思考過程を経ることが大切
今回は、マインドマップを用いて「テストすべきこと」を考える方法についてご紹介しました。
本記事は概要レベルの説明なので、実際にやってみていただくと「どう書けばいいんだろう」や「これでいいのかな？」と迷うこともあるかと思います。もしマインドマップが使いにくい場合は、別のツールや手法でもかまいません。大切なのは、仕様書や設計書などからいきなりテストケースを書き起こすのではなく、一度それらのインプットを元に思考してテストケースを作成することです。
テストエンジニア以外の職種の方がテストを考える際に「なんだかうまくいかないな」と感じた場合は、ぜひマインドマップを使って考えることを試してみてください。
（文：伊藤由貴）
