「より良いテストへの一歩　〜 そのテスト設計・計画、最適ですか？ 〜」に参加した

9/16にオンラインで開催されたVisionalさん主催の「より良いテストへの一歩　〜 そのテスト設計・計画、最適ですか？ 〜」の勉強会に参加してきました。(ビズリーチさんの会社の体系が変わって、Visionalの中のグループ会社になったらしい。知らなかった。)

発表1：テスト活動の納得感を持ってテストケースを激減させた話

●今までの問題点

• プロジェクトの体制としては開発チームとQAチームが分れていて、QAチームは1スプリント前の成果物をテストする流れだった
• 1スプリント前の成果物のテスト設計、実施を行うことになり、開発とQAの作業が分断。既に次スプリントを開発している開発チームとの連携に時間がとられていた。
• QAチームの中で各自の作業の進捗が見えづらい状況。

●改善したこと

• 同じスプリント中にテスト設計を開始するようにプロセスを変更
• テスト設計のレビューも細かい粒度で実施するようにした。先にテストパターンを洗い出すなどの工夫。
• プランニングポーカーでSPの算出。SPによるタスクのアサイン。
• タスクの見える化(タスクがdoneしていない場合、テスト実施が終わっていないのか、テストの修正中なのかが分からない状態だった。タスクを細かい粒度で分けるようにした。)

今までテスト設計・実装が混ざっていたが、テスト設計を手厚くすることでテストケースを減らす動きができるようになり、結果テストケースの削減に繋がったというお話でした。 今までどちらかといえば過剰になっていたテストケースが適切なテストケースで設計されるようになったということなんだろうな、と思います。

先のテストケースの洗い出しをしてレビューしてもらうのは、普段の開発でも使えるなーと思いながら聞いていました。TDDで開発する前にテストケースを先にレビューしてもらって開発すれば、過剰なテストコードを書かなくてすみそう。逆に不足しているテストケースも早めに知ることもできそうだなー。

わたしの会社でもスクラムで開発をしていますが、先に全ての実装を終わらせて後半のスプリントでまとめてテストをする流れが多いです。途中で仕様が変わることがあり、同じテストを再度する必要があるなら仕様も固まるであろう後半でまとめてテストした方が効率がいいだろうという考えからなのですが。

TDDと同じで早くデバッグするという考え方なら、都度成果物をテストしていく方が効率がいいのかもしれないなー。

まとめ

• 2個めの「いまさら聞けない、テスト対象機種の選定方法」の発表は業務の関係で参加できませんでした。。。
• スクラム開発のテストの仕方に興味があって参加したのですが、同じスプリントで同じスピードでテストを実施してもらえるのは、開発側としても有難いだろうなー。
• そういえばオンラインの勉強会って初めて参加したのですが、業務しながらでも発表を聞けるのがとても助かった(急に仕事が定時で終わらない状態になってしまったので)