KIYOラーニング株式会社の玉城です。
今年8月からQAチームにテスターとして異動しました。
テスターという名前の通り、自社サービスに新機能追加や改修があった際、リリース前にその機能をテストする役割を担っています。
テスターを初めて感じたこと
基本的に、テスト項目はQAエンジニア（他の担当者）が作成したテストケースに記載されたテスト仕様書をもとに実施します。
そのため、機能の仕様決定に関する打ち合わせなどには参加しておらず、仕様書の内容を読み取ってテストを進めていく必要があります。
その結果、QAエンジニアとテスターの間で認識や情報の齟齬が発生してしまうことがあります。
以下は、実際に私がテストに携わって感じた点です。
1. テストケースが画面上のどの位置を指しているのか分かりづらい
テスト項目が、画面上のどの箇所を指しているのか分からないケースがあります。
例えば「タイトルAという項目が正しく表示されているか」というテストがあった場合、対象画面を見て「タイトルA」という文字が表示されていれば問題ないと判断しがちです。ただし、これは画面上に「タイトルA」が一箇所しか存在しない場合に限ります。
画面によっては、同じ名称の項目が複数存在することも珍しくありません。その場合、どの「タイトルA」を指しているのかを、テスターは仕様書と画面を見比べながら判断しなければなりません。
多くの場合は、前提条件やテスト内容、周辺要素から推測できるため大きな支障にはなりません。しかし、どうしてもテスト項目が画面上のどこを指しているのか分からないケースが、時折発生します。
2. テスト内容の順番による手間
テストを行う際、担当機能のテストケースを上から順に確認していくことが一般的だと思います。その際、画面や機能ごとにテスト項目がまとめられている場合が多いです。
機能が単純であれば問題ありませんが、他機能や他画面と連携する場合、非常に手間がかかることがあります。
例えば、機能A・B・Cがあり、Cのテストを行うとします。Cのテストケースの中で、事前にAやBで特定のデータを入力・選択しておく必要がある場合、一度別画面に移動してデータを用意します。
その後、「AとBのデータが存在しない状態」でのテストケースが出てきたため、再びデータを削除します。しかし、さらに進むと、またAとBの事前データが必要なテストケースが現れ、再度データを作成する……といった具合です。
画面ごとにテストが整理されている点は分かりやすい反面、準備に手間のかかる前提条件が複数の機能にまたがると、作業時間が大きく延びてしまいます。
もちろん、テスト開始前にテスター側で前提条件を整理・ソートしておけば防げる場合もあります。ただし、前提条件の書き方によっては判別が難しく、注意していても抜け漏れが発生してしまうことがあります。
3. テスト仕様書のレイアウト
これはおそらく最適解が存在しない、永遠の課題だと思います。
多くのテスト仕様書は、「テスト番号」「画面名」「機能名」「前提条件」「手順」「結果」「担当者」「備考」など、少なくとも4〜5項目以上が横一列に並ぶ構成になっている印象があります。そして、その行が大量に続きます。
実際にテストをしていると、特に横に長い仕様書は非常に見づらく、画面に収まりきらないため、横スクロールしながら「画面」「機能」「条件」が正しいかを毎回確認する必要があります。これに時間を取られてしまいます。
さらに、レイアウト画面の画像が仕様書の冒頭に配置されている場合などは、行き来が増えてより大変です。
とはいえ、テスト仕様書は設計書でもあるため、情報が詳細であること自体は間違いなく重要です。ただし、情報量が多すぎると確認しづらくなるというジレンマも感じています。
作成者とテスターの視点の違い
以上、大きく3つの問題点を挙げました。
3については作成者の問題というより構造的な課題ですが、1と2については、仕様書の作成者とテスターの立場・感覚の違いが影響していると感じています。
作成者は要件定義や仕様レビューに参加しており、テスターよりもその機能について詳しい状態です。そのため、「これくらいは見れば分かるだろう」という前提が無意識に入り、前提条件や手順の記載が不足してしまうことがあります。
作成者視点では分かる内容でも、第三者が見ると把握しづらいことは意外と多いと感じます。
もちろん、テスト開始前に要件説明や注意事項を共有するミーティングが設けられている場合もあると思います。しかし、機能が大きく複雑になるほど、一度にすべてを理解するのは難しく、見落としも発生しやすくなります。
第三者にテストを依頼する前提であれば、少しだけ時間をかけて仕様書の粒度を上げることで、確認や質問の時間が減り、結果的に全体の工数削減につながるかもしれません。
おわりに
3については正解がなく、まさに永遠の課題だと思います。以前勤めていた会社では、テスト仕様書をExcelで印刷し、分厚い紙の束をめくりながらテストをしていたこともありました。
それはそれで「一度に全体を見渡せる」「画面レイアウトと並べて確認できる」というメリットはありましたが、紙の消費量や作業時間、最終的にWebへ転記する手間を考えると、決して効率的とは言えませんでした。
ここまで述べた内容は、あくまで一テスターとしての個人的な見解です。現在ではテスト仕様書を作成・管理できるサービスも多数存在し、私が挙げたような問題はすでに解決・改善されているのかもしれません。
それでも素人目線で言わせてもらうなら、必要な情報を適切に取得し、画面上に分かりやすい画像と紐づけてテストできる仕組みがあればうれしいな、と思っています（すでに存在しているかもしれませんが）。
例えば、こんなイメージです。
以上、一人のテスターからの少し愚痴めいた記事でしたが、最後まで読んでいただきありがとうございました。
KIYOラーニング株式会社について
当社のビジョンは『世界一「学びやすく、分かりやすく、続けやすい」学習手段を提供する』ことです。革新的な教育サービスを作り成長させていく事で、オンライン教育分野でナンバーワンの存在となり、世界に展開していくことを目指しています。
プロダクト
- スタディング：「学びやすく・わかりやすく・続けやすい」オンライン資格対策講座
- スタディングキャリア：資格取得者の仕事探しやキャリア形成を支援する転職サービス
- AirCourse：受け放題の動画研修がついたeラーニングシステム（LMS）
KIYOラーニング株式会社では一緒に働く仲間を募集しています