この記事はエムスリー Advent Calendar 2021 5日目の記事です。明日以降も面白い記事が続きますので、是非購読・拡散お願いします。
エムスリーエンジニアリンググループ QA の窪田です。早いもので私もエムスリーに入社して2年が経ちました。所属組織が変われば開発と QA の実施方法が変わることを実感した2年間です。 皆様の組織では開発をする人と QA をする人はどのような関係でしょうか。QA 組織と開発組織との関わり方の観点から QA 組織について考えてみました。
テストと独立性
プロダクトを開発すると程度は現場よりけりですが、必ず QA を実施すると思います。では、どのような立場の人が QA を実施しているでしょうか。JSTQB シラバス によると 独立性の度合いごとにテスト 1 を実施するのは主に以下のような組織に分けられます。下に行くほど独立性が高くなります。
- 独立したテスト担当者不在
- 開発チーム、またはプロジェクトチーム内に所属する、独立した開発担当者、またはテスト担当者
- 組織内にある独立したテストチームまたはグループで、プロジェクトマネージャーや上位管理者の直属組織
- 顧客またはユーザーコミュニティから派遣された独立したテスト担当者、または、使用性、セキュリティ、性能、規制/標準適合性、移植性など、ある特定のテストタイプを専門に行う独立したテスト担当者
- 組織外の独立したテスト担当者
独立性に対する個人的な話ですが、システムテストや受け入れテストなどで独立したテスト担当者がテストを担当したほうが良いと教わってきました。JSTQB シラバスにも同様のことが書かれていました。これが絶対的に真実であるかは置いておくとして、今までの経験上ある程度正しいのかなと思っています。例えば文書を作った後に、他人にレビューをしてもらうと気づかなかったことにたくさん気づけるといった経験をしたことはないでしょうか。QA 活動についても同じで、他人に動かしてもらって気づくということは私自身もよくありました。
独立性のメリット・デメリット
JSTQB シラバスによると、独立したテストによるメリットとして以下が挙げられています。
- 独立したテスト担当者は、開発担当者とは異なる背景、技術的視点、バイアスを持つため、開発担当者とは異なる種類の故障を検出する可能性が高い
- 独立したテスト担当者は、ステークホルダーが行った仮定について、検証、説明の要求、または反証を仕様作成時および実装時に行うことができる。
- ベンダーの独立したテスト担当者は、契約元の会社にある（政治的な）圧力なしに、テスト中のシステムについて正直に客観的な態度で報告できる。
逆に、デメリットとして以下が挙げられています。
- 開発チームから隔絶されると、協力関係の欠落、開発チームへのフィードバック提供の遅延、開発チームとの対立を招くことがある。
- 開発担当者の品質に対する責任感が薄れることがある。
- 独立したテスト担当者は、ボトルネックとして見られることがある。
- 独立したテスト担当者にテスト対象の情報などの重要な情報が伝わらないことがある。
メリット、デメリットともに経験的にある程度納得感ありました。独立性の良さを享受しつつ、デメリットを抑えていく活動が大事かなと思います。色々な組織のでの QA 経験といろいろな組織の事例紹介に触れて、どの組織もある程度の独立性は大事にしていたと感じています。それだけ意識されているポイントなのだと思います。
関わり方の種類
独立した組織として存在する QA 組織が開発組織と関わる方法として私が知っているのは3種類あります。 では、各組織でどのように開発と関わって QA を実施しているのか、知っている事例を交えながら考えてみたいと思います。
以下では、開発者とQAエンジニアそれぞれに対して、どのようなタスクを与えるのか、を軸に分類します。 1. 開発者がテストを全て実施し、その後 QA エンジニアもテストを実施する 2. テストの一部または全てを QA エンジニアが担当する 3. テストは開発者が実施し、テスト内容を QA がレビューする
1. 開発者がテストを全て実施し、その後 QA エンジニアもテストを実施する
ハードウェアのものづくりの歴史は古く、ソフトウェア開発は比較的新しいのでソフトウェア開発が始まった当初はハードウェアの検査工程を参考に QA が実施されていました。完成品を最終的に QA エンジニアが確認するといったものです。最初期では本当に最後の最後でダメ出しが出るのでこの手法は手戻りが多く、開発と QA の対立が激しくなりがちといった特徴があったと聞きます。とはいえ現代に至るまで改善は続けられており、大規模開発では都度介入して、工程の節目のタイミングで検査の形を取る場合が多いかなと思っています。ウォーターフォールの大規模開発などで採用している・いた組織が多い気がします。 また、大規模だとサンプル検査を実施する場合もあります。最終成果物の n% だけ確認し、摘出した不具合傾向から強化テストなどを実施するなどプロセスは様々です。 この辺の QA 実施方法の歴史は奈良隆正さんの JaSST Tokyo 2017 の資料 が詳しいです。
ポイント
この手法は古くから QA 組織が存在しており、基準やルールなどがかなり整備されていないと実施することは難しいかなと感じます。QA 経験の浅い人が検査を実施するときに参考にするチェックリストや観点、合格基準が無いと意味のあるテストや出荷の判断がしづらく、検査を実施する意味があまりないためです。その代わり手厚い基準とサンプリング手法などの確立したプロセスにより QA エンジニアを開発者に対して比較的少ない比率で運用することが可能かなと思います。そのため、比較的スケールもしやすいです。
2. テストの一部または全てを QA エンジニアが担当する
マイクロソフトの事例が極端な例ですが、開発者一人に対してテストエンジニアが一人2 の割合で存在し、開発者が単体テストを含む15% のテストを実施し、残りはテストエンジニアが実施するみたいです。元マイクロソフトのエンジニアの話によると、部署によってはテストは100%テストエンジニアが実施する場合もあるそうです。
そのような極端な例ではなくても、いわゆる組み合わせテスト、システムテストなどは テスト担当の開発者や QA エンジニアが担当するという組織は結構多いと思います。現在、QA 組織がない企業などはこのような形で回していることが多いのではないでしょうか。
ポイント
テストを実施する担当者が一定数必要になるため、今回紹介する他のやり方に比べて QA エンジニアなどのテスト実施者が多く必要になります。上記のマイクロソフトの例は極端ですが、アジャイルなどの手法を取る場合、チームに1人〜2人はテストを実施する人が必要になるかなと思います。
メリットとしてよく言われるのは、開発者が開発に集中できるということが挙げられます。逆にテストを担当しない開発者の中には品質の作り込みに興味が薄くなる場合があるというのもよく言われるデメリットです。デメリットを軽減するためにも、日々の品質意識の醸成や QA エンジニアの上流工程への積極的参画も重要な活動になります。
エムスリーでは主にこの形態でテスト活動を実施しています。
3. テストは開発者が実施し、テスト内容を QA がレビューする
QA エンジニアなどのテスト実施者が少ない、QA エンジニアが多くのチームに横断的に加わる形だったりする場合、テスト計画の作成支援や、開発者が作成した計画やテストケースを QA エンジニアがレビューする事により品質の確保や、テストの独立性を保っています。少ない人数で QA を実施するときや、QA エンジニアが複数の案件を掛け持ちする際などにこの形になることが多いです。
ポイント
開発者の品質意識がかなり高かったり、テストを積極的に実施する文化がある組織の場合、このケースを取ることができるかなと思っています。 QA 組織が比較的大きくなってもこのアプローチを取っている組織ももちろんあり、LIFULLさんの QA 組織も似たような感じかなと思っています。3
組織全体の品質プロセス浸透や改善などを促進したいときは大きな力を発揮します。
エムスリーでも一部チームや一部の開発ではこの方法をとっています。
まとめ
QA の中でもテスト活動に着目して分類、考察を実施しました。 いろいろな組織がいろいろな方法でテスト実施していると思います。エムスリーでは「2. テストの一部または全てを QA エンジニアが担当する」 の形で関わることが多いです。今後は横断組織としての活動をこれから強化して、よりエムスリー開発全体の品質に寄与できたらいいなと思っています。
We're hiring!
今回の記事の通り、QA 組織には様々なあり方があります。エムスリーの QA 組織もある程度形が整ってきましたが、まだまだ改善ポイントがあると思っています。組織の改善や QA 組織の改革に興味のある QA エンジニアは社員とカジュアルなお話ができますので、興味を持たれた方は下記よりお問い合わせください。
-
テストも QA の一部ということで例として挙げさせてもらっています。↩
-
この資料のテスト計画コンシェルジュやコンサルテーションの部分を指しています。もちろんテスト実施をされている部分も多いかと思います https://www.slideshare.net/next_developer/ltech6-lifullqa↩
