QAがテスト設計プロセスの見える化に取り組んだ話

こんにちは。東京品質保証部 QAの矢引です。 今回は、今年の上半期に行った、試験設計プロセスの見える化の活動について紹介します。

製品チーム横断でQAのカイゼンを支援するチーム「SPITz」

サイボウズでは、製品ごとに開発チームが分かれており、QAメンバーがそれぞれの開発チームで活動し、担当製品のテストプロジェクト全般を担当しています。

QAの仕事内容についてはこちらの記事でもご紹介していますのでぜひご覧ください。

blog.cybozu.io

また、上記の活動とは別に、品質保証部内のQA全般のカイゼンを支援するチーム「SPITz」( Software Process Improvement in Test の略)があり、有志のメンバーが活動しています。 これまで、探索的テストの情報収集やTPI NEXTの情報収集・試験的導入などを行いました。

背景

サイボウズではリリースに関する品質の基準は統一されたものがありますが、 試験設計のプロセスについては、部内で大まかな指針はあるものの具体的なプロセスは各チームに任されています。

各チームでは、独自に試験設計プロセスの改善はされているものの、暗黙知として運用されている場合がほとんどで、他チームへ共有ができていない状況でした。そのため、SPITzでは以下の点を問題として取り上げました。

  • 他チームからのフィードバックが得られない。
  • 他チームの良いプラクティスに気づくきっかけがない。

そこで、これらの問題を解決すべく、まずは各チームの試験設計プロセスを見える化しようということになりました。

試験設計プロセスを見える化しよう!

このテーマについて情報収集を行ったところ、参考になる先行事例を見つけました。

SPI JAPAN 2013 「テスト設計プロセス可視化の取り組み」パナソニック株式会社 伊藤由起 http://www.jaspic.org/event/2013/SPIJapan/session1B/1B2_ID008.pdf

これを参考にして、PFDの形式で試験設計プロセスのフローを表現することにしました。

ここで、取り組む際に注意したことは必要以上に詳細化しすぎないということです。 こういったプロセス可視化の際に起こりがちなのは、現状のプロセスを一から十まで全て表現しようとしてしまい、膨大なコストがかかった割にすぐに陳腐化してしまい役に立たなくなってしまうことがあります。

今回は「他のチームと比較すること」「(一回限りではなく)今後も見直して活用すること」を目的としたため、 試験設計の入力となる情報(ソース)と、その情報を元にどのようなプロセスを経ているかの2点にフォーカスして可視化することにしました。

SPITzメンバーの担当製品をターゲットとして、5つのチームの試験設計プロセスを見える化しました。

例えばあるプロジェクトはこのようなフローになりました。 f:id:cybozuinsideout:20180727180433p:plainf:id:cybozuinsideout:20180801181133p:plain

効果

このようにテスト設計プロセスを見える化することで、各製品で全く違うと思われたフローにも共通している部分があることに気付きました。 また、作成した図をベースに各プロダクトのQAメンバーで意見を交換したところ、 自分のチームのプロセスの問題点に新たに気付けたり、 他チームの方法の一部を自チームに取り入れることで、問題点を改善できることに気付くことができました。

例えば、あるチームでは、試験仕様書のレビューはQAメンバー内でしかしていませんでしたが、他チームのフローを参考にすることで、PGによる試験仕様書のレビューのフローを取り入れることにした事例があります。 また、図をきっかけとしてチーム間のコミュニケーションが促進化され、よりQAメンバー間での情報交換をしやすくなったと感じています。

今後も継続的にQAメンバーのチームを超えた学び合いの促進に役立てたいと考えています。

最後に

今回は、製品チーム横断でQAのカイゼンを支援するチーム「SPITz」が行った、試験設計プロセスの見える化の活動について紹介しました。 現在、SPITzは次のテーマをAgile Testing として鋭意活動中です。

今回の例に留まらず、サイボウズでは「日々の仕事をカイゼンしたい」「いろんな人と繋がって学び合いたい」という改善意欲をもった方がチャレンジできる環境があります。

ぜひサイボウズで一緒に働きましょう!