こんにちは、Classi QAチームの竹林です。 Classi QAチームでは、単にテストをするだけのチームではなく品質向上をミッションとするチームとして、品質向上に向けた施策を実施してきました。
この記事は、Classi QAチームの品質向上に向けた歩みの共有になりますので、QAの進め方について検討している方の参考になれば嬉しいです。
「品質の見える化」で始める
Classi QAの品質向上に向けた取り組みは「品質の見える化」から始めています。 品質向上のための課題抽出や施策提案を、現状に最適な優先度や内容で進めるために、まずは現状を把握する必要性があるから、との考えからです。 また現状把握だけの利用でなく、今後の品質向上PDCAサイクルなど、QAの中長期的な取り組みのベースにすることを想定しています。
「品質の見える化」の実装は、バグなどの不具合発生時に「どんな事象が？」「どこで混入した？」「なぜ混入した？」などの情報を残していく方式で進めました。 この方式は、開発者の協力がないと成り立たないのですが、Classiの開発メンバーは品質意識が高くとても協力してくれるので、スムーズに進めることができました。（改めてこの場で感謝します。）
「品質データの活用（第一弾）」を始める
「品質の見える化」で見えてきた品質データは、「テスト結果レポート」を作るために活用しています。 「テスト結果レポート」は、テストから得られた情報を基にしてリリースリスクを把握できるため、「リリース品質の向上」に繋げることが期待できます。
- 【リリースリスクを把握するための、テスト結果レポートの項目（例）】
- テストの進捗状況
- 不具合の発生・収束状況
- 不具合の内訳（バグ？デグレード？仕様？など）
- 不具合の対応状況・残存状況など
- リリース見解（総合的なリスク判断）
「開発とテストの専業化」をトライアル
「開発作業と検証作業を専業化するかどうか」は意見の別れる事案ですが、Classi開発では「専業化」をトライアルでスタートしています。 開発スピードが企業戦略的にも重要な要素になっている現在では、専任メンバーがテストを専業することで得られる「開発メンバーの負担軽減」は大きなメリットです。
一方で、専業化によるデメリットとして「開発者のテスト意識やテストスキルが低下する懸念」などがあり、今後はメリットとデメリットのバランスを観察しながら、随時ブラッシュアップしていく予定です。
「QA効果の最大化」を始める
「上流でのバグ検出」を目的として導入されることが多い「QAの上流参加（仕様レビューなど）」ですが、Classi QAでも始めています。 「上流でのバグ検出」を目的とする理由は、「品質のV字モデル」で提唱されるように開発後期（下流工程）で検出したバグは手戻りが多いため、できるだけ開発前期（上流工程）で検出したいとの考えからです。
「テストの自動化」を始める
開発スピードがUPしたりリリース頻度が高まることで懸念されるのがデグレード発生リスクですが、その対策として利用されているのがテストの自動化で、Classi QAでも導入を開始しています。 かなり以前（10年以上前）からある自動化施策ですが、ここ数年は特に盛り上がりを感じており、多くの開発現場でデグレードに苦労していることが分かります。
「品質データの活用（第二弾）」を始める
品質データの活用（第一弾）では『リリース品質の向上』に活用しましたが、（第二弾）では課題や改善のヒントなどの見えた情報を開発工程にフィードバックして、『開発品質の向上』に活用します。
この（第二弾）は非常に難しい施策で、本施策の実現に必須となるPDCAサイクルを「継続運用できている」という事例を私はあまり聞いたことがありませんが、Classi QAでは挑戦を始めています。
本施策については、当開発者ブログの別記事【QAチームが取り組む「品質の見える化」への挑戦】に投稿を予定していますので、併せてお読みいただけると嬉しいです。
おわりに
Classi QAチームの品質向上施策をフェーズ分けすると、現在は後期に入ったあたりです。
ただ、後期フェーズに入ったとはいえ、やることが少なくなったわけではありません。
今後更にスピードアップが求められるソフトウェア開発や、日々進化する開発技術に対応するために、新しい施策の提案や実施済みの施策のブラッシュアップなど、タスクは尽きません。
今後もClassi QAチームの品質向上への道は続きます。
