QAエンジニアがリリースフロー整備するメリット

みなさん、こんにちは！Showcase GigのQAエンジニア横田です。
入社して、1年が経ちました。主に、O:der TableのQA活動しています。

テスト設計や実施していることが多いですが、今回は、リリースフロー作成して運用している事についてお話します。

QAエンジニアとして活動しているが、テスト以外の業務でどう活動したら良いのか考えている方に1つの選択肢として提示できればと幸いです。

O:der Tableのリリースフローについて

現在、O:der Tableは隔週で定期リリースをしています。定期リリース運用が始まったのは、一年前になります。
緊急対応なども発生しますので、定期リリースとは別にhotfixリリースが行われることはあります。

リリースフローの簡易図を下記に記載します。

解説

・O:der Tableリリースに対して、複数チームが存在しています。
上記のリリースフロー記載のスプリントプランニング/レトロスペクティブについては、あるチームの例となっています。
それ以外は同様になります。

・QAチームは、各チームに所属しており、それぞれのスプリントで動いています。
上記のリリースフローにてQAチーム単体で活動するのは、緑の線で表している部分になります。機能テストやリグレッションテストを行い、リリース判定までを担当しています。

・「機能テスト対象QA環境反映期限」「リリース対象QA環境反映期限」それぞれの対象もQAチームで決定しています。
どちらの対象も、開発側でのテスト実施は行っているためQAチームですべての対象で個別テスト実施を行う必要がありません。

機能テスト対象：主にUIや機能追加・改善が行われるもので、リグレッションテストのみではなく個別に項目書を作成して実施する内容
リリース対象：ログ追加等、QAで個別にテスト実施を行う必要はなくリグレッションテストで担保すべき内容

・リリース判定は、リリースにて、リグレッションやユーザー影響インパクトの大きいバグが発生していないかを軸に判定しています。
機能テスト段階で、バグが発生した場合などは、その部分のみリリースしない事もあります。

過去に改定している内容

①機能テスト完了後にショート版のリグレッションテストを実施していた。その後、仮リリース判定を実施する。
→　工数は増え、実施結果から得られるものも少なく廃止しました。

②QA環境への反映期限以降に反映をする場合は、別チケットでQAチームに共有→承認を得てから反映する
→　開発者に詳細を別チケットで作成してもらい、QA側でどのような影響範囲/リスクがあるのかを判断できていた。しかし、反映期限を超える対象が少なくなったので自然となくなりました。

QA発信でリリースフローを運用するメリット

リリースフローを、QAが作成して運用することでいくつかメリットがあります。

①QA確認が完了することでリリースできることを徹底できる
②QAから開発エンジニアに進捗状況を聞きやすくなる
③他部署からの信頼を得られるようになる

①QA確認が完了することでリリースできることを徹底できる

QAが作成することで、QA期間の確保が確実にできます。
リリース前にどれだけの期間が必要か、いつまでにQA環境が整っている必要があるのか。これらの情報を一番把握しているのはPMや開発エンジニアではなくQAエンジニアです。

ですので、その情報をフローに落とし込む事ができるのは、QAだけです。

QA以外でも暫定的に落とし込むことは可能です。そこで生まれる問題として、「QA期間の不足＝十分なテストが実施できない＝顧客影響の拡大」につながっていきます。 そのような状況を起こさないように、QA視点でリリースフローを作成することでその動きを徹底できます。

②QAから開発エンジニアに進捗状況を聞きやすくなる

上記にも記載したとおり、現状のリリースフローではリリースまでの間に2箇所ほどQA環境への反映期限が存在します。
そのため、それぞれの対象（Jiraチケット）の状況確認としての理由付けできます。

仮にこの期限があやふやで定まっていなかったらどうでしょうか。
毎リリースごとに、「いつ確認しようか」「このタイミングで聞いても良いのかな？」と、考えてしまうこともあります。
確認される側としても、「そんな急に聞かれても」と感じる可能性があります。

QAからルールを提示することで、想定可能な悩みを解決できます。

③他部署からの信頼を得られるようになる

今回の記事を書くにあたって、プロジェクトマネージャー2名に話を聞きました。
その際、現在のリリースフローができる前は、リリースしたかった内容がリリース日直前にリリースできなくなってしまったなど、サポートチーム等の他部署に 迷惑を掛けてしまう事があったという話がありました。

QAが品質に責任を取れるリリースフローを作成することで、前もって正確なリリース内容を伝えることができるようになりました。
QA期間中にリリースできないという判定をすることもあります。その内容も、事前に伝えることができ、顧客の対面に経っている部署にスピーディーかつ正確な情報を伝えることが可能になりました。
そのことで、他部署から開発部署へ信頼感が高まる要因の1つとなったと思われます。

今後の施策

現在、隔週でのリリースとなっているので、そこを毎週リリースが行えるようなフローを構築したいと考えています。
隔週から毎週に変わることで、発生しうる課題を洗い出し、それに対してどう対応するかをチームとして検討します。 その後、毎週リリース運用に進めて行きたいと考えています。

まとめ

QAエンジニアの役割は、リリースされる品質に責任を持つことだと思っています。
リリースまでの道のりを、QAエンジニアが整備することで、リリースまでの経緯に対して自己意識を持つことができます。
道のりの中で、誰かが困っていることなども気付きやすくなります。そういう部分を解決することで、リリースされるものの 品質にも責任を取れると思っています。