QAグループの星野です。
昨年の2020年11月に公開された『LIFULLのQAの取り組みについて』にてQAグループの主だった活動について紹介されました。 本記事では、こちらで概要だけ紹介されている"リリース前リスク分析を起点としたQAのアクション"についてご紹介致します。 QAがプロジェクトメンバーとして参画していないプロジェクトを対象とした取り組みになります。 www.lifull.blog
また、今年2021年1月にはそれらの活動の中からテスト計画の作成を行う『テスト計画コンシェルジュ』について紹介がありました。 QAがプロジェクトに対して直接的にアプローチする取り組みについてはこちらの記事をご覧ください。 www.lifull.blog
RiskManagementNoteについて
なぜ行っているか
LIFULLでは設計や実装を行っているエンジニアたちがテストにも責任を持っています。
テスト設計や実施のみを専門としている組織は存在しません。
よって、すべてのプロジェクトにQAチームが必ずしも直接的に関与する必要がありません。
しかし、自分たちの関わっていないプロジェクトで本番障害が発生しユーザーへ不利益が発生したときに「関係ありません」と知らんぷりは絶対にしません。
自分たちが直接的に関わっていてもいなくても、本番障害を自分たちで防げる可能性があったなら責任があると考えています。
大きなリスクを抱えたプロジェクトになるべく気がつけるように各開発部署の情報を抽出し、人の目で改修要件や仕様書を確認しています。
どんなことをしているのか
抽出したチケット情報からプロジェクトのドキュメントを参照して改修要件などを確認します。
基本的にはプロジェクトの比較的序盤、改修要件が定まっている段階のものが調査対象になります。
改修内容や影響範囲やリリースの予定日など様々な情報をまとめ、
調査/分析した結果をQAチームで確認し、なにかしらの対応が必要かどうかを検討しています。
どう行っているのか
プロジェクトの情報を見ながらリスク、特にプロダクトリスクを考えます。
改修箇所で問題が起こった場合に「重要度：システムの機能への影響」「優先度：低下するシステムの価値」「発生確率：遭遇し得るユーザーの規模」の3軸で定量的に数値を出します。
それに加え、改修要件を見ながら「テストは十分に検討されているか」「過去の障害から予測できる障害はないか」「他プロジェクトと改修範囲がバッティングしていないか」「自動e2eテストで検知できるか」などを考えながら定性的なリスクを挙げていきます。
これらの定量的、定性的な情報からプロジェクトへQAが関与するかどうかを判断しています。
ET検討会について
続いてET検討会についてです。ETというのはExploratory Testingの略称で、探索的テストを指しています。
RiskManagementNoteではプロジェクトの比較的序盤で調査をしているのに対し、ET検討会ではリリース直前のものを対象に扱います。
なぜ行っているか
私が入社した時点ではRiskManagementNoteのみで、ET検討会は行われていませんでした。
あるとき、リファクタリングやSEO対策のための小さなプロジェクトが増え始め、1日にリリースされるプロジェクト数が大幅に増えた時期がありました（多い日には1日に30件程度リリースされていた）。
開始からリリースまでの期間が短い小さなプロジェクトが増えたことで、 RiskManagementNoteのチケット調査では網から漏れて掬い上げられないプロジェクトが出てきたり、 QAがRMNの検討フェーズに入った時点でリリースを翌日に控えているなど対応が追いつかなくなってきました。
また、小規模なリリースとはいえ、それだけの数がリリースされるとなると統合時に何があるかわかりません。 開発チームがテストをしていると言っても、他チームのリリースによる影響まで考慮して見ることは難しいためQAが水際作戦でケアすることにしました。
リリースについてはチケットで管理されているため、RiskManagementNoteで網から漏れてしまったプロジェクトもここで拾い上げることができます。
どんなことをしているのか
当初はリリース周りのチケットを手動で集めていましたが、現在は自動的に抽出し何件のリリースが控えているのかをbotが教えてくれます。
こちらもRiskManagementNoteと同様に「どんな障害が起こり得るか 」「類似する障害はないか」「テストは十分に行われているか」などの観点でプロジェクトの情報を確認します。 他、ET検討会が始まったときの「同時にリリースされる施策で衝突しそうなものはないか」といったものも気にしています。
どう行っているのか
ここで対象とするものは翌営業日にはリリースされてしまうため、その日のうちに探索的テストを実施します。
開発チームが所有する環境で既に開発チームによるテストは実施されており、 QAが確認する環境はそれとは別のテスト環境であるため、開発チームのテストには影響がありません。 また特別な環境の準備も不要なので自由なタイミングで実施することができます。
リリースを止める際にも判断含め時間が必要になるため、QAチームはなるべく迅速に探索的テストに取り掛かります。
そのため、(少なくとも自分は)チャーターを入念に準備することはあまりせず、挙げたリスクを中心に実施しています。
まとめ
QAの間接的なプロジェクトへのアプローチをご紹介しました。
プロジェクト内のエンジニアがテストに責任を持っているとしても、（少なくとも私は）QAが不要になることはないと考えています。
冒頭で直接的なアプローチとしてご紹介しているテスト計画コンシェルジュなどの取り組みも含め、
開発チームが自分たちのつくりたいものに注力できるように、出来上がるものがより良いものになるようにサポートするのがQAの役目だと感じています。
LIFULLのQAチームはテストの設計や実施のみを専門とするような組織ではなく、
横断的な組織だからできること、開発したエンジニアがテストに責任を持っているからできること、
そういった「自分たちだからできること」とET会が始まったように「状況に応じて必要な行動を取ること」を大事にしているチームだと思います。
ここに書いている取り組みが、読んでくださっている方々の組織にそのまま適応できるかはわかりませんが少しでも参考になれば幸いです。
