初期品質向上のためのQA目線での取り組み

2023/04/19

| Ryoko Takagi

背景

現在、QAチームはフルタイムメンバー2名、PPさん*3名で活動しています。（※ 令和トラベルでは業務委託の方をプロパートナー（PPさん）と呼んでいます。）

NEWTの開発チームでは、1週間に1度のアプリリリースを行っており、昨年10月からの半年間で200Epicのリリース件数を目標としていました。単純計算で1ヶ月あたり33Epic、1週間で8-9Epicをリリースする必要があります。

少ない人数でより多くの案件をリリースするためには、QA ready時の品質（初期品質）がとても重要です。初期品質が低いと、QAエンジニアと開発者の間で不具合に関するやり取りが頻繁に発生してしまい、お互いの工数が取られてしまったり、Blockerがやっと解消されたと思いきや、また次のBlockerが見つかり、、、というようになかなか安定的にQAを進められず、元々予定していたリリース日の遅延に繋がる可能性も出てきてしまいます。

そのため、QA目線での初期品質を向上させる取り組みを実施しました。

取り組んだこと

Sanity testの導入

これまでは、開発者がどこまで挙動確認をしてQA readyにするか明確な基準が決められていませんでした。

そのため、大きめの開発案件に関してはQAエンジニアがSanity test（健全性テスト）を作成し、そのケースを開発者（もしくは同じ開発チームのエンジニア）に実行してもらい、ケースがOKになった箇所からQAを開始、OKが付くまではQAを開始しない、という方針を取り決めました。

QAエンジニアとしては、Sanity testのケースを作成する工数が追加になりますが、最終的にはQAチームが実行するTest caseにも流用できそうだったこと、またこの工数をかけることでエンジニアとの不具合のやり取り工数が格段に減ることが予想されたため、導入してみました。

実際のSanity testのケースの一部がこちらです。

Sanity testのケースを作成する際には、下記の三点を意識しました。

1案件で20ケース前後に収める

開発者に負担にならないかつ、正常系のフローを一通り通すことができる量を考え、1案件で20ケース前後に絞ってケースを作成しました。

ケース全体の作成フローとしては、

先にSanity testを作成→肉付けする形で実際のTest caseを作成

先にQAが実行するTest caseを作成→そこから抜粋してSanity testを作成

この2パターンをどちらも試してみました。前者だとTest caseの作成が楽になったと感じましたが、後者だとあれもこれもSanity testに入れたい、、、となったので、Sanity testの導入を検討している方には、わたし個人としては前者をおすすめします（笑）

Blockerとなり得る重要なケースのみに絞る

1でも記載した通り、あれもこれも入れたい、、、となってしまいがちですが、できる限りケースを絞って記載するようにしました。特に、このケースがOKにならないと、Test caseの方で連続して保留になってしまうようなケースを意識して取り入れるようにしました。

例えば、今年頭にリリースしたポイント機能というEpicだと、いくつかの画面でたまるポイントが表示されるのですが、QA側のTest caseではそのポイントの表示位置が正しいか、表示文言が正しいか、ポイント数が正しいか、など様々な観点を確認します。しかし、そのようなケースを実行するためには、まずその画面にたまるポイントが表示されていなければなりません。そのため、Sanity testではポイントの細かい表示などにはこだわらず、「この画面にたまるポイントが表示されていること」が確認できればOK、その後細かい点はQA側のTest caseで担保するという形にしました。

観点やパターンを書きすぎない

細かい観点やパターンはQA側のTest caseで実行することから、Sanity testに記載する内容はかなり削ることを意識しました。QAエンジニアは普段からテストケースを見ているため慣れていますが、開発者に実行してもらうとなると、1ケースに多くの情報を詰め込みすぎると見落としや混乱を招く可能性があると考え、できるだけ簡素に、必要な情報のみを記載することにしました。