第3回 バグを見つけるコツ7選+α

第3回 バグを見つけるコツ7選 α

登録は簡単!. 無料です
または 登録 あなたのEメールアドレスで登録
第3回 バグを見つけるコツ7選+α により Mind Map: 第3回 バグを見つけるコツ7選+α

1. まつって誰?

1.1. 新人さんからわかるソフトウェアテスト解説マンガ『テスターちゃん』作者

1.1.1. https://www.amazon.co.jp/dp/4863543026

1.2. 勤め先ではQA組織所属。テストのコンサルタントのイメージ

1.3. JaSST Kyushu(ソフトウェアテストシンポジウム九州) 実行委員長

1.4. QA4AI(AI プロダクト品質保証コンソーシアム)でガイドラインのVUI領域(音声認識、自然言語理解、音声合成)担当

1.5. 会社でもプライベートでもテスト系のことをしてる変な人

2. テストの目的の一つ「バグを見つける」

2.1. テスト項目をチェックしていくのはどちらかというと「仕様通り動いているかの確認」

2.2. バグは「想定していなかった手順や使い方」で発生することのほうが多い

2.2.1. 考慮漏れ

2.3. そういったバグを見つけるには「自由なテスト」のほうが向いている

2.4. 「自由にテストしてバグを見つけろって言われても!」という人がほとんどですよね

2.5. 今日はテスト歴10年のまつの経験から「こういったことをしたらバグが出やすかった」というコツをお伝えします。

2.6. あくまでまつの経験上の話

2.7. これらは開発側としては「ウッカリしやすい場所」なんて言えるかもしれません

2.8. まつの背景

2.8.1. web

2.8.2. アプリ

2.8.3. ゲーム(スマホ、ブラウザ)

2.9. まつが書いたマンガでも紹介しています

2.9.1. テスターちゃん「バグの出し方のコツ」回

2.9.2. バグの出し方のコツ カテゴリーの記事一覧 - テスターちゃん【4コマ漫画】

3. バグを見つけるコツ7選

3.1. キーワードで紹介します

3.1.1. キーワードからさらに発想しやすくもなるかなと

3.2. その1:繰り返す

3.3. その2:タイミング

3.4. その3:境い目

3.5. その4:種類

3.6. その5:順番

3.7. その6:外部制御

3.8. その7:特殊な状態

4. バグを見つけるコツその1:繰り返す

4.1. 行動を繰り返すことによって、保存失敗や初期化忘れのようなバグを見つけられたりします

4.1.1. 例えばトグルボタン

4.1.1.1. 設定画面に遷移してトグルボタンをON!

4.1.1.2. 戻ってもう一回設定画面に戻ってみると…トグルボタンがOFFになっている!

4.1.1.3. テストケースの期待結果が「トグルボタンがONになっている」だけだと見つけにくい問題

4.1.1.3.1. 余談だけど、このケースの場合はテストする意図がわかってないケース

4.1.1.3.2. トグルをオンにした結果、実際にその設定画反映されているか…が本来そのテストで確認したい項目

4.1.2. 入力でエラーを出した後に再度文字を入力したら赤色で反映されちゃうとか

4.1.3. そういった単発だけではなく、もっと長いサイクルだと

4.1.3.1. ユーザー登録→使用→ユーザー削除→ユーザーの再登録

5. バグを見つけるコツその2:タイミング

5.1. ソフトウェアが何かするタイミングで別操作を入れると重複処理やフラグ変更失敗などのバグを見つけられたりします

5.1.1. 例えば投稿

5.1.1.1. 投稿ボタンをタタンとクリックしてみる

5.1.1.1.1. 投稿処理中に再度投稿処理ボタンが押せたことによって重複登録されてしまうなど

5.1.1.2. ajax(非同期通信) の通信のタイミングで何かしようとしてエラー

5.1.2. ゲームだと

5.1.2.1. 無限コンボ

5.1.2.2. マリオの2段ジャンプ

5.1.2.3. マリオのちびファイアマリオ

5.1.2.4. ローディング中にやたらタップするヤツ

5.1.3. バグ票で起票するけど「再現できません」がよく発生するものでもある

5.1.3.1. 動画を撮ろう

6. バグを見つけるコツその3:境い目

6.1. データの境い目、ページの境い目など「端っこ」ではバグが起こっていることも多いです

6.1.1. あるあるだと文字数制限の場所

6.1.1.1. テストケースで通ってる場所

6.1.2. データが1件ある場合と0件ページ

6.1.2.1. テストをやっているとデータが溜まっていくので0件ページは目が通りにくくなる

6.1.3. ページング

6.1.3.1. 1ページ目よし2ページ目よし!OKとやるけど

6.1.3.1.1. 1ページ目はURLにパラメーターなし

6.1.3.1.2. 2ページ目はURLにpage=2のパラメーター

6.1.3.1.3. 3ページ目は……?

6.1.4. 生年月日

6.1.4.1. 1970年と1969年

6.1.4.1.1. システムの境界値

7. バグを見つけるコツその4:種類

7.1. 入力に様々な種類があるときや、プレミアム会員など種別があるとき、特定の種類で保存失敗などのバグを見つけられたりします

7.1.1. よくあるのは文字

7.1.1.1. 人名

7.1.1.1.1. はしごだか(髙)

7.1.1.2. 空白、改行

7.1.1.3. 絵文字

7.1.1.3.1. 寿司ビール問題

7.1.1.4. サロゲートペア文字

7.1.1.4.1. 4バイトの文字

7.1.1.4.2. ŵ|ȥڥ - ƮĦITŨ󥸥˥¤γФȽ

7.1.2. 文字列

7.1.2.1. ちゃんとした日本語の文章

7.1.2.1.1. 改行が反映されないなど

7.1.2.2. URL

7.1.2.2.1. wikipediaのURLを張り付けるとはみ出したりする

7.1.2.2.2. https://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%82%BF%E3%83%BC%E3%81%A1%E3%82%83%E3%82%93

7.1.2.3. そもそも入力しない

7.1.2.3.1. 何もデータが入ってこなかった時の処理 (null)

7.1.2.4. htmlのタグ

7.1.2.4.1. (例をmidmisterに書いたらエラーが出たぞ。。。)

7.1.2.5. エスケープ処理される文字列

7.1.2.5.1. ><

7.1.2.6. SQLのクエリ

7.1.2.6.1. ' or 'a'='a

7.1.2.6.2. SQLインジェクション

7.1.3. 仕様が雑だった場合考慮が薄い場合があるので要注意

8. バグを見つけるコツその5:順番

8.1. この順番だと上手くいくけど、順番を変えると失敗する場合があります。「使い方の思い込み」のバグなんかが見つかります

8.1.1. そのプロダクトに触り慣れていると「ユーザーはこう使うだろう」みたいな思い込みの順番ができちゃったりする

8.1.2. 例えばデータは「絶対小さな準から入力していくだろう」など

8.1.2.1. 金額20000円~10000円の商品で検索

8.1.3. 「あ、そっちのデータから来ちゃったかー」という瞬間

8.1.4. 何気ない流れでやっている場所は順番を変えてやってみるのが吉

9. バグを見つけるコツその6:外部制御

9.1. ブラウザ自体の機能やスマホの機能で操作もできるわけです。ブラウザバックや割り込みなどを行うと描画失敗やクラッシュなどがあったりします

9.1.1. 例えば、購入ボタンを押した後はボタンは非アクティブにしているけどブラウザの「更新」ボタンは押せる

9.1.1.1. ロードが長いと連打する人がいる

9.1.2. アプリを使っている最中はホームボタンを押せる

9.1.2.1. ホームボタンで戻って復帰させたら画面が真っ白に!

9.1.3. 電話なんかもかかってくる

10. バグを見つけるコツその7:特殊な状態

10.1. 主にスマホ。よく使っている状態じゃなくて制限状態にすると、そこらへんの考慮漏れの問題が見つかります

10.1.1. 例えば、権限系のOFF状態

10.1.1.1. 位置情報を使うアプリで、位置情報オフの状態

10.1.1.1.1. 位置情報は最大の個人情報なんて言われる。オフにしている人も多い

10.1.1.2. 権限はONにしてくれるものだという思い込み

10.1.2. 通信遮断から電波復活後の挙動

10.1.2.1. トンネルに入って電波途切れたとか

10.1.2.2. wifi瞬断したとか

10.1.2.3. メッセージアプリでメッセージ送信失敗→電波復活後の再送信

10.1.3. 速度制限がかかっちゃった人

10.1.3.1. タイムアウトで画像が軒並み見れないとか

11. +αまつの経験をいくつか

11.1. URLのパラメーターをいじったら他人のマイページが見れた

11.1.1. ブラウザゲームのテストの時はURL改ざんはよくやっていた

11.2. まつの個人開発:本来想定していたフローでやったらうまく動かなかった

11.2.1. 文字列が書かれたcsvを読み込んで、webページ上の文言と照らし合わせるツール作成

11.2.2. 自分でcsvファイルを作って、それを使ったユニットテスト作って動作確認。問題なし。

11.2.3. 最終的にエクセルで大きなファイルを作りcsv化して使ったら文字列の照合で失敗

11.2.4. 「エクセルを使う」という工程!

11.2.5. こういうのは本来シナリオテスト

12. まとめ

12.1. バグを見つけるコツ7選

12.1.1. その1:繰り返す

12.1.1.1. 行動の繰り返し

12.1.2. その2:タイミング

12.1.2.1. ソフトウェアが何かしてるときに処理を挟む

12.1.3. その3:境い目

12.1.3.1. 「端っこ」はバグが出やすい

12.1.4. その4:種類

12.1.4.1. 何かひとつではなく、種類があるなら様々試してみよう

12.1.5. その5:順番

12.1.5.1. 思い込みの順番はないですか?

12.1.6. その6:外部制御

12.1.6.1. 操作はアプリ内だけではないのです

12.1.7. その7:特殊な状態

12.1.7.1. みんな理想的な状態でスマホを使っているわけではありません

12.2. +αの経験

12.2.1. URL改ざん

12.2.2. 全体として想定したフローでの確認

12.3. 今回お伝えしたのはあくまでまつの経験の話です。

12.4. みなさんの扱うプロダクトに使えるものもあるし、使えないものもあるでしょう。

12.5. 何かのヒントになりましたら幸いです~!!