ソフトウェア開発において、テストエンジニアや品質保証(QA)担当者は、どのような役割を担っているのでしょうか。
「リリース前の最終チェッカー」「テスト項目を消化する作業者」
多くの現場では、そう捉えられているかもしれません。
しかし、私たちSky株式会社では、QAエンジニアの役割としてはソフトウェアの「品質をつくる」という、より能動的で創造的な仕事であると考えています。
要件定義が「要件定義書」を、開発が「プログラム」をつくるように、QAエンジニアは「品質」という価値をつくりあげることに関わります。
「望まれる品質」を設計する
QAエンジニアの仕事において大切なことの一つは、「お客様が本当に望むソフトウェア品質を定義し、その実現を支援すること」です。
ソフトウェアの「品質」は、製品・サービス、ご予算、そしてお客様のこだわるポイントによって大きく変化します。
例えば、日常的に使う安価な商品と、特別な日に使う高級品とでは、求められる品質レベルが異なるように、ソフトウェアにも対象に応じた「適切な品質」が存在すると考えられます。
私たちは、お客様との対話を通じてその「適切な品質」を明確にし、テストを通じて現状の品質を計測します。
そして、目標とのギャップを埋めるために、開発チームや関係者と連携し、プロジェクトを推進していきます。
これは単なるテストの実行に留まらず、品質のゴールイメージを設計し、プロジェクト全体をより良い方向へ導いていくこと。
不具合検出の「その先」へ
テストを実施して不具合を見つけるだけで、ソフトウェアの品質は本当に向上するでしょうか?
おそらく、答えは「No」です。
私たちが検出した問題を開発チームが正確に理解し、修正してくれて初めて、ソフトウェアの品質は向上します。
つまり、「不具合を検出するスキル」と同じくらい、「検出した事象を開発チームへ正確に伝えるスキル」が重要になります。
さらに、私たちは「どの不具合を優先的に検出するか」という点も重視します。
例えば、以下のAとB、どちらがより品質向上に貢献できるでしょうか?
| ケース概要 | |
|---|---|
| A | ユーザーがめったに行わない操作で発生する不具合を100件検出し、修正する。 |
| B | ほとんどのユーザーが必ず行う操作で発生する致命的な不具合を1件検出し、修正する。 |
多くの場合、答えは【B】になるはずです。
テスト対象の製品を深く理解し、ユーザーの利用シーンを想像することで、ユーザーが遭遇しやすく、影響の大きな不具合を効率的に検出する。
これが、限られたリソースの中で品質を最大化するためのアプローチです。
品質のプロとして、開発をリードする
プロジェクトが多忙になると、つい納期とテスト項目の消化に集中してしまいがちです。
しかし、私たちが目指しているのは、品質の視点からお客様と開発チームをサポートすることです。
例えば、やむを得ずテスト項目を削減する場合。
「○○項目分の機能テストが削減されます」と事実だけを伝えるのではなく、「○○機能における△△という観点の動作が保証できず、最悪の場合、××という不具合やユーザーへの不利益が生じる可能性があります」といった、一歩踏み込んだ見解を伝えます。
テストの削減が、品質としてどのような影響を及ぼすのか。そのリスクと見解を提示すること。
それが、品質に関わる専門家としての責任だと考えています。
また、多くのプロジェクトでは「不具合が多すぎる」「そもそも動作せずテストが進まない」といった問題が発生します。
その根本原因の多くは、テスト工程より前の 上流工程に潜んでいることがあります。
上流から品質を作り込む、次世代のQAエンジニア
私たちは、不具合の検出にとどまらず、開発の上流工程から品質を作り込む「シフトレフト」のアプローチも大切にしています。
特にアジャイル開発のようなモダンな開発スタイルでは、完成したものを後から大勢で検証し、不具合を修正していくやり方では手戻りが多く、非効率になる場合があります。
開発の早い段階からフィードバックを繰り返し、より価値の高い製品・サービスづくりに貢献できるQAエンジニアでありたいと考えています。
そのためには、設計レビューへの参画、開発初期段階での品質リスクの分析と対策提案など、広い視野で開発プロセス全体に貢献していくことが、これからのQAエンジニアには求められていくでしょう。
おわりに: 品質をつくる、プロフェッショナルとして
QAエンジニアは「品質をつくる」仕事です。
望まれる品質の設計を支援し、
ユーザー視点で本質的な不具合を検出し、
品質の視点からプロジェクトをサポートし、
上流工程から品質を作り込む
これらを通じて、ソフトウェアの品質向上に貢献していくことが、QAエンジニアの役割であり、目指す姿と考えています。

