「テスターちゃん」で学ぶソフトウェアテスト③
「Qiitaに書いてた記事をnoteに移行しよう」シリーズと言うことで、Qiitaに投稿している記事の掘り起こしとなります。また、内容の整理も行う予定のため、Qiitaに投稿した記事をそのまま移行する形とならない場合もあります。ご了承ください。
■Archives
■探索的テスト
・探索的テストって何？
テストケースを使わないでお題（目的）に沿って、考えながら、自由に行うテストのこと。
※だけど、自由と言っても適当に操作するワケではない。
①学習：どう動くか把握しながら、
②テスト設計：どうテストするか考えて、
③テスト実行：実際に試してみる。
④分析：終わったら結果を踏まえて、次にどうするか考える。
【補足】
補足説明で作者さんは、難しく考えず「こう攻めたらどうよ」を考えて、繰り返し試しまくるとアドバイスしている。
また、JSTQB Foundation Levelのシラバスでは、第4章テスト技法内の「4.4.2 探索的テスト」で探索的テストについて説明されている。
テストケース作りに時間をかける代わりに、考えながらテスト設計と実行を一緒にやる。
→テストの時間が少ない時とか、アジャイルの時などに有効。
もちろん、テストケースとの併用も可。
→テストケースで正常系を確認し、探索的テストでイレギュラーを確認したり、それらを同時進行で実行するなど。
ただし、
・どんなテストが必要か考えて、
・テスト実行して、
・結果から推理して、
一緒にやる必要があるので、とても難しい。
・どう言うところにバグが潜んでいるか
・こういうアプリならだいたいこういう動きをする
・などなど
経験と知識を積んだ人じゃないとなかなかバグを出せないことが多い。
【経験と知識について】
バグ検出はワラの山から針を見付けるようなもの。
「昨日この辺で作業してたからそこに針があるだろう」「区画で割って1区画ずつワラの中を探そう」と言った工夫は必須である。
つまりは柔軟性が求められる、と言う認識。
・探索的テストの種類とやり方について
探索的テストの種類
・テストチャータを使うタイプ
・フリータイプ
・セッションベースドタイプ
※基本的なものを絞り込み
テストチャータを使うタイプについて
①テストの指針となるお題を設定する。
→お題や資料のような探索的テストの道しるべになるもののことをテストチャータと言う。
〔EX〕
仕様書にある機能が実装されているか確認。
この場合、必要なものは仕様書となる。
②目指す方向を決めて、探索的テストを行う。
→目指すところがあるから迷いにくくなる。
自由だと人によってあちこち行くので、方向性を決めておく。
〔EX〕
・ガイドブックツアー（マニュアルに着目）
・ランドマークツアー（遷移等に着目）
・スーパーモデルツアー（UIに着目）
・ガーベージコレクターツアー（機能や画面をパパッとチェックして回る）
フリータイプについて
テストする人にお任せするスタイル。
①テストする人自身で目的を決める
②学習
③テスト設計
④テスト実行
⑤分析
を進める。
【注意】
フリータイプのみだと、よほどのメンバーがいない限り、抜け漏れが発生すると考えていい（みんなメイン機能にテスト設計が集中するなど）。
使う場合は他の手法と併用するのがおすすめ。
またまとめ役は大変になることもある。
慣れない人だと、設計がうまくできなくて正常系を繰り返すだけになることもある。
セッションベースドタイプについて
テストチャータを使うタイプに時間制限をつけたもの。
→時間を区切ることで集中力を保ち易かったり、急な変更に対応し易かったり、テスト管理がし易かったりする。
セッションベースドテストマネージメントとも言われている。
①1回の探索的テストの時間を決める
→45分〜2時間のことが多い
この1回のことをセッションと言う
②セッションのお題(テストの目的：ミッションとも言う)とテストチャータを用意する
③1つ目のセッションが終わったら１５〜２０分くらいの時間で結果を話し合う
④話し合ったこと（終了後の話し合いのことをデブリーフィングと言う）を元に、次のセッションのやることの調整をする
⑤①〜④を繰り返す
コツ
探索的テストを時間と確認範囲で分けることによって、基本動作を短時間で効率的に確保できる。
基本動作のバグは早めに報告する。
テストしたことについて
テストしたことは簡単でいいのでテストログ（正式名称ではない）として残しておく。
テストした証拠になるし、通っていない場所の確認にも使える。
■バグの出し方
・「バグの出し方がわからない！！」そんな時は…
仕様の確認と一緒に、仕様のちょっとした脇道（イジワル）を考えて試してみる。
→仕様から少しひねったイジワルをするとバグが出ることが多い。
・バグの出し方のコツ
①繰り返す
同じ操作やを繰り返したり、更新をかけてみたりする。
〔EX〕
SNSで「いいね」を押した後、F5でリロードしてみる。
テストケースだと1回だけしか通らないようなものがたまにあるから、もう1回繰り返すとおかしなことがある。
保存失敗とか、エラー後に繰り返すと文字の色が変わっていないとか、投稿後に投稿すると前の内容が残っていたり、など。
②タイミング
ソフトが何かしているタイミングで何かを操作してみる。
〔EX〕
・投稿する時に投稿ボタンを連打する。
・ローディング中にあれこれ操作してみる。
・音楽なら再生ボタンが停止ボタンに変わる前に再クリックしてみる。
・購入処理の操作⇒申し込みや課金部分で出たら大変。
・アプリなら処理中にホームに戻ってみる。
③境界値
端っこ部分はバグが出やすい。
※境界値分析の考え方もここから来ているのかもしれない。
〔EX〕
・パスワードなどで8文字以上と決まっている場合、８文字で通るか、７文字でエラーがちゃんと出るか。
・投稿サイトなどで投稿が1件ある場合と投稿なし（データなし）の場合。
・見えない境界値も重要である。
④種類
入力に種類があるときは色々な種類を試してみる。
〔EX〕
・画像や動画の場合
→画像の種類
サイズ
容量
再生できる動画のコーデックの種類
・ファイルアップロードの場合
→上がってはいけないファイルのチェック
RLOの制御文字を入れたファイルを試す
・文字の場合
→環境依存文字
4バイト文字
絵文字
⑤順番
ある順番で操作するとうまくいくけど、別の順番で操作するとバグが出ると言う時がある。
順序を入れ替えたりして試してみる。
思い込みの順番にも気を付けること
「ユーザーは絶対この順番で操作する」と言う思い込みをしてしまうことがある。
何気ない流れでやっている手順がある場所も要注意。
暗黙的に順序が決まっているようなところがあったら順番を入れ替えてみる。
⑥外部制御
ページ内やアプリ内の操作の他にブラウザ機能で操作できるところを試してみる。
〔EX〕
・ロードの待ち時間が長いので「更新」ボタンを押す→フォームの再送信→「再施行」を押す
・「戻る」→「確定」ボタン
・Androidのバックキー
⑦特殊な状態
よく使っているいつもの状態ではなく制限のある状態にして確認してみる。
→スマホやタブレットなどでよくあるパターン。
〔EX〕
・ある権限を制限した時
→位置情報の権限を使うアプリで位置情報オフでやってみる
・通信遮断状態（機内モードを使って確認する）
→圏外になった時の動作、電波が復活した時の挙動がどうなっているか
・通信制限状態
考慮漏れバグ
「こう言う時はどう動くか」と考えることは大切である。
・バグ出しのコツ・補足
企画・開発が忘れがちなところでもある。
なので、あらかじめ「こんなところを見るようにしている」と伝えると事前にバグが防げたりするかもしれない。
■体験談
下記のように7×3で均等にアイコンが並んでいて、アイコンごとに押下すると表示が変わる機能があったとします。
A B C D E F G
H I J K L M N
O P Q R
AとC、もしくはCとQを同時に押下した場合(3つ並んでいるアイコンの内、両端を押下する形)、挙動として考えられるのは下記かと思います。
①無反応
②AかC、もしくはCかQ
ですが、実際は押下していない挟まれたアイコンの内容(上記の例えだとBもしくはJ)が表示されると言う不具合が発生しました。
起票し、改修後はAかC、もしくはCかQのどちらかのアイコンを押下した際の内容が表示される形になりました(同時押しとは言え、タイミングや押下時の強さによってどちらかのアイコンの表示がされるのは考えられる)。