1. スモークテスト目的の 探索的テストの戦術
1.1. スモークテストとは
1.1.1. JSTQBの用語集では以下のように説明されています
1.1.2. プログラムの必須機能が正常に動作することを確認するのが目的で、 コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
1.1.3. ざっくり言ってしまうと「主要機能がだいたい動くよねということを確認するテスト」です
1.1.4. できたてホヤホヤのシステムやアプリを受け取ったときに
1.1.5. 全体をサラッと通して、最低限のところ動くよね、ということを確認するときに使います
1.1.6. この時動かないところがあれば、後に続くであろうテストケース実施で、その部分は後回しにして…とテストの進め方を組み直すことができます
1.1.7. また、この時点で見つかるバグは大きな問題です。
1.1.7.1. 大きな問題が早めにわかるというメリットと
1.1.7.2. 早めにわかることで修正時間を確保できるメリットがあります
1.2. では、スモークテスト目的のまつ流の探索的テストの戦術です
1.2.1. 概要としては、システムを各機能に分割して、各機能をメンバーに割り当てて探索的テストです
1.2.2. ただ単にメンバーに探索的テストをしてもらうと同じところを見てしまったり
1.2.3. 見ていない機能が発生したり、どの機能まで見たかわからなくなったりします
1.2.4. 機能ごとに範囲を指定することでそれらを回避しつつ、全体をサクッと確認することができます
1.2.5. 分割は機能でもストーリーでもページでも、わけやすいものでわけましょう
1.3. 例
1.3.1. 例えばシステムがA,B,C,D,E,Fの6機能
1.3.2. メンバーがXさん、Yさん、Zさんの3名だったとします
1.3.3. 探索的テストとしては時間で区切った探索的テストで進めます
1.3.3.1. 【第10回】セッションベースドの探索的テストのやり方【テスターちゃんねる】
1.3.4. セッションの1回目は
1.3.4.1. XさんはA機能の探索的テスト
1.3.4.2. YさんはB機能の探索的テスト
1.3.4.3. ZさんはC機能の探索的テスト
1.3.4.4. 時間は40分です。小さい機能ならもっと時間を短くしてもよさそうです
1.3.4.5. 目的は「動かないところ、あきらかにおかしいところの発見」
1.3.4.6. テストチャーターは「仕様書」です
1.3.4.7. 慣れているメンバーが多いのであれば、チャーターなしに自由に探索的テストでもよいかもしれませんね
1.3.5. セッションの2回目は
1.3.5.1. XさんはD機能の探索的テスト
1.3.5.2. YさんはE機能の探索的テスト
1.3.5.3. ZさんはF機能の探索的テスト
1.3.6. 図にするとこんな感じです
1.3.7. 単純に時間と範囲を絞って割り当てるだけの探索的テストですが
1.3.8. 使いやすく強力な方法で重宝していました
1.4. 余談ですが、スモークテストはE2E自動テスト向きだとまつは思っていたりします
2. まとめ
2.1. 今回はまつ流のテストの目的別の探索的テストの戦術をお話しました
2.2. スモークテスト目的
2.2.1. スモークテストは「主要機能がだいたい動くよねということを確認するテスト」です
2.2.2. 機能などわけやすい単位でわけて、それぞれのメンバーで被らないように探索的テストを担当するやり方をご紹介しました
2.2.3. こんな感じです
2.3. バグ出し目的
2.3.1. 機能などわけやすい単位でわけて、複数名で被らせながら探索的テストを担当するやり方をご紹介しました
2.3.2. こんな感じです
2.4. リグレッションテスト目的
2.4.1. リグレッションテストは「何か修正したとき、いじってない場所がバグってないよね？を確認するテスト」です。
2.4.2. バグ票をチャーターとして探索的テストをする方法をご紹介しました
2.4.3. また、主要導線が死んでいないかの確認にスモークテスト目的の探索的テストを使うことがあることもご紹介しました
2.5. まつ流のテストの目的別の探索的テストの戦術の話はいかがだったでしょうか？
2.6. この手の話って、全然話に上がってこないので自分流を説明してみました
2.7. 「私たちはこんな感じでやってるよー」というのがありましたら是非コメント欄に記載してみてください。みなさん参考になるかと思います
2.8. もしよければ、いいねやチャンネル登録をお願いします！
2.9. 戦略的なテストライフを！ それでは！
3. リグレッションテスト目的の 探索的テストの戦術
3.1. リグレッションテストとは
3.1.1. JSTQBの用語集では以下のように説明されています
3.1.2. ソフトウェアの変更されていない領域で欠陥が混入している、もしくは露呈していることを検出するための、変更関連のテストの一種。
3.1.3. 要は「何か修正したとき、いじってない場所がバグってないよね？を確認するテスト」です。
3.1.4. テストをしてると一度は言われたことがあるセリフ
3.1.5. 「そこ触ってないから大丈夫ですよ」
3.1.6. 大体は本当に大丈夫ですが、たまーに影響があって壊れていることはあります
3.1.7. 今回はシステムテストの後半、修正したバグの周りでデグレが起こっていないか確認する方法で説明したいと思います
3.2. では、リグレッションテスト目的のまつ流の探索的テストの戦術です
3.2.1. 概要としては、修正したバグをリストにして、
3.2.2. それぞれのバグ票をチャーターにして周辺を探索的テストするという方法です
3.3. 説明していきます。
3.3.1. まずは、バグ票をspread sheetなどにリスト化します
3.3.1.1. 機能や発生場所の管理をしているなら、近いものでまとめると割り振りしやすいです
3.3.2. そして
3.3.2.1. 1~10番まではXさん
3.3.2.2. 11~20番まではYさん
3.3.2.3. といったように割り振りします
3.3.2.4. 機能や発生場所でバグをまとめられるなら、その領域ごとに割り振れるとグッドです
3.3.3. そのバグ票をチャーターとして
3.3.3.1. 1回は確認テストをしてもらいます
3.3.3.2. 確認テストはそのバグ票に記載されたバグが再現するかの確認です
3.3.3.3. 手順を把握した後に、そのバグ票を参考に探索的テストを実施です
3.3.3.4. 時間を決めないとずっと続けてしまったりするので
3.3.3.5. 「10分くらいやって何もなかったら次に行ってね」なども伝えた方が良いです
3.3.4. もし大きな問題が発見されたら、そこを集中して確認する探索的テストを挟むのがいいです
3.3.5. バグ票を全部見るのは、現実的ではないことも多かったりします
3.3.6. その場合は優先度が高いものを範囲にしたり、修正に時間がかかってたものをピックアップしたりするなどしていました
3.4. この方法はテストの時間がしっかり確保できているときです
3.5. システムテスト後半のリグレッションテストを行いたいタイミングのときはそんなに潤沢に時間がないときが結構あります
3.6. そんなときは、主要導線が死んでいないか、の確認に留めることもあります
3.6.1. この場合はまつは「スモークテスト目的の探索的テスト」を実施することも多かったです
3.6.2. 全体をサラッと確認できるためです
3.6.3. ただこういった場合は探索的テストよりも業務シナリオを通すといったほうが安心できます
3.6.4. そのへんの業務シナリオもまつ的にはE2E自動テスト化しておくのがいいかなーと思っています
4. バグ出し目的の 探索的テストの戦術
4.1. まつ流のバグ出し目的の探索的テストは、テストケースを実施後
4.2. つまり「だいたい仕様にあるところの確認が終わった」後に行うことが多いです
4.3. では、バグ出し目的のまつ流の探索的テストの戦術です
4.3.1. 概要としては、システムを各機能に分割して、各機能をメンバーに割り当てて探索的テストですが
4.3.2. さきほどと違って、セッションごとに1機能ずつスライドさせて確認していきます
4.3.3. また、途中掘り下げた方がいい部分が見つけたらスライドを打ち切って、その部分に集中するセッションを挟みます
4.3.4. これは例を聞いた方が早いでしょう
4.3.5. 先ほどと同じで分割は機能でもストーリーでもページでも、わけやすいものでわけましょう
4.4. 例
4.4.1. 例えばシステムがA,B,C,Dの4機能
4.4.2. メンバーがXさん、Yさんの2名だったとします
4.4.3. 探索的テストとしてはセッションベースドの探索的テストで進めます
4.4.4. セッションの1回目は
4.4.4.1. XさんはA機能の探索的テスト
4.4.4.2. YさんはB機能の探索的テスト
4.4.4.3. 時間は40分です
4.4.4.4. 目的は「イタズラや、仕様に載っていないような手順を行って違和感があるところを見つける」です
4.4.4.5. テストチャーターは強いて上げるならば「仕様書」です
4.4.4.6. 慣れているメンバーが多いのであればチャーターなしに自由に探索的テストをしてもらったほうがバグは出やすいと思います
4.4.4.7. セッションが終わった後は、どんなことがあったか共有です
4.4.4.8. まつはマインドマップにやったことを残しながら進んでいました。見せやすいので
4.4.5. セッションの2回目は
4.4.5.1. XさんはB機能の探索的テスト
4.4.5.2. YさんはC機能の探索的テスト
4.4.5.3. 機能を一つスライドした形ですね
4.4.5.4. 時間や目的は同じです
4.4.6. セッションの3回目は
4.4.6.1. XさんはC機能の探索的テスト
4.4.6.2. YさんはD機能の探索的テスト
4.4.6.3. 時間や目的は同じです
4.4.7. セッションの4回目は
4.4.7.1. XさんはD機能の探索的テスト
4.4.7.2. YさんはA機能の探索的テスト
4.4.7.3. 時間や目的は同じです
4.4.7.4. これで一周しましたね
4.4.8. 図にするとこんな感じです
4.4.9. 1機能について複数名の目を通す探索的テストです。
4.4.9.1. 探索的テストは人によって成果が変わるので複数名でガッツリバグ出しをしてもらう形ですね
4.4.10. もちろん全員同時に同じ機能を見てもいいです。
4.4.10.1. その場合、たまにみんな同じバグを追いかけまわしてたりしてるので注意です
4.4.11. セッション中に、あらたに問題点が見つかることも多いと思います
4.4.11.1. その時は次に行かず、その部分を集中して確認するような探索的テストを挟んだりします
4.4.11.2. 詳しくはこちらで説明しています
4.4.11.2.1. 【第10回】セッションベースドの探索的テストのやり方【テスターちゃんねる】
4.4.12. 余談ですが、最初の6機能、3名だとこんな感じに指揮すると思います
4.4.12.1. 図
4.4.12.2. こちらも1機能2人の目が通るような形です。
4.4.12.3. 担当機能を一つずつスライドさせて3重チェックもいいですが、2名で十分だと思います。時間もかかりますしね
5. まつって誰？
5.1. 新人さんからわかるソフトウェアテスト解説マンガ『テスターちゃん』作者
5.1.1. https://www.amazon.co.jp/dp/4863543026
5.2. 勤め先ではQA組織所属。テストのコンサルタントのイメージ
5.3. JaSST Kyushu(ソフトウェアテストシンポジウム九州) 実行委員長
5.4. QA4AI(AI プロダクト品質保証コンソーシアム)でガイドラインのVUI領域(音声認識、自然言語理解、音声合成)担当
5.5. 会社でもプライベートでもテスト系のことをしてる変な人
6. 今回の概要
6.1. これまでの動画で探索的テストのやり方を説明してきました
6.2. 今回はシステムテストの時に「この場面ではこういう探索的テストの方法を使う！」
6.3. という「まつ流の探索的テストの戦術」を話したいと思います
6.4. あくまで、まつがテスターとして現場で用いたやり方です
6.5. 一般的に言われているものではなく、まつの経験の紹介であるという事にご注意ください
6.6. （というか、一般的にこういう話が言われているのは聞いたことがないです）
6.7. この順番で話していきます
6.7.1. スモークテスト目的
6.7.2. バグ出し目的
6.7.3. リグレッションテスト目的