こんにちは、とのの（@tonono2587）です。
先日、テスト設計チュートリアルに参加してきました。
当日の動画と、資料があがっていますので本編はそちらを確認してください
動画
https://youtu.be/9deZfaEjME8?si=xzPymMHa6JBcDbBb
資料
テスト設計コンテスト
大事だと思ったこと
ひたすら挙げます 続く文は詳細とか、感想
属人的に行われがちなテスト設計を、再現性のある「プロセス」へ
特にチームに1人しかいないと、魔法みたいに思われがちだと感じていた。
プロセスというのは再現性を出すためのものなんだ、と聞いてやる気が出た。
（最近(？)"再現性"を出したい）
二重にやることで、間違える可能性を最小限にするのがテスト活動
もともとは複数人でやるから生まれた活動なのかもしれないけど、
開発とテストで二重の確認ということは、一人でも何人でも必要なことだと思った。
段階に合わせた確認が必要
テストレベル：段階的な品質確認用
テストタイプ：特定の目的にフォーカスした、テストの"分類"
テストフェーズ/テストサイクル：テスト活動をプロジェクト内でマネジメントしやすくまとめた、
テストレベルの実行活動。どういう順番で実行するか決めた"まとまり"
「プロセス」にすると何をしているか明確になる
いつ、誰が、何をするかわかっていれば、他人が理解できる
”準備”というだけではわからない。（人によって違うし、すぐ終わりそうだし）
プロセスとして定義することでやることと必要性がわかり、再現性が出る
再現性を出したい人なので、定義したらいいのか！と思った。
少しでも多くテストするよりも、何をするかのほうが大事
テスト開発プロセスの中でテストを効果的にするには、
リスクの早期発見とリスクの評価が求められる
リスクマネジメントの手段としてのテスト
リスクには2種類ある
プロジェクトリスク：（計画リスク）間に合わないかも、お金足りないかも
プロダクトリスク：（品質リスク）お客さんに迷惑がかかるかも、使わないかも
テストで見るのは「プロダクトリスク」
わたしはプロジェクトリスクも結構気にしていて、
チームへフィードバックすることも多い。だからPMっぽい動きをしがちなのかなと思った。
けど計画リスクはテストしなくてもわかることだから、お金とか期日とかリソースとかを把握している人がちゃんとやらないとねと思う。
テスト開発プロセスは、順序やグルーピングは流派で違うが、飛ばすことはできない
どこかで必ずやらないといけないことは何かを「考えて」効率よくやるのが大事。
考えるのがテスト設計
飛ばすことができないということは、何かしら絶対やってるはずで、
広くグルーピングされていることもあるのかも
順番も変えていいということは、余計組み合わせがいがある。
基本的な順番や、各工程でやること
突然の手書き
わたしは要求分析のときに、プロジェクトリスク入れがち
他の人とやっていくうえで大事なこと
- 文書は読み手にわかりやすく コードと一緒
- 工程の一貫性があること
成果物を作っただけで使わなかったら作る意味がない。各活動の成果物は繋がっていることが大事 - 基本ができたうえで初めて評価される まず正しく使えていることが大切
整理、構造化、的を射たテストをつくる力 が技術力
あなたの腕の見せどころ！と話されていて燃えた
できたらかっこいい！
テスト戦略について質問した
テスト戦略やテスト計画は、テストをつくるまえにやる活動だと捉えていた。
今回のテスト開発プロセスで出てこかなったので、
「テスト戦略」っていつたてるんですか？と質問した。
今回の説明では分け方・切り口が違うだけ、と回答をもらってスッキリした。
テスト要求分析などでたてることが多いかも。
その他感想
何事も効率をよくすることにかなりの喜びを感じるタイプなので、
テスト開発ってやりがいがあるし、向いてるかもしれないなと思いました。
順序も、グルーピングも違っていいと捉えると、説明ができればどんな内容でも大丈夫で、
「説明できること」の大事さを再認識しました。
おしまい
参加してよかったです！
