理想と現実で考えるシステムテスト

こんばんは。かいりです。
今回は先日あったJaSST nano vol.16にて発表したテストメソッドについてまとめてみようと思います。
どうぞよろしくお願いします。

As-Is To-Beテストメソッド（仮）

名前がまだいまいち定まっていません笑　いい名称募集中です。

As-Is To-Beは元々ビジネスで使われる用語で、「理想を定め、現実をそれと比較することで課題を見つけることができる」といったような課題発見のためのフレームワークです。私がテストの時に考えていることを言語化すると非常に近いものになるのでこの名称を使わせて頂いています。

このテストメソッドは2021年夏（QAになったタイミング）に一応自分で考えたテストメソッドになります。PM, UXの領域に足を突っ込んでいますが、そのぶん超上流からQAに入ることができるのが特徴です。

テストメソッドは5つの項目で構成されています。

1. ビジネス上の目的を明確にする

2. システムの理想の姿を定める

3. パターンを使って課題を予測する

4. 理想と現実の間に課題はある

5. 理想と現実で互いに歩み寄る

それぞれについて説明していきます。

1. ビジネス上の目的を明確にする

• 業務上のシステム作成は当然ながらビジネスなので、何のためのシステムなのか（＝誰にとっての価値なのか）が明確になっていないと後々困ることになる

• 仕様が曖昧なのは仕方がないが、ここが曖昧なのはNG

次項の「システムの理想の姿を定める」ためにも、このフェーズは重要です。ユーザーから「このようなものが欲しい」と指定されることは多いと思いますが、それをその通りに作ることが必ずしも正解ではないということは、経験のある方もいるのではないでしょうか。

設計書の段階で細かいところは実装しながら詰めていくというのはよくあることだと思いますが、根本的な目的が曖昧なのはNGだと私は考えています。
「どんなものが欲しいか」ではなく、「どんな課題があるのか」「それを使って何をしたいのか」を明確にしておきます。そうすれば自ずと「どんなものを作ればいいか」は明らかになってくるはずです。

2. システムの理想の姿を定める

• ビジネス上の課題/目的と、考えうるユーザーストーリーから理想のシステムを定義する

• その際には他社の類似システムも参照する

• 仕様書がすでにあったとしても、それが目的に沿っていないことは珍しくない

• この時、ユーザーは純粋なユーザーだけでなく、全てのステークホルダーを意識する

ここが私にとっては一番大切なフェーズです。
前項で述べたビジネス上の課題や目的を明確にすれば、システムの理想の姿の大枠は定まると思います。そこからが腕の見せ所だと思っていて、ここからいかに「顧客が本当に必要だったもの」（有名なネットミームなので知らない方は検索してみてください）の解像度を上げていくことができるかが重要と考えています。そのためには他社製品情報含めありとあらゆる情報を収集する必要があります。

これはプロダクトマネージャーの業務だと言う方もいるかもしれませんが、プロダクトマネージャーの方の言うことが必ずしも正しいとは限りません。（プロダクトマネージャーの方、ごめんなさい💦）
誰かの言われた通りに作業するのではなくて、自分なりの理想の姿を頭の中に描いておくということが、テストをするにあたっても大切なことだと私は思っています。テストに限ったことではないかもしれませんが…。

また、理想を描く時には、純粋なユーザーだけでなく、システムに関わる全てのステークホルダーを意識するようにしています。システムに関わるのは作る人、使う人以外にも色々な人がいます。例としてはカスタマーサポート、ユーザーの情報を分析するアナリストなどが挙げられると思います。そういった人たちのため必要な情報がきちんと整っていることも、理想の一つとして数えます。

3. パターンを使って課題を予測する

• 理想の姿を求める時に異常系の確認が漏れる場合が多いので課題に焦点を当てて予想する

• よくある課題はすでにある程度パターンがある（ex. エラーハンドリング、セキュリティ）

• 自社事例（バグチケット）や社会的に問題になったバグ事例なども活用する

「こうであるといいな」を追い求めていると、どうしても正常系に偏りがちになりますので、この辺りで異常系にも焦点を当てておきます。

上にも書いた通り、エラーハンドリングやセキュリティの問題、ログの欠損などよくある課題（バグ）には既にパターンがあることが多いです。また、過去にこんなバグが起きたという自社事例や、社会的に問題になったバグも参考にすることができます。

JaSST nanoの際にTwitterでも言われていましたが、エラー推測ですね、これ。

4. 理想と現実の間に課題はある

• テスト工程（仕様書含む）

• 理想を頭に入れた状態でユーザーストーリーに沿ってチェックし問題がないか確認する

• 理想と現実を比較すると、対応すべき課題が見えてくる

ここからが実際のテスト工程になります。といってもここでのテストというのはシステムテストのことではなく、仕様書やデザインなどシステムにまつわる全てに対するテストのことを指しています。

この時点で理想は頭に入っています。そうしたらあとはそれに沿ってチェックしていくだけです。画面はこんな感じになっているはずだ、こんな動きをユーザーはするはずだ、そう思いながら一つ一つ確認していきます。そうすれば、大抵の場合は一つや二つ想像と違う部分が出てきます。（統計は取っていませんが経験則です）

5. 理想と現実で互いに歩み寄る

• 課題をトリアージする

• 課題には「絶対に対応しなければならないもの」と「そうでないもの」の二種類がある

• 絶対に対応しなければならないものは社会的信用に関わる場合もあるので現実を理想に寄せる

• 全ての課題に対応していたら本来の目的を達成できない場合、理想を現実に寄せることも検討する（一部機能を切り落とすなど）

理想を全て叶えられればいいですが、全てが理想通りにいくとは限りません。絶対の納期があって、そこに間に合わなければビジネスとして成立しない場合は、現実のままいかなくてはならないこともあるでしょう。

それでも、たとえばそのままリリースした場合に社会的に問題になりかねないバグは「絶対に対応しなければならないもの」です。なので、エンジニア、プロダクトマネージャー、その他必要に応じて関係者を巻き込んで理想と現実の妥協点を探ります。間違っても理想を全て守るよう押し付けてはいけません。そのため、QAエンジニアにはコミュニケーション能力が問われると私は思っています。

終わりに

QAエンジニアとしてはまだまだ経験不足ではありますが、普段こんなことを考えながらテストをしているよということをまとめてみました。
これをもっとブラッシュアップしていきたいのでよろしければコメント等いただけると幸いです。

最後までお読み頂きありがとうございました。