プロジェクトにQAが入るとどうなるか
こんにちは。kubopです。
先日社内のプロジェクトで初めて、初期段階からQAとしてジョインしました。その際の良かったこと、さらに良くしていけたことを書ければと思います。
※ 期間は約3-4ヶ月程度のプロジェクトです。
おおまかな流れ
キックオフ
仕様検討
実装
検証
本番リリース
キックオフ
おおよその仕様・やりたい事をざっくり決めます。
やりたい事自体は決まっていて、どう進めていくかみたいな話をしていました。
QAとしては、ここまでは最低限欲しいな〜とかこうなるとヤバいかもな〜みたいなことを問いかけたりしていました。
仕様検討/実装
詳細となる仕様を決め、実装していきます。
どういう構成で実装していくか、タイムアウトは何秒にするべきか、セキュリティはどうか、懸念事項を洗い出し、潰していく作業です。
QAとしては、関連部署（SREチームやCSチーム）に確認が取れるようアレンジメントしたり、実例マッピングを用いてエッジケースを洗い出したりしていました。
実例マッピングで出したケースに関しては、逐次エンジニアに確認をとって詳細設計の見直しをしていました。（実装と並行で行うこともあり
また、仕様ドキュメントを作成する文化が無かったためQAチームで作成・メンテが出来るようにしていました。
ここの段階で同時にヘルプページを考えます。
CSチームと協力して素案を作成し、運用イメージを共有していきます。
また、単体テストのレビューをできる限りQAが行なっています。
全てを把握することは難しかったのですが、ここはスキルアップの余地ありだなと感じています。
検証
QAチームが主導して検証を行います。
仕様検討段階で作成したテストケースを実装と同時並行で確認していきます。
ここで気を付けていたことは、
検証が最終チェック、つまりQAが門番にならないことです。
実装ができたタイミングで検証を少しずつ進めていき、少しずつバグ出ししていきます。
最後の最後で一気に検証、というのは絶対に避けようと決めていました。
本番リリース
本番リリースに向けて、システムテストを実施します。
特に問題になるのは本番環境で動かない！となることなので、本番に近い環境を用意してもらい、デプロイして動作確認を全員で行いました。
開発メンバーはもちろんのこと、QA・SRE・CS・PRチームなどを巻き込んで機能自体のバグと同時に機能の認識齟齬、実装ミスなどがないかを確認していきました。
今回はサーバサイドのリリースをした上で、フロントエンドのリリースを行えば良いだけだったため、フィーチャーフラグ的にリリースを行うことができました。
今回のこの方式がかなり具合良かったので、次回も同じようにリリースできれば良いなと思っています。
QAがやって良かったこと
過去データの洗い出し・テストケース作成
過去データを利用して、新たなデータを作成する機能であったために、クレンジングされていないデータではバグが発生する可能性がありました。
可能性は多岐に渡り、人間が認識できるレベルを超えていました。
そのため、あるパターンをもとに過去数万件のデータをマスクして取り出してテスト検証用データとしました。
テストケース自体も、素人ながらマインドマップを用いて作成しました。
ドキュメントの作成
元来ドキュメントを作成しながらプロジェクトを進行したことがなかったのでドキュメントを格納できる場所を用意して、出てきた案や懸念点などをそこに集積出来るようにしました。
あらゆる場所に考えがストックされる(Slackなど)と、認識齟齬が発生するのですが、それが起こらなくて良かったと感じました。
「結局、それどうなった？」がなくなったので良かったです。
デイリースクラム・随時検証
途中からデイリースクラムを提案し日次で進捗の共有・確認をしていました。
検証は一気に行わず、できるところから進めていき、最終的にリグレッションテストを行なっていました。
しかしながら随時検証を行なっていくと「何が出来て、何が出来ないか」が明確になります。
そのため、スケジュールに遅延が起こりそうといった見えない危険に気がつくことができました。
実例マッピング・他部署連携
実例マッピングを、ステークホルダーを巻き込んだ形で複数回行なっていました。本当はもう少し頻度高めることができれば良かったのですが
他部署を集めて実例マッピングを行うことで、「これだけは出来ないと（発生してしまうと）本当にまずい！！」が共有出来て実装後に巻き戻ることがありませんでした。
また、実際に運用するであろうCSチームの理解を早期に得られたことが非常に大きな功績でした。
ストッパーになれた
随時検証をしていく中で、このままではマズイのではないだろうかと早めにアラートを投げることができました。
結果として遅延することになりましたが、障害レベルの不具合が起きずにリリースすることが出来ました。
やれば良かったこと
スクラム開発
初期からスクラム開発を行なっていれば良かったなと思いました。
スクラムイベントの実施、またスプリントゴールを設定することで何が出来て、何が出来ないかを明確にしておくことが肝要だと感じました。
というのも、検証段階で何を検証したらよいかパッと見全くわからないからです。
開発メンバーが認識していること、QAが認識していること、POが認識していること、ステークホルダーが認識していること、の齟齬自体が命取りとなります。
動くものを素早く検証する
今回は、インフラに手を入れる修正があり、統合テストをするためにはインフラの負荷の調整などが必要となりました。
ですが、機能の検証とインフラの負荷検証自体は切り分けて行なっても良いはずです。
そのため、機能を単一で動かせるような実装をした後に、負荷検証を行ったインフラ環境と統合して確認できると良いなと思いました。
コードによる開発と、それ以外の開発、一気通貫で作りたくなる気持ちが凄くわかるのですが、まずは単一で動くものを用意してアジャイル的にステークホルダーに見せていくというのが大事なのだと思いました。
また、検証中にインフラ起因なのか、コード起因なのかの切り分けが難しい時がありました。リリース直前に同様の問題が起きた場合はリリース延期せざるを得ません。そういった問題を防ぐためにも切り分けたほうが良いかなと思いました。
単体テストケース設計をする
単体テストケースは完全に開発メンバーにお任せし、レビューを行なっていたのですが見切れなかったり設計自体に何か意見を言えたり出来なかったなと反省しました。
コードリーディングスキルと、RSpecの技術となるのですがそのあたりもQAとしてはきちんと身につけていなければ安心できません。
まとめ
プロジェクト進行を横断して見れ、全ての時間軸で存在できるQAならではの動き方はもっとあるなーと反省の多いプロジェクトでした。
プロジェクト自体のオーナーになるつもりで、イニシアチブを持って進行役ができるともっと良いだろうなと思います。
Whole Team Approachが少しは出来たかな？と思います。
この記事が気に入ったらサポートをしてみませんか？