バグを見つける40のアイデア（リンク集）
バグを見つける30のアイデア1
— Hideo Oide🍜 (@hide_ramen_san) April 11, 2024
「createdとupdatedに着目しよう」
並び順が昇順でも降順でもデータのcreatedかupdatedかで違うので期待値を確認しよう。
また、リファクタリング等でデータを移管する時にうっかりupdatedを更新しないように気をつけよう。
バグ見つける30のアイデア2
— Hideo Oide🍜 (@hide_ramen_san) April 12, 2024
「データが重複を許容しないか確認しよう」
ユーザー名やメールアドレス等で重複データを許容しない場合に、updateにより重複するデータに変更する場合も確認しよう。
deleteした後で再登録出来るかも確認しよう。
バグを見つける30のアイデア3
— Hideo Oide🍜 (@hide_ramen_san) April 12, 2024
「deleteが物理削除か論理削除かに着目しよう」
物理削除なら削除後のreadはデータが無い時のreadだけど、論理削除なら削除後のreadは削除フラグが有効かの確認になるので意味合いが違う。
削除後の再登録も物理削除ならcreateだけど論理削除ならupdate。
バグを見つける30のアイデア4
— Hideo Oide🍜 (@hide_ramen_san) April 12, 2024
「0とnullを確認しよう」
データが無いnullの状態と0の状態が違うことは有り得ます。
初期状態の0の表示だけではなく、例えばポイント等が一旦加算された後に使い切って0になった場合も確認しましょう。
バグを見つける30のアイデア5
— Hideo Oide🍜 (@hide_ramen_san) April 13, 2024
「境界（値？）を確認しよう」
ソフトウェアテスト技法に境界値テストがあります。境界値には数値化しにくい（内部的には数値化されてる）ものも有り得る（UIパーツのどの部分まで反応するかとか）ので確認しましょう。
広告は意図的に反応しやす過ぎるようですが…
バグを見つける30のアイデア6
— Hideo Oide🍜 (@hide_ramen_san) April 13, 2024
「負の値を確認しよう」
同値分割等で無効な値を入れるという話はよくありますが、負の値が許容されているかどうか、許容されていない場合に入力したらどうなるかを確認しましょう。
お買い物アプリで検索条件にマイナスのお値段を入力できるのをたまに見ます。
バグを見つける30のアイデア7
— Hideo Oide🍜 (@hide_ramen_san) April 13, 2024
「小数点を確認しよう」
小数点を許容するのか、許容するとして小数点第何位まで保存、表示するのか、四捨五入するのか繰り上げるのか切り捨てるのか、確認しましょう。
レビューの平均値が4.26だったら星4つなのか星4つと半分の星だったりするのか等。
バグを見つける30のアイデア8
— Hideo Oide🍜 (@hide_ramen_san) April 13, 2024
「最大値を確認しよう」
境界値テストで最大値を確認しますよね。
入力の確認で終わらずに最大値入力したデータが他の箇所でどのように表示されているかを確認しましょう。
ユーザーネームに最大値を入れたら、それが他人にどう見えてるかプッシュ通知等も確認必要。
バグを見つける30のアイデア9
— Hideo Oide🍜 (@hide_ramen_san) April 14, 2024
「特殊文字に注意しよう」
絵文字、スペース、機種依存文字の入力と出力を確認しましょう。
絵文字もサッカー⚽は1バイトでOKでラグビー🏈は2バイトでNGとかもあります。
スペースのみの入力と出力も試してみましょう。
バグを見つける30のアイデア10
— Hideo Oide🍜 (@hide_ramen_san) April 14, 2024
「HTMLタグに注意しよう」
フリーテキストが入力できるところにはHTMLタグを入力して出力も確認してみましょう。
<h1>見出し</h1>とか入れてそのまま表示されるかタグ部分が除去されるか見出しになるか。
期待値は使われる場所によるので要確認です。
バグを見つける30のアイデア11
— Hideo Oide🍜 (@hide_ramen_san) April 14, 2024
「連打と同時押し」
定番ですがボタンの連打と同時押しは試してみましょう。
同じブラウザの2つのボタンの同時押しだけじゃなくて、違うブラウザで同じボタンの同時押しも試しましょう。
とはいえテストケース全部に連打する手順を書くのはちょっと止めたいです。
バグを見つける30のアイデア12
— Hideo Oide🍜 (@hide_ramen_san) April 14, 2024
「キャンセルで取り消されるものは他に無いか確認しよう」
5個購入したらクーポン付与という条件で5個購入後1個キャンセルされたらクーポンもキャンセルされるでしょうか？それともクーポンは継続でしょうか？
自己都合キャンセルか事業所都合キャンセルで違いますか？
バグを見つける30のアイデア13
— Hideo Oide🍜 (@hide_ramen_san) April 15, 2024
「キャンセルの前と後で状態を変えてみよう」
決済がキャンセルされた後に支払ったお金が返ってきますよね。
アカウント削除したりして返ってくるお金を受け取れない状態になってたらどうなりますか？
返さなくて良いですか？ダメですよね？
バグを見つける30のアイデア14
— Hideo Oide🍜 (@hide_ramen_san) April 15, 2024
「条件成就のタイミングに着目しよう」
非同期処理する場合にエンキューする前は条件を充たしていて、実行されるときには条件を充たさなくなっている場合にどうなるか。
メール一括送信する場合に、バッチ処理が走る前に退会してたらどうなる？とか。
バグを見つける30のアイデア15
— Hideo Oide🍜 (@hide_ramen_san) April 15, 2024
「日付けの切り替わりを確認しよう」
日付けだけではなく、何時に切り替わるかも確認しましょう。
0時の場合も、営業時間終了の午後5時の切り替わり場合も、ゲームの場合は朝午前5時の切り替わり見ます。
月や年の切り替わりも注意が必要です。
バグを見つける30のアイデア16
— Hideo Oide🍜 (@hide_ramen_san) April 15, 2024
「ファイルの種類に気をつけよう」
画像や動画等のファイルのダウンロードやアップロードができるサービスの検証では色々なファイルで試してみましょう。
jpeg、png、gif、webp、mov、mp4、txt、docx、pdf、csv、xlsx、pptx、zip…いや、もっとありますね。
バグを見つける30のアイデア17
— Hideo Oide🍜 (@hide_ramen_san) April 15, 2024
「有効期限に気をつけよう」
新しい機能をリリースする時に、有効期限が3ヶ月だったりするとして、リリース前に有効期限切れた場合の挙動を確認してますか？
リリースしてから3ヶ月後のことだからとリリース後に後回ししてないですか？
バグを見つける30のアイデア18
— Hideo Oide🍜 (@hide_ramen_san) April 16, 2024
「有料と無料の違いに気をつけよう」
有料会員と無料会員で手数料が違ったりしますよね。
途中で有料会員から無料会員に切り替わるとどうなりますか？
あとゲームで同じ効果のアイテムが有料と無料と両方あって、無料が優先的に使われるとかありますよね。
バグを見つける30のアイデア19
— Hideo Oide🍜 (@hide_ramen_san) April 16, 2024
「条件を複数重ね掛けしてみよう」
2000円の商品について10%割引と100円引きと両方の条件を充たしたら、10%は割引前の商品価格ですか？割引後の商品価格ですか？2000-2000×0.1-100=1700ですか？2000-100-（2000-100）×0.1=1710円ですか？
（重複しない可能性高いが）
バグを見つける30のアイデア20
— Hideo Oide🍜 (@hide_ramen_san) April 16, 2024
「管理者権限に気をつけよう」
特にtoB向けのサービスでは、管理者かそうじゃないかでできることに制限がかかっていることが多いですよね。
新しい機能を開発するたびに、管理者と非管理者との比較をデシジョンテーブル等を使って整理すると良いと思います。
バグの見つける30のアイデア21
— Hideo Oide🍜 (@hide_ramen_san) April 16, 2024
「中断からの再開に注意しよう」
画面がA→B→Cって遷移する場合に、A→B→A→B→Cって一回前の画面に戻ってから遷移しておかしくなったりしたことないですか？
もしかしたらcacheが壊れたりしてたのかもしれません。
バグを見つける30のアイデア22
— Hideo Oide🍜 (@hide_ramen_san) April 16, 2024
「退会とBANの違いに気をつけよう」
サービスを使えなくなるという意味では似たような機能ですが、退会はできれば帰ってきて欲しい、BANは二度とサービスにアクセスして欲しくないという違いがあります。
退会からの復帰が出来るかは検証しましょう。
バグの見つける30のアイデア23
— Hideo Oide🍜 (@hide_ramen_san) April 16, 2024
「検索結果はユーザーの属性ごとに確認しよう」
ショッピングサイトでは、ブランド名で検索しても、会員の性別や年齢で違う検索結果になることもあるので、完全一致や部分一致だけではなく、複数のユーザーで同じワードで検索して結果を見比べて意図通りか確認しよう。
バグを見つける30のアイデア24
— Hideo Oide🍜 (@hide_ramen_san) April 17, 2024
「後方互換に気をつけよう」
古いバージョンで作成したデータを新しいバージョンで閲覧編集出来るか確認しましょう。
また、アプリでは古いバージョンを使い続けるユーザーがいる可能性があります。古いバージョンを使うことで有利にならないようにも注意しましょう。
バグを見つける30のアイデア25
— Hideo Oide🍜 (@hide_ramen_san) April 17, 2024
「OSアップデートに注意しよう」
AndroidやiOSのアップデートは例年9月くらいにあります。
スマートフォンで利用されるサービスに関わっているなら、新しいOSが公開される前にBeta版をインストールしてお客様が使われる前に動作確認しましょう。
バグを見つける30のアイデア26
— Hideo Oide🍜 (@hide_ramen_san) April 17, 2024
「ビルドツールのアップデートに注意」
AndroidやiPhone向けのアプリの開発であれば、プロダクトコードに変更が無くても、Android StudioやXcodeのバージョンアップによって影響が出る場合があります。
広範なリグレッションテストが必要になる可能性があります。
バグを見つける30のアイデア27
— Hideo Oide🍜 (@hide_ramen_san) April 17, 2024
「他人のなりすましに注意しよう」
ブラウザで動作するアプリケーションであれば、idを任意の値に書き換えられます。他人のidを利用できないことを確認しましょう。
また、クレジットカードなど、1つのカード番号が複数アカウントに紐付けられないことを確認しましょう。
バグを見つける30のアイデア28
— Hideo Oide🍜 (@hide_ramen_san) April 17, 2024
「外部連携サービスの停止や仕様変更に気をつけよう」
担当するサービスが自社開発したシステムだけで運用されているとは限りません。
たとえばログインで使用するSNSがメンテナンス中でログインできない場合でも、ユーザーが理解出来るメッセージを出しましょう。
バグを見つける30のアイデア29
— Hideo Oide🍜 (@hide_ramen_san) April 17, 2024
「関連法令を確認しましょう」
法令違反のシステムをリリースするわけにはいきません。
また、リリース後に法令が改正されて仕様変更が必要になる場合もあります。
自社サービスに影響する法令の改正情報には注意しましょう。
税や会計は頻繁に改正があって大変そう。
バグを見つける30のアイデア30
— Hideo Oide🍜 (@hide_ramen_san) April 17, 2024
「最後は根性」
サッカーのゴールキーパーが指一本で止めたみたいなのは、ソフトウェアテストでもあると思います。
QAエンジニアの役割として、最後の門番は古いと言われたりしますが、プロダクトの品質を守りたいっていう気持ちの強さは必要だと思っています。
バグを見つける30のアイデア31
— Hideo Oide🍜 (@hide_ramen_san) April 18, 2024
「人数がユニークかどうか確認しよう」
PVはページの閲覧数で1人が3回閲覧したらPVは3になります。
UUはユニークユーザーなので1人が3回ページを閲覧してもUUは1です。
ページ閲覧数に限らず、人数を表示する場合はどちらなのか確認しましょう。
バグを見つける30のアイデア32
— Hideo Oide🍜 (@hide_ramen_san) April 18, 2024
「エラーログをチェックしよう」
開発環境でもエラーログを出力している開発チームも多いと思います。
お客様に影響の無いエラーでもモニタリングのノイズになるのでできれば取り除きたいです。
新機能の開発中に新規のエラーが出てないかは確認しましょう。
バグを見つける30のアイデア33
— Hideo Oide🍜 (@hide_ramen_san) April 19, 2024
「お問い合わせを確認しよう」
運用されているサービスであれば、お客様からお問い合わせがあるかもしれませんが、件数が多くなければ開発チームに報告は無いかもしれません。
ただ、調べてみたらバグだったという可能性があります。
バグを見つける30のアイデア34
— Hideo Oide🍜 (@hide_ramen_san) April 19, 2024
「誤った報告にも寛容に」
バグだと思ったら操作を間違えてたとか仕様を勘違いしてたとかは良くあることです。
それを非難してバグ報告を萎縮するようになってしまうとバグが見つかりにくくなってしまいますので気をつけましょう。
バグを見つける30のアイデア35
— Hideo Oide🍜 (@hide_ramen_san) April 19, 2024
「効果的なダブルチェックを」
ダブルチェックは有効な手法だと思いますが、全く同じケースを2人目が行ってもあまり意味は無いと思います。リンゲルマン効果と言われます。
1人目と2人目で少し工程を変える（たとえば違う入力値とか違う環境）と良いかもしれません。
バグを見つける30のアイデア36
— Hideo Oide🍜 (@hide_ramen_san) April 20, 2024
「最初に全体像を」
1000ケースを5日間で実行する計画だとして、1日目に1番目から200番目を完了したけど3日目にコアになる機能をテストしてみたらバグが多く出て計画を大幅に変更必要になったことはありませんか？…
バグを見つける30のアイデア37
— Hideo Oide🍜 (@hide_ramen_san) April 20, 2024
「検証中のABテストに気をつけよう」
新機能Xの有効性の確認のために50%のユーザーにだけ使えるようにすることがあります。
その検証中に別の新機能Yを追加する場合は、Xが使えるユーザーと使えないユーザー両方でテストする必要がある場合があるので注意しましょう。
バグを見つける30のアイデア38
— Hideo Oide🍜 (@hide_ramen_san) April 20, 2024
「過去のバグチケットを確認してみよう」
転職したり配置換えで新しいプロジェクトを担当することになったら過去のチケットを確認してみましょう。
対応が後回しになっているバグを認識できるかもしれませんし、過去のバグが再発した時にすぐに気が付くかもしれません。
バグを見つける30のアイデア39
— Hideo Oide🍜 (@hide_ramen_san) April 20, 2024
「見積もりの予実がズレた場合は注意」
予定より実装に時間がかかってしまった場合は何か理由があるかもしれません。
当初想定よりも仕様が複雑だった、同時にリファクタリングもした等、理由によってはバグが作り込まれる可能性も高くなります。
バグを見つける30のアイデア40
— Hideo Oide🍜 (@hide_ramen_san) April 21, 2024
「関係する機能を比較しよう」
たとえばショッピングサイトであれば、個別に商品を購入する場合とカートに入れて一括購入する場合を比較しましょう。
SNSで記事に写真をアップロードする場合と自分のプロフィールの写真をアップロードする場合を比較しましょう。
いただいたサポートは生活費にあてます