Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Agile testing ~in my case~

Matsu
July 24, 2022

Agile testing ~in my case~

This is agile testing in my case.
For each feature, we perform exploratory testing to look for large overall bugs, followed by test case execution, followed by exploratory testing to look for minor bugs.
Once the features to be released are in place, regression testing of the entire system is performed.
In addition, an e2e automated test that performs an overall check is rotated daily.

Matsu

July 24, 2022
Tweet

More Decks by Matsu

Other Decks in Technology

Transcript

  1. Agile開発でのテストのやり方 ~ 私の場合 ~

  2. 松谷峰生 (まつやみねお) 役割 • WEB QA • JaSST Kyushu共同実行委員長

  3. QA4AIコンソーシアム http://www.qa4ai.jp/

  4. マンガ http://testerchan.hatenadiary.com/ 新人さんからわかる ソフトウェアテスト解説マンガ 「テスターちゃん」

  5. 私が経験した Agile開発

  6. Agileといっても みなさんが思い浮かべる形はそれぞれなので 最初に私が経験した テストチームと開発チームの 関わり方を紹介します

  7. 餅つき型(※今命名した) スプリント テスト 開発 〇機能ができました! テストします! 完成した機能から テストが来る スプリント中、餅つきのように開発/テストを繰り返す。 スプリントの終わりにテストが完了している機能をリリース。

  8. 切れ間なくテストが続く

  9. 管理メイン型(※今命名した) スプリント スプリントの前半に開発、後半にQAを行う。 スプリントの終わりにリリース。 工程が分かれているのでスケジュール管理が行いやすい 開発 修正など テスト準備 テスト実行

  10. これってミニウォーター(ry

  11. リリースサイクルが早いのが問題 テストをどうやっていけばいいんだ?

  12. ~ 私の場合 ~

  13. テスト準備

  14. JSTQBのテストプロセス(準備部分) テスト 計画 テスト 分析 テスト 設計 テスト 実装

  15. あてはめてみる スプリント 開発 修正など テスト実行 テスト計画 テスト分析 テスト設計 テスト実装

  16. かなりツライ ツライものは いつか回らなくなる

  17. (個人) 仕様書の 読み込み みんなで一緒にテスト観点出し 仕様書を読んだ後、テストメンバーが集まって テスト観点出しを行う。 どこを気を付けるべきか、どんなテストをしたらいいか共有できる みんなで一緒に テスト観点出し 認識合わせ

    テスト観点の共有 疑問点の洗い出し
  18. テスト観点出し後の準備 みんなで一緒に テスト観点出し 疑問点を 企画/開発に質問 テストケースに落とした ほうがいいところは テストケースに落とす 全体チェックリストに 新仕様部分追記

    ※システム全体の主要機能を30分くらいで 確認するための簡易的なチェックリスト
  19. テスト実行

  20. 管理メイン型の場合(※さっき命名した) 一次探索的テスト (スクリプトテスト) 二次探索的テスト リグレッションテスト リリース後テスト スモークテスト目的。早めに大きいバグを出して テストできないところの把握、開発の修正工数を確保した い 組み合わせが複雑なところ、テストがメンドイ場所などは

    テストケースを用いて確認する 複雑な手順でのバグなどの導出が目的 バグ修正が終わった後の仕上げのテスト。 先ほど登場した全体チェックリストを用いて 確認することが多い。
  21. 一次探索的テスト(スモークテスト目的) 探索的テストは機能と時間を分けたセッションベースドで実施。 なるはやで実装機能全体をなめたい。 【例】:機能(A機能、B機能、C機能、D機能) テストメンバー(Xさん、Yさん) テストチャーター:仕様書 A機能:Xさん B機能:Yさん セッション1 :

    40分 セッション2 : 40分 テストチャーター:仕様書 C機能:Xさん D機能:Yさん
  22. 二次探索的テスト(細かなバグまで出したい) A機能 B機能 C機能 D機能 セッション1 Xさん Yさん セッション2 Xさん

    Yさん セッション3 Xさん Yさん セッション4 Yさん Xさん 細かなバグを出したいときの探索的テストのスタイル チャーターは特になく、それぞれに任せる。 探索的テスト絨毯爆撃型と名付けた。
  23. 餅つき型の場合(※さっき命名した) A機能 一次探索的テスト (スクリプトテスト) 二次探索的テスト B機能 一次探索的テスト (スクリプトテスト) 二次探索的テスト C機能

    一次探索的テスト (スクリプトテスト) 二次探索的テスト リグレッションテスト リリース後テスト
  24. 自動テスト

  25. 自動テスト(リグレッションテスト目的) 一次探索的テスト (スクリプトテスト) 二次探索的テスト リグレッションテスト リリース後テスト 自動テスト 今回 追加された機能 「以外の」

    主要部分の テストが回っている テスト完了後に 実装機能で追加した方がよい項目は追加
  26. まとめ

  27. 一連の流れ 一次探索的テスト (スクリプトテスト) 二次探索的テスト リグレッションテスト リリース後テスト 仕様書読み込み みんなでテスト観点出し (テストケース作成) 全体チェックリストに追記

  28. ご清聴ありがとうございました!