「QAが上流から参画する」とどうなるの？～テストフェーズだけではないQAのお仕事～

みなさんの会社や開発組織には、QAエンジニアやテストエンジニアの方（以下、本記事中では両者をまとめて「QA」と表現します）はいらっしゃるでしょうか？

開発組織においてQAが効果を発揮するためにはさまざまな要素が必要ですが、そのうちの1つに「QAがいつ開発プロジェクトに関わるか」があります。

本記事では「テストフェーズになったらQAが入る」といった、開発の後工程になってからQAが入る現状と、QAがいわゆる上流工程から関わることの意味、そして上流工程でQAが行うことについて解説します。

「必要になったら呼ばれる」QA

QAやテストと聞くと、開発プロセスの終わり、すなわち「テストするときになったら」声をかければ良いと考える方は意外といるようです。

とくにウォーターフォール型の開発を行っている場合、
・要件定義
・仕様策定
・設計
・実装
・テスト
・リリース

といった流れに沿って、実装後にできあがった（と思っている）システムをQAに渡してテストを行う「テストフェーズ」を設けている組織もあります。

このテストフェーズになってから開発プロジェクトにQAが参加するパターンは、実はQAにとってはやりづらい進め方なのです。

■情報が不足した状態でテストをしなければならない

たとえばテストをしていて、「バグではないけれども違和感がある挙動」を見つけることがあります。

もしかしたらこの挙動は、要件定義や設計段階で「理想的ではないけれどもやむなし」として決定したものかもしれません。

しかしQAがテストの段階からプロジェクトに入った場合、そのような経緯を知らずにテストすることになるので、「念のためバグ票に書いておこう」等の対応をすることになります。そうすると、開発者がそれを確認し、「仕様です」という返信をして・・・といった、本来不要なやりとりに工数を割くことになってしまいます。

上記は非常に細かい例ですが、違った切り口では
・システムでどこがとくに大事な機能・画面・ふるまいなのかの判断がしづらい
・バグがありそうなところのアタリをつけづらい
なども考えられます。

上流工程からQAが入るとどうなるのか

テストフェーズになったら呼ばれる、ではQAが活動しづらいとなると、いつからプロジェクトに参画すれば良いのでしょうか。

基本的な考え方は、プロジェクトの開始時点からQAが入ると良いでしょう。上流工程からの参画、とも言われます。

これにはいくつかの理由があります。

■バグを未然に防ぎ、プロジェクト全体のコストを抑えられる

QAが行うことは、単にテストケースを作って実行するだけ、ではありません。

たとえば、仕様書や設計書などのドキュメントレビューにもQAの参加が望ましい、とされています。レビューと表現すると形式ばったイメージを持たれる方もいるかもしれません。ここではきちんとしたレビュー以外にも、「ドキュメントができたタイミングでQAにも共有する」ことを想定しています。

QAは要件や仕様書などのドキュメントを見て、「ユーザーが＊＊＊を入力したらどうなるのか」や「＊＊＊について記載がないが、どのような挙動をするのか」など、仕様の漏れに気づくことができます。これが大変重要なポイントです。

引用：「コストモデル」を使った開発品質・生産性向上の取組み～バグ対応コストの見える化と最適化～（独立行政法人情報処理推進機構技術本部ソフトウェア高信頼化センター（IPA/SEC））より

上のグラフは、開発工程における修正コストのグラフです。

要求仕様の誤りをその時点で発見できた場合の修正コストを1とした場合に、それを見逃して後工程で発見するとどのくらい修正コストが増えるのかを示しています。もし設計やコーディング、テストの段階で要求仕様の誤りに気づくことができず納入時に発覚した場合、要求仕様の時点で修正する200倍のコストがかかる、とされています。

この数値は開発しているシステムや開発手法などさまざまな事項に影響を受けることが予想されますが、バグは開発の前工程で潰せたほうが、修正コストが少なく済むという点は普遍的にあてはまるでしょう。

つまり、QAが上流から参画し、QAの視点（条件の網羅やテストのしやすさなど）で見ることによって、早期にバグの元を発見でき、ひいてはプロジェクト全体のコスト削減につながる可能性もある、といえます。

■適切な準備をし、効果的なテストを作成・実施できる

普段QAをされている方の中には、リリースまでの時間がない中でリリースするアプリケーションを渡され、情報が少ない中でなんとかテストをこなした、という経験がある方もいらっしゃるでしょう。

こうした、短期間でテストをしなければならない状態では、十分な、そして効果的なテストが行いづらくなってしまいます。

ソフトウェアテストには、テストプロセスという考え方があります。これは開発のプロセスに似ており、
・テスト分析
・テスト設計
・テスト実装
・テスト実行
などのステップからなります。

つまり、QAはテストを思いつきだけで行っているのではなく、テスト対象となるシステムやアプリケーションに関するさまざまな情報を元に何をテストすべきか、どうテストすべきかを決め、テストケースの形にしているのです。

そのため、テスト分析やテスト設計にかける時間がごく限られた状態でテストを作成・実行すると、テスト漏れにつながるリスクがありますし、効果的なテストができなくなってしまいます。

QAが上流工程から開発プロジェクトに参加し、早い段階から要件や仕様などの情報を得ることにより、仕様や目指す品質に対する理解を深めた状態でテストを検討できるようになる。これが、上流からQAが参画するもうひとつのメリットです。

■開発プロセス全体を見て、改善のヒントを得られる

テストのための情報を集めたり、仕様書や設計書などのドキュメントレビューをしたりすること以外でも、QAが役立てる場面はあります。
それは、開発プロセス全体を見て課題を見つけ、改善することです。

品質を「プロセス品質」と「プロダクト品質」の面から捉える、という考え方があります。

詳細な説明は省きますが、プロダクトの品質に対して、それを開発するプロセス自体の品質が影響する、という考え方です。

美味しい料理をつくるプロのシェフは、調理工程自体もしっかりしている、と考えるとイメージしやすいかもしれません。気まぐれな順番で調理をしていても美味しい料理はできあがりませんよね。万が一美味しくなったとしても、そこにはプロに求められる“再現性”がありません。

ソフトウェア開発に話を戻しましょう。

QAが上流工程からプロジェクトに参画することで、開発プロセスの中でうまくいっていないところを見つけ、改善のためのヒントを得られます。

これはまさに私がQAエンジニアとして取り組んでいる領域です。例を挙げると、
・複数部門が参加する開発プロジェクトの流れを可視化
・テストの実施タイミングや内容、担当などの可視化
・テストケース管理や不具合管理方法を見直し、不具合分析ができる状態を整備
などです。

QAが直接手を動かす部分だけで改善活動をしても、できあがるシステムやアプリケーションの品質向上に対する効果には限界があります。開発者や運用担当、プロダクトマネージャーなどさまざまなロールを巻き込んで、広い範囲での「品質向上」を目指しています。

そのためには、開発プロジェクト全体を通じて状況を把握し、情報を集め、そしてプロセス品質を良くするための活動を行う必要があるのです。

QAの出番は開発プロジェクト全体にあり

本記事では、QAが開発プロセスの上流から参画するメリットや、実際に行うことについて説明しました。

バグを未然に防いだり、早期発見したりすることでプロジェクトのコスト削減に寄与
効果的なテストを作成し、品質向上
開発プロセス自体の改善につなげる

など、QAが活躍する場面は「テストフェーズ」だけではなく、開発プロジェクト全体にあるのです。

皆さんの開発組織にQAがいる場合は、ぜひ開発プロジェクトの最初から参加してもらうようにしてください。

（文：伊藤由貴）

―presented by paiza