トップ > AdventCalender > 開発タスク管理フローに便乗してテスト関連タスク管理を(精神的に)楽にしたかった

開発タスク管理フローに便乗してテスト関連タスク管理を(精神的に)楽にしたかった

AdventCalender GitHub QA Webサービス アプリケーションテスト チームマネジメント 技術 reviewed

このブログでは商品紹介にはてなブログ標準機能のAmazonアソシエイトを利用しています

これはソフトウェアテスト Advent Calendar 2019 - Qiita 4日目のエントリです。

@wifeofvillonです。Drivemodeという会社で自社プロダクトのE2Eテストを主業務としており、最近はいい感じのテストマネジメントを模索しています。 このエントリでは現在進行形で体験・実行している「開発タスクマネジメントにQAチームとして便乗するための取り組み」について書きます。

何が起こっているか

現在Drivemodeとは別のアプリの開発プロジェクトが走っています1。

ほとんど総力戦のような状態になっているため、既に開発に組み込まれていたメンバーとは別にCertified Scrum Professional®を取得しているメンバーが開発タスクのマネジメントをしてくれる体制になりました。とはいえ要件が決まりきらない箇所が多く、きっちりスプリント計画を立てるのが難しいため、小規模なウォーターフォール開発にアジャイル開発のプラクティスを持ち込んだような変則的な運用になっています。

この体制の中にQAチームもまぎれ込んで、同時にマネジメントしてもらうための取り組みを行いました。今回はその泥臭い取り組みの内容を撮って出し2で書きます。

開発タスク管理フローについて

前提として、今回の開発タスク管理フローは以下のようになっています。

  1. 開発タスクをGitHub Issuesに切り出す
  2. 切り出したIssueをGitHub Projectsのカンバンで管理する
  3. カンバンとバーンダウンチャートを元に振り返りを行う

カンバンのカラムは以下のようになっています。

  • Waiting Design
  • To do
  • In progress
  • Review in progress
  • Reviewer approved
  • Done

各Issueは開発状況に応じたカラムに開発者によって移動されますが、デザイナーの作業が必要であったり、コンポーネントテストのダブルチェックが必要であったりする場合にはそれぞれ「needs UX design」「ready for QA」のラベルを付けます。

基本的にコンポーネント開発のIssueはダブルチェックを経て完了扱いになります3。

また、カンバン上のカードタイトル＝Issueタイトル内に(相対)作業見積が記載されています。開発者同士のプランニングポーカーで算出されたもので、これを元にGoogleスプレッドシートでリリースまでのバーンダウンチャートを作成しています4。

f:id:wifeofvillon:20191202151331p:plain
開発Issueの例

やったこと

前項をふまえQA側は、QAのタスクを開発タスクと同じカンバン上で管理できるようにしました。

  1. QAのタスクを分解してGitHub Issuesに切り出す
  2. Issueごとに(相対)作業見積を行いIssueタイトルもしくはDescription内に記載する
  3. 開発者のレビューが必要なIssueに「needs Developers eyes」のラベルをつける
  4. 作業見積を元にGoogleスプレッドシートでバーンダウンチャートを作成する

タスク分解はまず「要件把握」「テスト仕様書作成」「コンポーネントテスト実行」「統合テスト実行」に分け、そこから機能単位で子Issueを切り出しました。(コンポーネントテスト実行は開発Issueのダブルチェックがそれに当たるので自分では切り出していません。)

作業見積も開発者がプランニングポーカーを用いた相対見積をしていることに合わせてフィボナッチ数の相対見積にしました。自分で切り出したIssueに関しては開発Issue同様タイトル部分に、開発Issueに関してはテスト仕様書・報告書へのリンクの横に記載しました。

今回開発者と一緒に管理されたかった理由の一部として

  • 要件が決まりきっていない箇所がある
  • ユースケースの組み合わせが多くカバーできているか自信がない
  • これを機にもっとテスト仕様書もレビューしてもらいやすくしたい

という気持ちがあったので、開発者がデザイナー・QAに対してそうしているように、開発者のレビューが必要だと感じたIssueに「needs Developers eyes」のラベルをつけるようにしました。

作業見積を元にGoogleスプレッドシートでバーンダウンチャートを作成するところは開発タスクと同じですが、現状では別シートに分けています。

f:id:wifeofvillon:20191202151436p:plain
QAIssueの例

やりたかったけどやれなかったこと

本来は作業見積は開発者と一緒にやれることが理想ですし、実際プランニングポーカーの場にも呼んでもらいました。しかし、開発IssueがQAの作業単位より細かく切り出されていたこと、その時点ではプロジェクトの概要把握もおぼつかず基準として提示されたIssueについて作業量をイメージできていなかったこと5から、作業見積はひととおりのQAタスクをIssueに切り出してからひとりで行いました。

開発IssueがQAの作業単位より細かく切り出されていたというのは、例えば電話の待ち受けモードを変更する機能があったとすると、開発は「電話の着信を無視する」「着信を知らせる」という粒度まで分解されています。これについては別に何もおかしくはないのですが、統合テストで使えるテスト仕様書を作る(そしてテストを実施する)ことをゴールとしているQAの場合、電話の待ち受けモード全体をひとつのタスクにしたほうが条件組み合わせによる結果の違いがわかりやすく、テスト仕様書が書きやすくなると感じました。

バーンダウンチャートも開発・QAをまとめてプロジェクト全体で1枚にできると美しいと思うのですが、今回は作業見積自体別々に行ったのでそれぞれ別シートで管理しています。

(現状)よかったこと

プロジェクト運用に口と手を出したことによって、既存プロジェクトではTrelloでやっていたこととほぼ同じことをGitHub Projectsでもやれるようになったので、私の作業負担が大きくなったとは感じません。

むしろ私が何をどんなペースでやっているかが他のメンバーから見えやすくなったことにより、安心感が得られ、進捗を出していくぞ！という緊張感が生まれてよかったと思います。

あと、これはいいことだとは言い切れないのですが、作業負担が大きくならなかった理由として、テスト仕様書を書くのもダブルチェックを実行するのも全部自分なので作業見積やIssueの書き方に迷いがないというものがあります。

ここで例えば新しくメンバーを追加してテスト仕様書作成を分担したり、テスト実行を任せたりする場合は別途QAチーム内で作業見積をする必要がある6でしょうし、GitHub Actionsというかカンバン系式に慣れていない人と一緒に作業する場合はそのサポートも作業のうちに入ってくるのでこれこの短期間に限ってはひとりでよかったなと思います7。

次のリリースでは理想にもう少し近づけるといいですね……

普遍的な問題として

今回の取り組みはあくまで開発者主体のプロジェクトで自分も心理的に楽になるためのものなので、どこのチーム・どこのプロジェクトにも普遍的にあるであろう

  • 見えている作業・想定できる作業しか具体的な見積もりができない
  • リリース直前に新しい仕様が降ってくる・仕様が変わると対応しきれない

という問題が解決されるわけではないです。

進捗どうですか？

この運用にしてから最初のリリースはまだ終わっていません(12/4現在)。なので、実際にどうなったか知りたい人は飲み会とかで訊いてください。

ソフトウェアテストの小ネタ Advent Calendar 2019ではもっと気楽なことを書くと思います

  1. 新規アプリの開発は私がチームに加わってからも、手堅いものからチャレンジングなものまで何度かありました。その度に副産物として開発・QA体制がブラッシュアップされてきたように思います。↩

  2. まさか本当に撮って出しになるとは先月の時点では想定していなかった……↩

  3. 余談ですが、Pull RequestがmergeされるとGitHub ActionsでCIが実行され、Firebase App Distributionで新しいリビジョンが各試験端末に配布されるようになっており、これを用いてダブルチェックを行います。↩

  4. どうしてこういう体制になったかを書き始めると脱線するのでここでは書きません。このタスクマネジメントの話は@KAKKA_Blogがいつか書いてくれるかもしれません。知らんけど。↩

  5. これは完全に私の落ち度↩

  6. そして作業見積についても学習してもらう必要がある可能性がある↩

  7. 今後についてはその限りではない。私よりつよいQAエンジニアがハンドリングしてくれないかな〜とはずっと思っている↩