QAコーチと学ぶ テスト戦略

QAとテストに関する発表会@福岡天神 #テストラジオ

テスト戦略の考え方をまとめてみました。
① プロダクトの理解
② テストで何をするのかをまとめる
③ テストの協力者を探す

これらがスタートに必要になります。

Transcript

1. QAコーチと学ぶ テスト戦略 なそ＠さとう ひろゆき QAとテストに関する発表会@福岡天神 #テストラジオ
2. 自己紹介 •QAやテストに関わって10年。SIは５年くらい。 •アジャイルの中のQAとかを考える。 •短いライフサイクルを好む。 •主業務はWFの提案書が多め。 本スライドの内容は個人の意見であり、 特定の団体やなにかは関係ないです。 最近Xのアイコンを変えました
3. テストラジオのメインパーソナリティ チャンネル登録、高評価よろしくお願いします
4. これから話す中で ネタが古いので、わからない人が 聞き飛ばしてください
5. タイトル • なんか書いてある • なんか書いてある • なんか書いてある リアル発表とかだと この辺は書かないとか本当はあるんだけど 今回は気にしていないです。
6. タイトル • なんか書いてある • なんか書いてある • なんか書いてある リアル発表とかだと この辺は書かないとか本当はあるんだけど 今回は気にしていないです。
7. こんなことがありました •テストの全体が見えずに、 どこまでテストすればよいかわからない。 •今やっているテストだけじゃ、足りない気がする。 •テストの改善ができることベースで、 このままでいいのかな。
8. テストケースを考える前に、 プロダクトを把握しよう
9. テスト戦略を進めるときのポイント ①プロダクトの全体を眺めてみる ②テストで何をするかを考える ③テストの協力者を探す
10. ① プロダクトを眺めてみる • プロダクトの構成を考えてみる。 • (例) Web系 • 画面（ブラウザ） • API等のバックエンド • データ保存するDB構造 • インフラ • 外部連携（APIやCSV連携） 外部連携を分けるのは自分たちの範疇で 仕様や改修ができるかどうかを判断できる ようにする。
11. ② テストで何をするかを考える • テストタイプやテストコンテナ等の「何を」テストするのかを まとめたもの。 • 単体テスト、単機能テスト、画面テストは人によって認識が異 なるので、開発者交えて言葉合わせをしてみる。 • プロダクトの仕様が難しいところ、作りが複雑なところを開発 者に聞いておくとテストのボリュームをコントロールしやすい。
12. ③ テストの協力者を探す •開発者以外にも手伝ってくれる人はいる（はず）。 • 個人的にはホワイトボックスのテストは開発者にやっ てもらったほうが効率が良い。 • 最初のうちは開発者のテストをレビューした方が良い。 •プロジェクトマネージャ、リーダー、マーケとか も協力してくれるはず。 •ユーザーテストとかするなら誰が音頭をとるのか も決めておく。
13. 高速にゴミつくる人は開発者 じゃねーよ！！ と言える 勇気
14. まとめてみるとテストの全体が見える ① プロダクト ② テストタイプ ③ 協 力 者 対象とか注意事項とかの 星取をやってみる
15. まとめてみるとテストの全体が見える ① プロダクト ② テストタイプ ③ 協 力 者 対象とか注意事項とかの 星取をやってみる
16. テスト戦略を考える •テストの手段を考える •協力者と一緒に進める方法を考える •いつテストができるかを確認する
17. テストの手段を考える • 自動テスト？手動テスト？探索的テスト？ • シナリオで確認する？機能を確認する？ • OK、NGで判断できる？ • テストデータって誰が準備するの？ とかとか
18. 戦略を考えるときのポイント • （発展）現状から発展させるあるべき姿 • （白）なにもないまっさらな状態から考えるあるべき姿 ｔ 今 発 展 白 めっちゃ しんどい 個人の感想です Q A イ ケ イ ケ 度 QP
19. 戦略を考えるときのポイント • （発展）現状から発展させるあるべき姿 • （白）なにもないまっさらな状態から考えるあるべき姿 ｔ 今 発 展 白 現状を変えなが ら進められる 個人の感想です Q A イ ケ イ ケ 度 QP
20. いつそれらが完成するかの順番を考える • ３０年後に出来上がる話ではなくて半年、１年、３年でできる ことを考えてみる。 • 考えたことを半分の期間で達成するためには何があればできま す？と考えてみてください。それが上司に相談することになる かも。 • その状態を思い出せるように定期的に見てみよう。 （更新日がXX月前とかだと形骸化しちゃっているかも）
21. ポイント 慣れたら1時間くらいで やってみよう スクラムとかだとスプリントプランニング中に 終わるくらいがベスト
22. テスト戦略のその先
23. プロダクトに対してテスト戦略を考えた • これからやるテストは大丈夫？ • これからやる機能にテスト戦略を当てはめてみる。 • 少しずつ適用してみる。一気に変えたらみんな困惑しちゃう。 小さく適用してみて、その結果を テスト戦略にフィードバックする
24. テストのボリュームやばいこ とになったよね？ 上司にこのテストやらなくていいですか？って 聞いたら、やりたいよね。やろうよってなるよね。
25. やれること、できないことがあるから、 なにか取捨選択をしないと • テストケースの実行もそうだし、バグが見つからないテスト ケースの実行もそうだし、これってなんでやっているんだっ け？とか迷うよね。 • テストってQAの持ち物？プロダクトチームの持ち物？誰の持 ち物だっけ？ • 何したらいいんじゃろね？わっかんないや
26. 取捨選択って難しいですよね
27. 取捨選択するときのポイント • リスクはどこにあるのか？ • 絶対に外せないシナリオはどれ？ • 代替案や他の手段は取れる？（意外とある） 無理って言われたリスケが 期限間近になったら何故か通ったりする・・・ あ れ れ 〜 お か し い よ 〜 !!
28. 責任範囲を絞っていない？ • 契約形態(業務)と良いプロダクト(想い)を作ることを切り分ける。 • 混同するとだいたいうまく行かない。 • 他責思考に陥りやすい。 • 何でもかんでも抱えるのも良くない。
29. テストケースを考え始める 〜テスト設計〜テスト実装〜 ここは大丈夫でしょう
30. テスト実行するまでが仮説。 テスト実行が検証 検証 レポ ート 仮説 テスト戦略 テスト計画 テスト設計 テストケース作成 テストデータ作成 などなど・・・ テスト実行 バグ起票 テストレポート 改善案策定
31. 仮説がめっちゃ長い。検証は一瞬。 テストレポートしんどい • テストレポートは定量、定量結果から判断できる考察、定性、 改善を記載するとよいと思っている。 • この定量結果が良いのかどうかは過去の実績やIPAのソフト ウェア白書等の結果から判断する。 • が、だいたい記載するまでもなくいたたまれない結果のことが 多かった（経験談） • 類似の観察ではなく、自身のプロダクトの過去との比較がよい。 • リリースサイクルが早いプロダクトには、傾向分析が有効。 定性は定量化できるが、逆は不可逆。
32. だからこそ、検証の結果を戦略にフィー ドバックする •自動テストで全部やろうとしちゃう。 •探索的テストで機能仕様を確認しちゃう。 •全部探索的にやろうとしたりしちゃう。 •とりあえず手動テストにしていない？
33. 次は何をしてみたい？小さな改善は？ • 小さな改善をおすすめするのは、人間の記憶容量は小さい。 • 昨日の晩御飯はきっと覚えている。１年前の晩御飯は覚え ています？（私は覚えていないです。昨日も怪しいけど） 大きなトラブルや困ったことは覚えているから、 自分たち以上のことに目が向きがちになる。 改善ではなく愚痴大会や反省会になってしまう。
34. 困ったり、区切りがついたら戦略との 差分を考えてみる •現状に縛られていない？ •理想だけで進めていない？ •他社や発表事例だけで会話していない？
35. 最初は憧れでOK！ やってみて改善 してみて、良くしていく。
36. やってみないと人は自分事にできない （事が多い）
37. おわり