1. 「テスターちゃん」について

初心者(新人)向けに描かれたソフトウェアテストの漫画になります
たまたまJSTQBについて調べていた時に見付けたブログの記事がきっかけで読むようになりました
JSTQBを取るメリット5選

今でも更新がある度にチェックしたり、書籍版を読み返したりしたり、とテスト関連の資料として活用しています

2. LOG

3. 探索的テスト

3.1 探索的テストって何

テストケースを使わないでお題（目的）に沿って、考えながら、自由に行うテストのこと
※だけど、自由と言っても適当に操作するワケじゃない

①学習：どう動くか把握しながら
②テスト設計：どうテストするか考えて
③テスト実行：実際に試してみる
④分析：終わったら結果を踏まえて、次にどうするか考える

【補足】

補足説明で作者さんは、難しく考えず「こう攻めたらどうよ」を考えて、繰り返し試しまくるとアドバイスしている

テストケース作りに時間をかける代わりに、考えながらテスト設計と実行を一緒にやる
⇒テストの時間が少ない時とか、アジャイルの時などに有効
　もちろん、テストケースとの併用も可
　⇒テストケースで正常系を確認し、探索的テストでイレギュラーを確認や、それらを同時進行など

ただし

どんなテストが必要か考えて
テスト実行して
結果から推理して

一緒にやる必要があるので、とても難しい

どう言うところにバグが潜んでいるか
こういうアプリならだいたいこういう動きをする
などなど

経験と知識を積んだ人じゃないとなかなかバグを出せないことが多い

【経験と知識について】

バグ検出はワラの山から針を見付けるようなもの
「昨日この辺で作業してたからそこに針があるだろう」「区画で割って1区画ずつワラの中を探そう」みたいな工夫は必須
つまりは柔軟性が求められる、と言う認識

3.2 探索的テストの種類とやり方について

探索的テストの種類

・テストチャータを使うタイプ
・フリータイプ
・セッションベースドタイプ
※基本的なものを絞り込み

テストチャータを使うタイプについて

1.テストの指針となるお題を設定する
　⇒お題や資料のような探索的テストの道しるべになるもののことをテストチャータと言う

〔EX〕
仕様書にある機能が実装されているか確認
この場合、必要なものは仕様書となる

２.目指す方向を決めて、探索的テストを行う
　⇒目指すところがあるから迷いにくくなる
　　自由だと人によってあちこち行くので、方向性を決めておく

〔EX〕
・ガイドブックツアー（マニュアルに着目）
・ランドマークツアー（遷移等に着目）
・スーパーモデルツアー（UIに着目）
・ガーベージコレクターツアー（機能や画面をパパッとチェックして回る）

フリータイプについて

テストする人にお任せするスタイル

①テストする人自身で目的を決め
②学習
③テスト設計
④テスト実行
⑤分析
を進める

【注意】

フリータイプのみだと、よほどのメンバーがいない限り、抜け漏れが発生すると考えていい（みんなメイン機能にテスト設計が集中するなど）
使う場合は他の手法と併用するのがおすすめ
またまとめ役は大変になることもある
慣れない人だと、設計がうまくできなくて正常系を繰り返すだけになることもある

セッションベースドタイプについて

テストチャータを使うタイプに時間制限をつけたもの
⇒時間を区切ることで集中力を保ち易かったり、急な変更に対応し易かったり、テスト管理がし易かったりする
セッションベースドテストマネージメントとも言われている

①1回の探索的テストの時間を決める
　⇒４５分〜2時間のことが多い
　この1回のことをセッションと言う
②セッションのお題(テストの目的：ミッションとも言う)とテストチャータを用意する
③1つ目のセッションが終わったら１５〜２０分くらいの時間で結果を話し合う
④話し合ったこと（終了後の話し合いのことをデブリーフィングと言う）を元に、次のセッションのやることの調整をする
⑤①〜④を繰り返す

コツ

探索的テストを時間と確認範囲で分けることによって、基本動作を短時間で効率的に確保できる
基本動作のバグは早めに報告する

テストしたことについて

テストしたことは簡単でいいのでテストログ（正式名称ではない）として残しておく
テストした証拠になるし、通っていない場所の確認にも使える

4. バグの出し方

4.1 バグの出し方がわからない！！

仕様の確認と一緒に、仕様のちょっとした脇道（イジワル）を考えて試してみる
⇒仕様から少しひねったイジワルをするとバグが出ることが多い

4.2 バグの出し方のコツ

①繰り返す

EX：SNSで「いいね」を押した後、F5でリロードしてみる

テストケースだと1回だけしか通らないようなものがたまにあるから、もう1回繰り返すとおかしなことがある
保存失敗とか、エラー後に繰り返すと文字の色が変わっていないとか、投稿後に投稿すると前の内容が残っていたり、など

②タイミング

ソフトが何かしているタイミングで何かを操作してみる

〔EX〕
・投稿する時に投稿ボタンを連打する
・ローディング中にあれこれ操作してみる
・音楽なら再生ボタンが停止ボタンに変わる前に再クリックしてみる
・購入処理の操作⇒申し込みや課金部分で出たら大変
・アプリなら処理中にホームに戻ってみる

③境界値

端っこ部分はバグが出やすい

〔EX〕
・パスワードなどで8文字以上と決まっている場合、８文字で通るか・７文字でエラーがちゃんと出るか
・投稿サイトなどで投稿が1件ある場合、投稿なし(データなし)の場合
・見えない境界値も重要

④種類

入力に種類があるときは色々な種類を試してみる

〔EX〕
・画像や動画の場合
　⇒画像の種類
　　サイズ
　　容量
　　再生できる動画のコーデックの種類
・ファイルアップロードの場合
　⇒上がってはいけないファイルのチェック
　　RLOの制御文字を入れたファイルを試す
・文字の場合
　⇒環境依存文字
　　4バイト文字
　　絵文字

⑤順番

ある順番で操作するとうまくいくけど、別の順番で操作するとバグが出ると言う時がある
順序を入れ替えたりして試してみる

思い込みの順番にも気を付けること
「ユーザーは絶対この順番で操作する」と言う思い込み
何気ない流れでやっている手順がある場所も要注意
暗黙的に順序が決まっているようなところがあったら入れ替えてみるとか

⑥外部制御

ページ内やアプリ内の操作の他にブラウザ機能で操作できるところを試してみる

〔EX〕
・ロードの待ち時間が長いので「更新」ボタンを押す→フォームの再送信→「再施行」を押す
・「戻る」→「確定」ボタン
・Androidのバックキー

⑦特殊な状態

よく使っているいつもの状態ではなく制限のある状態にして確認してみる
⇒スマホやタブレットなどでよくあるパターン

〔EX〕
・ある権限を制限した時
　⇒位置情報の権限を使うアプリで位置情報オフでやってみる
・通信遮断状態（機内モードを使って確認する）
　→圏外になった時の動作、電波が復活した時の挙動がどうなっているか
・通信制限状態

考慮漏れバグ
「こう言う時はどう動くか」と考えることは大切

4.3 バグ出しのコツ・補足

企画・開発が忘れがちなところでもある
なので、あらかじめ「こんなところを見るようにしている」と伝えると事前にバグが防げたりするかも

「テスターちゃん」で学ぶソフトウェアテスト③