こんにちは、エンジニアの千吉良（ちぎら）@_naru_jpn です。ここ最近 QA に関して考える機会があり、Systematic Software Testing という本を読んでいたところ、色々と刺激を受けるところがありました。計画書の作成やリスク管理などテストの実施以外の領域についても多く書かれていましたが、まずはミラティブの現状に基づいた改善を行うべきだろうと考えました。今回は特にメトリクスの取得などに関して、GAS（Google Apps Script）を活用してミラティブの業務に応用してみたことについてまとめてみました。
以下では細かいことにも触れているので、3行まとめをおいておきます。
- 手動テストの進捗を見えるようにしたよ
- GAS（Google Apps Script）で実装したよ
- ついでに関連業務を自動化したよ
ミラティブにおける QA と解決できそうと感じた課題
ミラティブでは、CI/CD を活用した運用*1やアプリのリリース作業の自動化*2 を積極的に行なっており、日々の運用業務においても整備された管理ツール上で作業が行われるなどによってサービスの品質を維持しています。一方で、配信処理であったりユーザー体験が関わる部分についての品質は、手動のテストによって品質を維持しています。ここでは、手動のテスト工程に対して実施した改善についてご紹介します。
手動でのテスト工程の作業は、従来からアウトソーシング（社外の QA チーム）によって実施しています。何人かの方に常駐していただいていて、社内の開発チームと日常的にコミュニケーションをとりながら QA をしていただいています。
大抵のケースではひとつの施策の実装単位で QA が行われます。仕様書やデザインをもとにしてテスト項目書が作られ、テストの実施期間中にバグが発見された場合にはバグチケットが作成され、都度担当のエンジニアが対応します。テストケースを用いたチェックリスト形式のテスト（通称：テスト項目実施）と、項目によらない探索的テスト（通称：フリーチェック）の両方が行われています。すべての項目とバグチケットの対応が終わり、フリーチェックも十分行われたらテストは完了となります。
テスト項目書の作成フェーズでは、項目書の作成は専門性も高く QA チームにお願いしているため、すぐに効果のある改善を考えるのは難しい部分でした。QA チームと開発チームが開発段階でより密にコミュニケーションをとり効率的な意思疎通を図るといった方向の改善も考えられますが、社外の QA チームと協力しているような環境では社内にチームがある場合と比較して、チーム内で共有できる時間などに限界があります。人の動きによるコミュニケーションの改善よりも、見えている情報を増やすことによるコミュニケーションの改善が効果があるのではないかと考えました。
テストの実施中は開発チームはバグチケットを受け取って対応しますが、項目テストでの項目の消化率などは QA チームしか把握していませんでした。検証のブロッカーとなるような障害やバグが発生している場合にも、それがテストの実施にどれだけの悪影響を与えているかを把握する術がありませんでした。見えていない情報があることによって妨げられているであろうコミュニケーションがあるならば、その情報を可視化することによって改善を図ることができるだろうと考えました。
QA 工程の可視化
いままでテスト項目の消化率は開発チームには共有されていなかったのですが、まずは一番わかりやすい数値であるテスト項目の消化率の日次の変化を見えるようにしました。以下はブログ用に用意したサンプルの施策のグラフで、9日間を想定した QA 工程の 7 日目までのテスト項目の消化率を表しています。
全体のスケジュールの中でテスト項目の消化がどこまで進んでいるのかが一目で分かるようになりました。横軸が微妙な数値になっているのは経過日数を 0 ~ 1 で正規化しているからで、これは規模の異なる施策の傾向が比較できるようになることを期待しています。また、実施したテスト項目あたりのバグチケットの起票数も記載しており、これはいわゆる欠陥率を表しています。
この例のグラフからは、QA 初期と後半のテスト項目の消化のペースが悪いことが分かります。QA 初期のペースの停滞は検証環境の不備が原因かもしれませんし、後半のペースの停滞は検証のブロッカーとなっている事象があるのかもしれません。そういった、開発チームと QA チームとの間でコミュニケーションをとりながら進めないといけない問題を話すきっかけになることを期待しています。
GAS を使った可視化の仕組み
今回の仕組みの実装には GAS（Google Apps Script）を採用しました。社内で Google スプレッドシートは日常的に使われていますし、権限管理も比較的慣れています。仕組みはとてもシンプルで、GAS のコンテナであるスプレッドシートを参照して、ウェブアプリケーション上にグラフを描画しています。
グラフの描画に用いる数値を記入しているシートはできるだけ少ない入力で済むようにしています。日次で入力をする必要があるのは以下に添付した画像の赤枠で囲った箇所のみです。
テストに関する作業の半自動化
以上まででテスト工程の日次の進捗が見えるようになりましたが、これだけだといつもの業務に可視化のための記入業務がただ増えただけなので、作業内容のヒヤリングなどを元にして、標準化も兼ねて自動化できるところはしようと考えました。
QA チームは日次の作業が完了した際に、Slack に経過報告や次営業日のテストの実施予定などを投稿しています。それらも含めて、以下のような作業を機械的に行えるようにしました。
- 個別の施策のグラフ管理用シートの自動生成
- 日次のテスト結果の Slack への報告
- 次営業日のテスト実施予定の Slack への報告
すべての施策を管理するシートを作成し、ここから個別の管理用シートを自動生成できるようにしています。
また、Slack への日次の報告は各施策に対応する文章を自動で作成し、GAS のウェブアプリケーションから Slack に投稿できるようになっています。
全体の構成を一枚絵にすると、以下のようになっています。
QA に関連する業務の暗黙的で属人化していた作業の一部が、機械的に行えるようになりました。会社間のコミュニケーションがあるような場合では、メンションの仕方などの細かいフォーマットに気を使っていただいたりなどすることもあると思いますが、仕組みに任せることでこの辺りの気配りも不要になったり、実施者による認識のずれなども少なくすることができます。
今後の展望と課題
テスト工程に関する数値が分かるようになったことで、情報をキャッチアップした人にチーム内のコミュニケーションのきっかけとして使っていただくところまではできるようになりました。しかし積極的にキャッチアップするモチベーションはまだ湧きにくいとも思っています。
日次の報告の文章は機械的に生成していて進捗も数値で把握できているので、例えば進行が妨げられたり品質が悪そうだったりしていないかを数値的に判断して、分かりやすい表現で（「消化率の推移がよくないのでチーム内で確認してみてください」など）開発チームに対してフィードバックすることは技術的に可能です。テスト工程とそのフィードバックを通じて、チームの改善につながる情報だったり、そのきっかけを提供していけたらより有意義な活動にできるのではないかと考えています。
また今回の取り組みとは方向性は異なりますが、ミラティブにおいて自動テストにどこまで有効性が持たせられるのか、という点も興味のあるところです。ミラティブのテストでは探索的テスト（フリーチェック）が少なくない割合を占めています（iOS のシミュレータが配信処理に対応していないなど、制約も多くあります）。チェックリスト形式のテストは自動化を考えられますが、探索的テストでは困難です。自動テストを考える際には、自動化できる分量と自動化した際の有効性がある程度予測できている必要があると思っていますが、この辺りはまだブラックボックスが多く、チェックリスト形式のテストや探索的テストによって担保されている品質はそれぞれどの程度か、なども可視化して把握できるように知る必要があるだろうと考えています。
We are hiring!
ミラティブではいろいろなエンジニアを募集中です！
