開発メンバーが100人を超えた大規模サービスのQAについて

開発メンバーが100人を超えた大規模サービスをQAしていて日々感じていることをポエムにしました。

1. 他のチームが何やってるか把握しきれなくなる

機能のテーマごとにスクラムチームを組んで各チームにQAエンジニアをアサインしていますが、チームの数が10を超えてくると、各QAエンジニアは他のチームの新機能や機能変更についてキャッチアップできません。サイロ化とかそういう話じゃなくて透明性が有っても情報量が多すぎて記憶しきれません。職種別ミーティング等の横串の組織で情報共有しても把握しきれるのには限界があります。

2. 他のチームの新しい機能にそもそも気が付きません

新しいボタンが実装されるなど、新しいUIパーツが出来ればそのボタンを押したらどうなるかを気にするでしょう。ただし、新機能が必ずしもUI上に見えるとは限りません。新しい機能についてドキュメントを整備しても、そもそも新しい機能がリリースされたことに気が付かないのですから、ドキュメントを確認することを期待してはいけません。自分が担当している機能に対して他のチームの機能がコンフリクトして問題が発生するのは、目に見えない地雷を踏むようなものです。

3. 他のチームの新しい機能に気が付くことを期待できないので、リリース前に検証することも期待しない方が良いです。

気が付いてないのですからリリース前のテスト観点、テストケースから他のチームの新しい機能への対応は漏れます。また、気が付いていたとしても、数ある他のチームの新機能から、自分の担当する機能に影響があるものを選び出すのは困難だと言えます。

なので、大切なのはリリース後になるべく早く問題に気が付いて修正することだと思います。

4. 必ずしもリリース後にエラーが出る等によって気が付くとは限らない

リリース後にエラーログやクラッシュログによって問題に気が付くことが出来れば、そのログを確認してリリースをリバートして影響範囲を確認して修正して再リリースすることができると思います。ただし、不具合の出方によっては、そもそもエラーもクラッシュもしなくて単にボタンが表示されなくなるとか、期待するイベントが送信されなくなるとか、何らかのアクションが発火しなくなる等もあり得ると思います。その場合はリリース後のログからは見つからない可能性もあります。その場合は発見が遅れ、影響範囲が広がってしまう可能性があります。

5. 思いつく予防策

もちろん自動テストによるリグレッションテストによってなるべくカバーできれば良いですが、新機能については実装が追いつかないことも考えられます。

まず大事なのは自分の担当するチーム内で完結する範囲内では不具合をなるべく出さないことです。

また、他のチームの機能に気が付かないでは済まされない、決済などの重要な機能についてはさすがに情報共有を徹底しましょう。

次に、本番のデータが異常値になった場合に気が付く可能性もあるので、分析ツール等でモニタリングできるようにすることです。

最後に、カスタマーサポートの方との連携を強めることです。お問い合わせが増えたりした場合に、すぐ相談してもらえる関係性にすることです。