この記事は カオナビ Advent Calendar 2023 12日目の記事です。
はじめに
カオナビでQCとして働いている赤﨑といいます。
先日娘の七五三詣で千歳飴を買って食べて歯の詰め物が取れました。千歳飴は噛まずに食べるのがおすすめです。
SQiPシンポジウム2023で「アジャイルと反復開発～忍者式テスト20年の実践から〜」の講演を聞き、実際に試してみたので、今日はその感想を書こうと思います。忍者式テストを試してみたい方に読んでほしいです。
「アジャイルと反復開発～忍者式テスト20年の実践から〜」はSQiPシンポジウム2023やスクラムフェス三河2023で、キヤノンメディカルシステムズ社の深谷美和さん(@miwa719)と関将俊さん(@m_seki)が発表していたテーマです。
スライド
https://www.juse.jp/sqip/symposium/timetable/files/B3-2_happyou.pdf
Youtube
https://www.youtube.com/watch?v=NW8vKNxcoks
なぜ試してみたいと思ったか
私の所属するチームではリリース前のUndone Workとしてリグレッションテストを行っており、いつかUndone Workから取り除きたいと考えていたのと、テストは足りてるのか漠然とした不安があったので、講演で紹介されていた 忍者式テスト に興味を持ちました。また 受け入れテスト駆動開発 もテスト実施中に検知される考慮漏れの削減につながると思い、何かしらの形で取り入れたいと考えました。
忍者式テストをやってみた
そこで忍者式テストを実際にやってみました。
前提
とにもかくにも忍者式テストを1周し、効果を実感したいと思いました。
ただ既存のストーリーテストケースに沿って進めると1周できる気がしなかったのです。そこでストーリーチケットの受入基準に着目しました。ストーリーチケット1件あたり5項目程度で構成されている受入基準に沿って進めれば1周できそうな気がしたので、まずは受入基準に沿って手動テストを始めることにしました。
チームで開発したストーリーチケットとバグチケットすべてを対象に、1日1時間チームのQC3人で進めていきました。開始時点ではおよそ600チケットあったので、1日10〜15チケットを消化したとして2.5ヶ月程度で1周できると想定して開始しました。
初めての取り組みで試行錯誤したかったため、QC3人とも毎朝11:00-12:00を忍者式テストタイムとしslackのハドルをつないで、テストによって得られた情報はもちろん、取り組みに関するメリデメや違和感を対話しながら作業を進めました。
講演の中で紹介されている 本日のおすすめテスト はアルゴリズムが理解できておらず、次回テスト実施日を管理するフィールドもなかったため、最終更新日が古いチケットから順に進めることにしました。
結果
意外にも1周するのにかかった期間は1.5ヶ月でした。想定よりも1ヶ月早く終わったのは、すでに他のストーリーチケットによって古くなったストーリーが数十件あったり、バグチケットはストーリーチケットよりも軽いためサクサク進められたことが要因と思われます。
不具合や使用性の課題が週に1個は見つかり、ものによってバックログに積んだものもあります。
それは嬉しくもあり悲しくもあり、複雑な心境でした。ただやってみて一番よかったのは、QCの間でテストに対する自信が湧き、変更に対する不安が減ったことでした。こちらは１周した後の振り返りで上がった意見です。
またハドルを繋いで作業を進めましたが、これは違和感を感じた挙動について、すぐに画面共有して意見を募れるメリットがありました。
NextAction
忍者式テストがなくなると思うと不安になった私たちは2周目を開始しました。2周目では以下のルールを追加して取り組んでいます。
本日のおすすめテスト の運用にチャレンジ
次回テスト実施日のフィールドを追加し、テストを終えたチケットに都度次回テスト実施日を入力するようにしました。今着手しているストーリーに影響しそうなものは3営業日後、そうでないものは1ヶ月後に手動で設定しています。自動化の方法がまだイメージできておらずアナログです。
そして、チームで開発した製品を構成するチケットのうち、次回テスト実施日が本日以前のものに絞って本日のおすすめテストフィルタを作りました。本日のおすすめテストを全て消化したら、おすすめ以外のチケットをまた最終更新日が古いものから順に進めるようにしました。
忍者式テスト用のハイレベルテストケースを作成
まずは受入基準に沿って実施していましたが、そのやり方ではテストをよりよくし続けることができないと思い、忍者式テスト用のハイレベルテストケースを作成することにしました。既存の使い捨てにしていたストーリーテストケースを手直しするか悩んだのですが、同時に読んでいた ソフトウェアテストをカイゼンする50のアイデアの「テストを作業項目に沿ってグループ化したり構成したりすることは避けよう」を読み、たしかに現在の運用では数年後ストーリーが数倍に増えた時に適用できるイメージが湧かなかったため、既存のストーリーテストケースを参考に、新しくハイレベルテストケースをユーザーのワークフローに従って再構築することにしました。
受け入れテスト駆動開発にチャレンジ
忍者式テストを試しつつ、受け入れテスト駆動開発の要素を盛り込まないか試してみることにしました。
いきなりテスト計画、分析、設計を開発チームみんなでやるのは、チームにとって大きすぎる変化だと思ったので、まずはQCのみで具体的なシステムのふるまいを受入基準に追記する活動を行いました。
前提
これまでストーリーチケットは以下の流れで利用されていました。
- POがユーザーストーリーと受入基準を記載
- 開発チームでリファインメントを実施
- ENが実装し、QCがテストする
この2と3の間で、テスト分析から見えたシステムのふるまいをQCが受入基準に追記するという行為を開始しました。こちらも規模に向き合うため、バックログリファインメントのような感覚で、テスト分析を行う時間を週に1,2時間確保し、次のスプリントで着手予定のストーリーチケットにふるまいを書き足したり、テスト設計タスクチケットの起票、紐付けを行いました。私の所属するチームではこれをバックログテスト分析と呼んでいます。
結果
上記前提の2と3の間のタイミングは、まだ当該ストーリーチケットを扱うスプリント前なので、インスプリントでテスト分析を行うよりも余裕を持ってテスト設計できました。また実装前に受入基準の不備や矛盾に気づくことができるようになりました。
NextAction
同じくチームにとっていいプラクティスなので以下の要素を追加して継続することにしました。
開発チームみんなでテスト分析にチャレンジ
数ヶ月試して気づいた課題として、受入基準の不備に気づいて追記したところまではよかったのですが、実は他ストーリーチケットの受入基準にも追記が必要だったのにそれに気づかないことがありました。それは実装終盤に発覚したのですが、ENと対話しておけばテスト分析の段階で防げた可能性があったものでした。
そこで次のスプリントからバックログテスト分析を開発チームみんなでやってみることにしました。
さいごに
上述した点から「アジャイルと反復開発～忍者式テスト20年の実践から〜」を聞いてよかったし、試してみてよかったと思います。まだ改善点はたくさんありますが、大事なテストを十分にやり続けられるように試行錯誤を続けます。
We Are Hiring
株式会社カオナビでは一緒に働く仲間を募集しています。カジュアル面談も行っていますので、ご興味がある方は気軽にお声がけください。