私が何かを開発した時、それが新規機能であれバグ修正であれ、ステージング環境と本番環境で手動テストを行っています。自動テストだけでテストが完了すれば楽なのですが、現実は自動テストだけではカバーしきれないので、手動テストも合わせて行っています。
ただ、テスト時にチーム内で何も事前合意がなく行きあたりばったりだと、テスト自体の妥当性に加えて様々なコミュニケーション上の問題が発生してしまいます。
そのような事態を防ぐために、私は次の5W1Hを意識してテストを作成するようにしています。
Why: なぜ手動テストをするのか
なぜテストをするのかは自明ですが、「自動」テストではなく「手動」テストをしなければいけない理由は何でしょうか？私の経験だと以下のようなものがあります。
１．実装内容が受け入れ基準に沿っているかを確認するため
自動テストが全てパスしようが、そもそも開発したものが受け入れ基準に適合しなかったら本末転倒です。そういった意味では、新規機能開発においては、PdMや機能をリクエストしたビジネス側での手動テストは常に必要になってきます。
２．リグレッション防止
自分の怠慢であることも多々ありますが、新しくリリースしようとしている機能や既存機能で自動テストのカバレッジが不十分なため、手動テストを行わなければならないケースはあります。自動テストを書いているとリリース期限に間に合わない、という場合も同様です。
また、似たようなケースで、自動テストではテストしにくい機能というのも一定割合発生します。特に、SPAやマイクロサービスの組み合わせなどで、マイクロサービスからデータを取得するタイミングとテスト実行のタイミングが合わなくテストが頻繁にFailしてしまう場合は、やむなく手動テストに切り替えます。
いずれの場合も、手動テストをするのは一時的な暫定措置として捉え、解決方法が見つかるなどのタイミングで自動テストで置き換えるようにしています。
3. 本番データで自動テスト出来ないから
これは本番環境での手動テストにのみ当てはまりますが、テスト用のデータよりも本番データの方が様々なバリエーションがあり、自動テストでパスしても本番の同じ箇所でエラーが起こることがあるからです。特に計算系の機能ではそのようなことが起きやすいため、本番環境リリース後の手動テストを行なうようにしています。
Who: 誰が手動テストをするのか
誰が手動テストをするのかという点は、以外と曖昧になりがちです。例えば、私が参加していた過去のプロジェクトで、ステージング環境でのテスト用に新機能のブランチを上げたが、テスト担当者が明確でないため誰もテストしてくれず放置された、ということがありました。また、本番リリースの日になっても誰が本番確認をするのかが明確でない、ということもありました。
こういうコミュニケーションミスを防ぐため、事前にテスト担当者名をタスクに記載するようにしています。ステージング環境と本番環境ともに同じ人が担当することが多いですが、違う場合は以下の例のようにそれぞれ記載するようにしています。
例：ステージング環境テストはプロジェクトマネージャの〜さんが担当するが、本番環境テストはプロジェクトマネージャーの〜さんに加えて経理の〜部長がテストする。
私がこれまで経験した中だと、テスト担当者としては、テストエンジニア、PM/PdM、その機能をリクエストしたビジネス部門の担当者が多かったですが、中には外部のクライアントにステージングで事前確認してもらう、というケースもありました。
What: 何を手動テストするのか
私の場合、そのタスクの受け入れ基準をベースにして手動テストシナリオを作っています。つまり、手動テストを一通り行えば、仕様通りに実装されているかどうかを判断出来るようにしています。そうすることで、受け入れ基準のチェックとテストを別々に行なわなくても良くなります。
ただ、受け入れ基準だけだと大まか過ぎたり、正常系しか記載がなかったりするので、細かいパターンや条件分岐をカバーしきれないことがあります。そういった考慮漏れを防ぐために、コードを実際に書いたエンジニアにもテストに加筆すべきパターンがないかをチェックしてもらうようにしています。
また、そのタスクで新しく開発した機能に加え、副作用が懸念される既存の機能についてもテストシナリオに加えることが多いです。ここは主に自動テストでカバーする領域ですが、新機能リリース時には念のためにテストすることは多いです。
関連して、そのアプリケーションの最もクリティカルな部分は、副作用の懸念がそれほどなくても念のためテストするようにしています。例えばECサイトならチェックアウト機能、ブログプラットフォームなら記事投稿機能、といった具体です。
Where: どこで手動テストをするのか
どこで、というのはウェブ系のアプリケーションだと、そのアプリケーションのステージング環境URLや本番環境URL、となりシンプルな場合が多いです。ただ、複数ステージング環境がある場合は明確にしておかないとテスト担当者がわからなくなってしまいますので、タスクのコメント欄などで特定のステージング環境を指定してテストを依頼するようにしています。
一方、現場で使うデバイス用のソフトなどだと、実機がある場所でテストを行なう必要があるので、どこでテストを行なうのか、という点を明確にする必要があります。
例えば、POS用のソフトウェアなら、テスト端末があるオフィスで行なうのか、はたまた実際に使う現場でテストしてみるのか、といった点も事前に関係者で合意しておき、タスクに記載するようにします。
When: いつ手動テストをするのか
ステージング環境でいつテストを行なう予定なのかを明確にしておかないと、様々な弊害が発生します。
一つは、本番リリース期日から余裕を持って逆算しておかないと、ステージング環境テストのフィードバックを受けて修正が必要になったが、開発に十分な時間が取れなくて本番リリースを遅らせなくてはならない、といった事態になってしまうということです。
また、たとえリリース日まで余裕を持って開発を行ったとしても、明確なテスト期日を合意していないと、いつまでもステージング環境が空かず、他のタスクがテスト待ちで滞留してしまう、といった弊害も発生します。
こういった事態を防ぐため、ステージングでのテスト期日は必ずタスクに記載するように心がけています。
また、同様に本番リリース日についてもわかり次第タスクに記載するようにしています。タスクは基本的に開発・テストが終わり次第早めにリリースするようにしているので、本番リリース期日とは別のタスク項目を設けています。こうすることで、その日にリリースするタスクについてチーム内で認識の齟齬が起きないようしています。
How: 手動テストをどのように記載するのか
テストの書き方はチームやアプリケーションの性質によって千差万別かと思いますが、私が手動テストケースを作るときは、なるべく自動テストと一緒のフォーマットにするようにしています。 具体的には、1)前提条件、2)操作手順、3)想定結果の３つで構成するようにしています。そうすることで、後で自動テストに書き換える時にそのまま使えるからです。
簡単なタスクならタスクチケットの概要欄にそのまま書き込むこともありますが、何個もテストケースがある中規模以上のタスクの場合は、以下の例のようにスプレッドシートで管理しています。
| ストーリー | 分類 | 前提・手順 | ステージング環境結果 | 本番環境結果 |
| ブログ記事公開 | 前提 | 作成済み未公開記事が存在すること。 | ||
| 操作手順 | 1. 管理画面メニューから記事一覧をクリック。 2. 該当記事の公開ボタンをクリック。 | |||
| 想定結果 | 記事が公開されること。 | Pass | Fail |
まとめ
私が手動テストを作成するときに意識していることを紹介してみましたが、いかがでしたでしょうか。
個人的には5W1Hを明確にするよう心がけることでチーム内のコミュニケーションも円滑になり、テストケースでの考慮漏れも少なくなっていると感じていますので、もし参考になるようでしたらぜひご自身の開発工程に取り入れてみてください。