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.1.1. 決めたことが決めた通りになっていることを確認する活動
2.2. テスティング
2.2.1. バグがないか探索しにいくなど、新しい情報を探し出す活動
2.3. 質問と回答
2.3.1. 仕様通り動くかのチェックだけでよくない？
2.3.1.1. リスクをどこまで許容できるか
2.3.2. 自動テスト最強！俺たちはこれ一本でいく！
2.3.2.1. 自動テストではテスティング部分は通らない
2.4. どちらが大切というわけではなく、チェッキングとテスティングの組み合わせが大切
2.5. 巷であれこれ言われているシステムがありますが
2.6. テストを雑に考えてると、明日は我が身になるかもしれませんよ……
3. こういった質問のまつの回答
3.1. 仕様通り動くかのチェックだけでよくない？バグ出たらリリース後に直すし
3.1.1. それでみんなの合意が取れていたらOK
3.1.1.1. 品質目標といったりします
3.1.2. 例えば最初のiPhone
3.1.2.1. リリース後にバグがいっぱいあったけど
3.1.2.2. まずは市場へ早く投入してインパクトを狙った
3.1.2.2.1. メリットがリスクを上回った
3.1.3. 例えばcocoaのandroid
3.1.3.1. 市場に出てから感染者との接触通知が来ないことが判明
3.1.3.2. リリース後修正
3.1.3.2.1. が、信用は失墜
3.1.4. リスクをどこまで許容できるか
3.2. 自動テスト最強！自動テストさえあれば、もう何も怖くない
3.2.1. これもチェッキングとテスティングの考え方
3.2.2. unittestやAPIのテスト、E2E自動テストでチェッキング部分はOK
3.2.3. 例えば機能の追加や、施策実施のとき
3.2.3.1. リグレッションテストなど決められた通り動くかのチェッキングはできる
3.2.3.2. 「こうすればどうなる？」「あの機能との兼ね合いどうなってるっけ？」などテスティング部分は通らない
3.2.3.3. 「仕様通り動けばOK」と同じ状態
3.2.4. 自動テストはテストの１手法でしかない
3.2.4.1. 他の手法と組み合わせてテストする必要がある
4. テスティング
4.1. バグがないか探索など、探索などを通し「新しい情報を探し出す活動」のこと
4.1.1. ちゃんとした定義はこちら
4.1.1.1. Testing and Checking Refined
4.1.1.2. テストとは、質問、学習、モデル化、観察、推論などをある程度含む、経験、探索、実験を通して製品について学ぶことで、製品を評価するプロセスです。
4.1.1.3. 使ってみて気になること
4.1.1.4. 思ったこと
4.1.1.5. わかってきたこと
4.1.1.6. そういったことを通して評価する活動
4.1.2. 深掘りすると余計に分からなくなるのでまとめると
4.1.2.1. チェキングのように期待結果が決まっていてそれをチェックする活動もあれば
4.1.2.2. 「これってどうなるのさ？」のようオープンクエスチョンで調べたりアレコレ試して
4.1.2.2.1. 「大丈夫だったねよかったね」
4.1.2.2.2. 「やばくね？」
4.1.2.2.3. がわかる活動もあるわけです
4.1.3. やり方は、例えば探索的テストがあります
4.1.3.1. 探索的テスト カテゴリーの記事一覧 - テスターちゃん【4コマ漫画】
4.1.3.2. 【第3回】バグを見つけるコツ7選＋α【テスターちゃんねる】
4.2. テスティングは自動テストにあまり向かない
4.2.1. プログラムは「これってどうなんだっけ？」とはやってくれない
4.3. テスティングで必要な思考
4.3.1. 開発時は問題領域を狭めていった
4.3.1.1. その過程で情報が落ちたり考慮漏れが発生する
4.3.2. テスティングでは、逆に「問題領域を広げていく」思考が必要
4.3.2.1. テスターさんに求められる思考、能力
4.4. 決まりごとのチェックに加えて、問題を探しに行く活動が大切
4.4.1. 知識
4.4.2. 経験
4.4.3. 好奇心や遊び心
4.4.3.1. 「こうしたらどうなるんだろう？」を試してみよう
5. チェッキング
5.1. 決めたことが決めた通りになっていることを確認すること
5.1.1. 開発者がメインで携わるテストはチェッキング
5.1.1.1. unit test
5.1.1.2. APIのリクエストに対するレスポンスの確認
5.1.2. E2E自動テストもチェッキング
5.1.3. （チェッキング部分は自動テスト向き）
5.2. 「決めたことが決めた通り動く」は「最低限守られるべきところ」
5.2.1. 超重要な活動
5.3. 開発者の思考はチェッキングに寄りがち
5.3.1. 図
5.3.1.1. 僕が尊敬する方の資料
5.3.1.1.1. http://www.jasst.jp/symposium/jasst18kyushu/pdf/S6.pdf
5.3.1.1.2. 31P~
5.3.1.2. フワッとした要求から
5.3.1.3. 具体化して要件
5.3.1.4. システムで表現できるように仕様に落とす
5.3.1.5. どんどん問題領域を狭めていって「こうすればこうなる」を設計・実装
5.3.1.5.1. 「こうすればこうなる」があっているかの確認
6. 最初に結論
6.1. 決めたことが決めた通り動くことをチェックする
6.1.1. チェッキング
6.2. 問題点を探索しにいく
6.2.1. テスティング
6.3. この二つがそろって「よいテスト」になる
7. 現場あるある：仕様書通り動くかのチェックだけしてリリース
7.1. よく見かける現場
7.1.1. 仕様書をコピペしたテストの項目を作って
7.1.2. それにPass/Failをつけて
7.1.3. テストの項目が終わったら「本番障害出ませんように…！」と祈りながらリリース
7.1.4. そして本番障害発生！
7.1.4.1. 「そこ！？ あーもうちょっと考えてたら事前に見つけられてたのに！」
7.2. これだとバグは出ます！
7.2.1. なぜなら、他にバグがないか探すような活動をしていないから
7.3. 例えば（まつの想像だよ！）
7.3.1. 【仕様】登録番号で予約が可能なこと
7.3.1.1. 【テストの項目】登録番号で予約が可能なことを確認する
7.3.1.2. 登録されていない番号はどうなる？
7.4. テストの目的
7.4.1. 「決めたことが決めた通りに動く」
7.4.2. 「バグを見つける」
7.4.3. 【第2回】テストの目的7選【テスターちゃんねる】