この記事はLITALICO Engineers Advent Calendar 2024 カレンダー2 の 13日目の記事です
はじめに
テスト大好きQAエンジニアの @samegumiです。
こないだ開発チームの @k_oritaさんから「バグ見つけるのうまいね」って声かけて頂きました。
嬉しかったので、自分なりのバグを見つけるコツをまとめてみようと思います。
前提
本ブログは、web系システム開発のテスト工程に10年弱だけ関わった個人の所感をまとめたものです。
ドメインによっては、このブログに記載したコツが全く当てはまらないことも十分考えられます。ご了承ください。
私が意識している「枠組み」
バグは、そのほとんどがテスト工程で検出されます。
テスト工程にて私がテストをする時（テスト設計も含む）に、意識してる枠組みがいくつかあります。
- 表示
- 処理
- 遷移
- 環境
バグを見つけたい時は、上記に加えて、以下の枠組みも意識します。
- プロジェクトやチーム（特にメンバーひとりひとり）の状況
これらの枠組みと一緒に、バグを見つけるコツをご紹介しようと思います。
表示のバグを見つけるコツ
『無』に注目する
まずは0件やデータが無いことを見ます。
0件ってのは、
- データはあるんだけど検索結果0件
- 権限的に見せられない
データが無いってのは、
- 対象データが作成されてない
- 物理または論理削除等で削除された
- DBのテーブルカラム追加等で、カラム自体はあるんだけど、nullが入ってる
とか、そういう確認です。
想定されるデータ表示に関しては、デザインや仕様検討、実装段階でもきちんと考慮されているのですが、データが無い時の表示や挙動は少しだけ意識からもれやすいため、バグが生まれやすくなります。
ここで検出できるバグとしては、次のようなものがあります。
検索結果0件の時に、表示するメッセージやリンク（再検索への導線等）が無い
検索結果0件の時に、一覧のカラム部やデータ部のデザインが崩れる
前提となるデータが無い時、画面の一部または画面自体が表示できない
データが無い状態は、CSV出力やバッチ処理（大量メール送信）においても注意が必要です。メインテーブル側ではなくJOINしたサブテーブル側にデータが無いためにバッチがコケちゃった…等、影響度の高いバグを引き起こすこともあります。
『データの上限』に注目する
DBのテーブル定義書か項目を入力する画面から、データの上限を確認します。上限いっぱいまでテストデータを登録して表示を見ます。
文字列型なら、半角英数字や記号や絵文字をテストします。半角英数字は表組みのデザイン崩れを起こしやすく、絵文字はたまに文字化けます
ここで検出できるバグとしては、こんなのがあります。
表組みのレイアウト崩れ
半角英数字が、枠や画面を突き抜けて表示される
データが途中までしか表示されない（欠損 / 改行が考慮されず見えない 等を含む）
上限いっぱいのデータを登録しておくと、入力桁数のバリデーションチェックが効いてないとか、入力データを利用してる処理でコケてたりとか（処理の中でデータ上限を考慮できてない等）、表示以外のバグも見つけやすくなります。
テスト開始したら、入力項目で上限いっぱいデータを登録するのオススメです
処理のバグを見つけるコツ
CURDの『UとD』は念入りに確認する
CRUD（Create/Read/Update/Delete）とは、永続的なデータを取り扱うソフトウェアに要求される4つの基本機能である、データの作成(Create)、読み出し(Read)、更新(Update)、削除(Delete)の頭文字を繋げた語。
IT用語辞典 e-Words より
データを作る、読みだす、更新する、削除するの頭文字をとってCRUDです。
体感ですが「U：更新する」と「D：削除する」がトリガーとなってバグ発生することが多いなぁ…という印象をもってます。
複数のブラウザを起動し同じデータを開き、その後、同時もしくは少しだけ時間をずらして更新してみましょう。
削除したデータがユーザーを識別するIDやメールアドレスなどの場合、同じデータで再登録できるか確認しましょう。
検出できるバグとしては、以下のようなものです。
複数ブラウザから操作すると、更新できてはいけないものが上書きされてしまう
削除したはずのデータが再登録できない
遷移のバグを見つけるコツ
正常系・準正常系・異常系ごとに流れをみる
web系システムは、何かデータを入力し、それを処理して、結果を出力する、というのが基本です。これらの操作と処理に対応したさまざまな画面で、web系システムは構成されています。
ここでは、画面遷移に注目したバグを見つけるコツを書きます。
テストの世界には、正常系・準正常系・異常系という用語があります。
人や業界によって少し使い方に差があるものの、私の理解は以下（引用）です。
正常系テスト：予定しているお仕事を予定通りにこなせるかの確認
異常系テスト：想定外のことに対して、きちんと対処できるか確認
準正常系テスト：想定はしているけど予定していないことに対して、きちんと対処できるか確認
わわわIT用語辞典 >「正常系テスト」と「異常系テスト」と「準正常系テスト」の違い
画面遷移に当てはめると、正常系とは「入力画面でデータ入力後、登録ボタンを押下すると、一覧画面へ遷移し登録データを表示する」など、webシステムが想定してる操作および画面遷移のことです。
準正常系は、想定されてるエラー発生時にエラー画面へ遷移させること。
異常系は、サーバーダウンや回線不調など想定外の状況発生時にエラー画面へ遷移させることを指します。
正常系
正常系の遷移でバグを出すコツは、とにかく全部のボタンやリンクを押下することです。
全部です。
全部。
全部ですよ？
UI部品が多い辛い。けど頑張って。目標をセンターに入れてスイッチ！です！
検出できるバグとしては、以下があります。
ヘッダーのホームへ戻るアイコンや、パンくず等のリンク貼り忘れ
利用規約やプライバシーポリシーなどのリンク貼り忘れ
準正常系
準正常系の遷移は、基本的にはエラーとセットでテストします。
予約確定しようと申込画面開いたけど、予約確定の少し前に別な予約が入ってたとか。
データコピーしようとしたけど削除済だったとか。
有効期限が切れたコードを入力したとか。
そんな時は、「処理が完了できないと知らせるためのエラー画面」を出す必要があります。
エラー画面が表示できたら、第一段階クリアです。
次に、エラー画面のUI部品をさわります。ログインへ戻るとか困った時のお問い合わせはこちらリンクとか。
しかるべき画面やファイルへつながってるか確認しましょう。
逆に、ログインやホームに戻るなどの導線が無い場合もあります。
エラー画面表示中でも操作可能なメニューバーなどがない限り、エラー画面がでる＝ユーザーが袋小路にはまってしまいます。開発者さんやデザイナーさんに確認しましょう。
またエラー画面は一つでも、そのエラーに至る要因は複数あることが多いです。
要因 A / B / C でエラー画面を出す仕様の場合は、必ず要因３つ全てでテストします。
準正常系の画面遷移で検出できるバグとしては、以下があります。
エラー画面のUI部品のリンク切れ
エラー画面から復帰する手段がない（仕様バグ）
特定の要因の場合、想定したエラー画面へ遷移しない
異常系
異常系は、サーバーダウンや回線不調など想定外の状況での画面遷移を見ます。
サーバーダウンや回線不調などは、手動で発生させられない状況なので、開発者さんと協力してテストを考えましょう。
異常系の画面遷移は、そもそも手動でテストすることが難しいです。
テストでバグを出すというより「こういう状況ではこういうエラーにしよう」等、パターンと結果の整理を行い、可能な範囲でその通りに表示されることを確認するというアプローチがいいかなと思います。
画面遷移でのバグを見つけるためには、ユーザーがWebシステムをどのように利用してるのか？どんなことに困るのか？等への理解が必要になります。
LITALICOのQAでは「利用時の品質」を重視しており、ユーザーストーリー作成とテストへの活用などで、ここを高める工夫を行っています。
興味持たれた方は @az_h さんの 2023年アドベンドカレンダー記事もどうぞ！
環境由来のバグを見つけるコツ
開発者のlocal（実装）環境、development（開発）環境、staging（検証）環境、production（本番環境）。
web系システムをリリースするまで、プログラムはさまざまな環境で実行されます。
環境ごとにサーバースペックや設定、DBのデータ量が異なるため、可能な限りより多く環境でテストすることが唯一＆最大のコツです。
より多くの環境でテストしておくと
「この機能はlocal環境ではエラー発生し、staging環境では問題なく動いた。」
等の情報が取れるので、バグの原因の当たりがつけやすくなります。
検出できるバグとしては、こんなのがあります。
メールが送信されない
メールに含まれるURLの向き先が本番環境以外のまま（https://hogehoge-staging/）
一括処理系（データエクスポート）が動かない、途中でエラーになる
本番環境でのテストは、利用中のお客さまへの影響や個人情報の観点から、実施が難しい場合もあります。
しかし本番環境で何かあった場合、お客さま・自社全てに影響してしまうので、メンテナンスモードやリリース＆テスト時間帯を工夫する（深夜）などできるだけ工夫し、実施した方が良いと考えています。
プロジェクトやチームの状況からバグを見つけるコツ
忙しさは人の注意力を下げてしまう
Webシステムを考えるのも、設計するのも、実装するのも、人です。
人は忙しいと、ふだんはできてることでもうっかりミスや見落としが多くなります。
人の意識からこぼれおちたものは、バグに育ちやすいです。
忙しい中で実装された機能は、できるだけ念入りにテストしましょう。
歴史は繰り返す
歴史は繰り返す。流行も繰り返す。
バグも似たようなものが繰り返し発生します（体感）。
なので、可能なら過去のバグチケットを読みましょう。そしてバグの傾向をつかみましょう。
その傾向を元にテストを行うと、バグが見つかりやすくなります。
本ブログのテーマが「バグを見つけるコツ」なので、上記２つを書きましたが…
QAとしてはそもそも上記が発生しないよう、考える必要があります
バグを見つける一番大切なコツ
バグを見つけるコツを、自分のつたない経験からまとめてみました。
こまごま書きましたが、バグを見つけるための一番大切なコツは
「システムに関わる"誰か"を想うこと」だと思ってます。
Webシステムを利用するユーザーさま、
システム含めたサービス全体のサポートをしてくれる社内メンバーさん、
サービスを売ってくださる営業メンバーさん、開発者さん、デザイナーさん、PdMさん、
システムに関わる人を想いうかべて、「こうなったら困るかも？」と想像し続けること。
その姿勢が、バグを見つけるコツにつながっていく気がしてます。たぶん！
最後に
ここまでお読みいただきありがとうございました！
LITALICO Engineers Advent Calendar 2024 カレンダー2 、まだまだ続きます！
今年はなんと！シリーズ 4 まであるので、みなさんぜひ楽しんでいってください！