ごあいさつ

はじめまして、増田と申します。

入社はずいぶん前になりますが、なんやかんやでお初になります。

　技術者ではないことから、逆にそれを生かして「ユーザー視点でアプリを評価できるのでは？」ということで、普段は社内で開発したアプリのテスト業務を担当しております。

テストの講座を受講しました

テストとは「これで完璧」というゴールがない業務ではありますが、少しでも品質や作業効率の向上につながればと、この度「テストの基本」の講座を受講する機会をいただきましたので、そこで教わった内容の一部をご紹介します。

行き当たりばったりのテストは不可能

講座のはじめに「バグとは仕様書の記載と異なる表示・動作のことである」という説明とともに仕様書とアプリを提示され、「制限時間内でできるだけ多くのバグを見つけてください」と言われました。

　スタートの合図と同時に仕様書の読み込みを開始しましたが、ろくにバグを見つけられないままタイムオーバーになってしまいました。
　行き当たりばったりでテストは不可能であり、テストケースの準備が不可欠ということが改めてよく分かりました。

定義することの重要性

さて、そのテストに欠かせないテストケースですが、「誰が実施しても同じ結果」になる必要があります。

　
特に、仕様書に「人によって解釈が異なりそうな記載」があった時は、具体的に何を指しているのかを確認した上で定義することが重要になります。

　たとえば仕様書に「きれいな花」と記載されているだけでは、「赤い大輪のバラ」を指しているのか、はたまた「ピカピカ光る電飾で装飾された花」を指しているのか分かりません。
具体的に何を指しているのかを定義することで、確認する内容が明確になります。

同様に、「良い」「悪い」「正しい」なども、判断する人により基準が異なるので、お客様の求める「良い」「悪い」「正しい」は何を指し、また判断する基準はどこにあるのかを確認して具体的な項目に落とし込むことで「誰が実施しても同じ結果」になり、テストする人に左右されないテスト結果につながります。
　言われてみれば、「〇〇が正しいこと」という確認項目をよく作っていたなと反省しきりです。

テストに必要な情報を全て洗い出す

お客様の要望を確認して定義したら、あとは操作手順と確認内容をテスト項目としてひたすら書き出すだけですが、この作業は想像力がとても必要です。
　誰が実行しても同じ結果にするためには、「使用するツールは何なのか」「環境の指定はあるのか」「操作する時間帯や曜日に指定はあるのか」などの細かな情報も欠かせません。
　想像力をフル回転させ、考え得る限りの情報や前提条件を考慮し、必要な情報を具体的に表記し、逆にテストする人を惑わすような不要な情報を排除する必要もあります。

そして、「こんな時にはこうなりそうだな」と思った時もまた定義が大切になります。
「こうなるはず」という思い込みで進めずに、お客様に期待されている結果は何なのかを確認した上で「この条件の時にはこうなる」という明確な項目に仕上げる事ができて、初めてテストケース作成のスタートラインに立てるのです。

偉そうに書いていますが、これらは全て講座で教わったことであり、増田はこのスタートラインに立てていませんでした。

今回、講座の受講を勧めてくださった先輩方に本当に感謝します。

受講を通して

自分にとっての「正しい」が誰にとっても「正しい」とは限らないという基本的な事に気づき、目から鱗が落ちる思いでした。

　また、テストの目的を「バグを一つ残らず見つけること」としてむやみやたらにテストしがちでしたが、お客様に求められている品質が何なのかを確認して、どこに対して重点的にリソースを割くのかを明確にすることも大切だと気づかされました。

テストというものが人に依存しやすいものであるという事を常に忘れず、明確なテストケースを作って、納品するアプリの品質向上に貢献していきたいです。