この記事はPeter G Walenによるゲスト投稿です。
ソフトウェア品質保証、ソフトウェアテスト、品質制御。全部同じ、ですよね？私たちはこういった言葉が無造作に使われているのを耳にします。どれも同じものとして扱われていることもあれば、明らかに対立していることもあります。どれが正しい用語なのでしょうか？
唯一絶対の答えを出す代わりに、これらの言葉の意味と、ことによると由来も見てみましょう。
起源
品質保証と品質制御は関連しています。品質保証と品質制御の周辺には、これらが一般的に何だと言われているかではなく、本当のところは何を意味しているかを理解するのに役立つかもしれない、興味深い概念がいくつもあります。適切に実施されているかぎり、品質保証と品質制御は、品質システムおよび品質管理プログラムの一部です。
品質保証 (QA)および品質制御 (QC) の起源は似ています。どちらも、部品またはコンポーネントのばらつきが良くないことである製造業に由来します。1920年代に最初に具現化された品質制御、また初期の議論においては、品質制御とはエンジニアリングの要件が満たされているかを確認しようとするものでした。
製造が複雑化するにつれて、「品質」やQCをめぐる考察も同様に複雑化していきました。そのような考察の大きな部分が、品質を制御し、プロセスのばらつきをおさえるための原則に発展しました。その目標は、現に動いているプロセスを定義されたプロセスモデルに準拠させることでした。
1950年代には、やはり製造業の分野で、品質のための「専門職」という概念が拡大し、初期のQAや品質監査職能を含むようになりました。これらは、公衆衛生や安全性が、最優先とは言わないまでも、重要である産業分野から発展しました。これが、製品の第三者レビューおよび監査につながりました。
「保証」という言葉の背後にある考えは、ランダムに選択された組み立て済みの部品が、非常に詳細な条件を満たすということです。差異が見つかったとき、定められた範囲内であれば、受け入れられる場合もあります。許容範囲外であれば、おそらく何らかの対処が行われるでしょう。対処には、組み立てプロセスを止めて部品をもっと厳しくテストすること、あるいは実行全体を破棄して新たに開始することなどがあります。
品質の「保証」は、品質の「制御」に依存しています。定義されたプロセスが完璧に守られていれば、ばらつきの余地は少なくなります。ばらつきの余地が少なければ、エラーの余地はさらに少なくなります。
このやり方は、装置などの物理的オブジェクトを組み立てる場合にはうまくいきます。同じ概念をソフトウェアの作成に適用した場合は、限界があります。
American Society for Quality (ASQ)による品質制御の定義には、プロジェクトの監査を行うようにと書かれています。その目的は、規定されたプロセスモデルに従っていることの確認です。ソフトウェアでは、各チームが独自のプロセスモデルを定義する場合があります。監査者にとって課題となるのは、チームや顧客のニーズに合わせてプロセスモデルが異なっている可能性があり、おそらくは実際に異なっているだろうと認識することです。
「1つのサイズですべてにフィット」させるというモデルは、どのチームにも合わず、役に立たないことが多いでしょう。目ざとく、経験を積んだ監査者であれば、これを認識できるでしょう。
品質
用語の「保証」と「制御」部分については、すでに見てきました。「品質」が意味するものについては、まだ見ていません。私たちが「制御」あるいは「保証」しようとしているのは何なのでしょうか？ここで、物事はややこしくなります。
「要件への忠実さ」という定義はよく引用されます。また、「(既知の)バグ/欠陥がないこと」も挙げられるでしょう。フィリップ・クロスビーやW・エドワーズ・デミング、石川馨を引用する人もいるでしょう。ソフトウェア業界のある方面の人たちは、伝説に近い故ジェリー・ワインバーグを引用するでしょう――「品質とは、誰かにとっての価値である」。別の人たちにとっては、ジョゼフ・ジュランが品質を「使用への適合性」と定義したことを引用するでしょう。彼ら「品質」周りの指導者達や思想リーダーには、それぞれ独自の特徴と微妙な違いがあります。
田口玄一の『Introduction to Offline Quality Control』は、また別の側面に触れています。田口によれば、「品質とは、製品が出荷後に社会にもたらす損失であり…本来の機能によってもたらされる損失以外のもの」です。この考えとジュランの考えを合わせると、別のより広い見方が生まれます。「品質とは、より広い害をもたらすことがない使用への適合性」であると言えるかもしれません。これは、ソフトウェアにとって重要な意味合いを帯びた定義になるでしょう。要件に沿っているかという疑問以上のものに対応しています。単に「正しいか」だけではない、より広い要件に着目します。この定義によって、「正しい」とは何かという、さらに広い概念が導入されます。
品質監査と品質検査
たいていの個人や組織には無視されている一組の概念があります。「品質」、品質プログラム、ソフトウェアテストとソフトウェア品質の関係を考慮することがなければ、それらは容易に見過ごされます。
物理的な工業製品の世界での検査とは、製品の特性を試験することです。それには、物理的な計測や、製品の1つまたは複数の特性のテストなどが含まれます。サイズは正しいか？コンポーネントは規定の許容範囲内に収まっているか？意図された荷重を処理できるか？
従来、こういった質問は物理的な工業製品に適用されてきました。ここ35～40年の間で、このような考えは工業製品だけでなくサービス製品にも適用されるようになってきました。質問への応答時間は指定された時間枠に収まっているか？顧客の問題はできるかぎりすみやかに対処され、解決されているか？顧客は常に作業の進捗や解決の見込みについて知らされているか？
品質監査は、品質検査と非常によく似ています。一番の違いは、監査には検査の一部の側面が含まれているが、目的は製品自体を検証することではないという点です。監査は、製品が製造される方法を評価します。
監査の目的は、定義されたプロセスモデルがどの程度厳密に守られているかを調べることです。違いがあったら？その場合は、違いの理由や必要性を調べます。目標は、作業が行われる方法を継続的に改善し、それによって製品自体も改善することです。「製品」が物品か、サービスか、あるいは私たちのケースで言えばソフトウェアかは関係ありません。
品質監査には、考慮すべき側面がもう1つあります。監査は製品の製造プロセスを調べるだけではありません。製品を検査するプロセスも調べて評価する必要があります。
これらの概念を考察し終えたところで、今度は、たいていの人が試みたあげく、無視したり、「何のことだかはみんなわかるだろう」という言い訳で片付けたりする、不都合な問題について考えてみましょう。
テスト
テストに対する一般的な見方の1つで、多くの人が「現実」の「正しい」見方だと考えるものによれば、ソフトウェアテストとは、動作を検証することです。テストは、文書化された要件に基づいて「合格」または「不合格」になります。ソフトウェアテストは、それらの要件を確認します。
しかし、ソフトウェアテストとは、それがすべてでしょうか？要件への忠実さを検証することが、ソフトウェアテストの唯一の目的なのでしょうか？それなら、ソフトウェアをテストすることは、工業製品やコンポーネントに対してデジタルマイクロメーターを使うのと同じことなのでしょうか？中心的な問題は、ソフトウェアテストとは何か、また何であると考えられているのかというあたりにあります。
ソフトウェアテストの一般的な定義は、「実際の結果が期待された結果と一致しているかをチェックし、ソフトウェアに欠陥がないことを確認するアクティビティ」といったところではないでしょうか。これに沿って、従来使われているある種の基準も、「合格/不合格」という結果の完全性および妥当性を示そうとする傾向があります。
基準には、次のようなものがあります。
- コードまたは関数カバレッジのパーセント値
- 自動テストと手動テストの割合
- テストケース実行の数
- 合格/不合格のテストケースの数
- 発見/修正されたバグの数
状況によっては、契約上の義務によってソフトウェアテストの「成果物」が定義されていることがあるのも承知しています。私の経験では、これはテストが意味する領域としては、極端に狭く限定的なものです。ソフトウェアプロジェクトがローンチに失敗したとき、あるいはリリース後に重大な欠陥が見つかったとき、訴訟に備えてある程度の防御を提供するくらいの働きしかありません。私の懸念は、これらの基準はテストについていくらか明らかにするかもしれないが、テストの有効性やソフトウェアの品質については、推論による以外に何も教えてくれないのではないかということです。
私がこのような疑問を提起したとき、確認としてのテストを提唱する人たちは、「ソフトウェアの品質」という問題は「テスト」の関知するところではないと答えることが多いのは、興味深いことです。つまり、テストは全体的なソフトウェア品質の問題とは関係がないというのです。
意味がわかりますか？私には意味がわかりませんし、正しいとも思えません。ひょっとすると、これを条件として受け入れるために必要な「テスト」の定義のせいなのかもしれません。テストとは何かについて、別々の定義を見ていたとしたらどうなるでしょうか。
Cem Kaner, J.D., Ph.D.は、また別のテストの定義を使っています。Kanerはテストを「ステークホルダーにテスト対象の製品またはサービスに関する情報を提供するために実施される経験的・技術的調査」と言っています。
この定義に従えば、テストはファクトベース(経験的)であるとみなされます。テストは適切なツールを使用します(技術的)。テストは必要とする人たち(ステークホルダー)に意味のあるソフトウェアの情報を提供します(調査)。
テストとは何かと尋ねられたとき、ここ数年、私が使っている実用的な定義は次のようなものです。
ソフトウェアテストとは、何らかのモデルに基づいて、ソフトウェアのふるまいを体系的に評価することです。
プロジェクトにふさわしいモデルを使用することで、組織の体感的な基準に頼る代わりに、適切な方法と技術を選ぶことができます。私たちが使うモデルが「文書化された要件への適合性」なら、私たちはソフトウェアを1つの方法でテストすることになります。パフォーマンスや負荷容量の面も知りたければ、別の方法でソフトウェアをテストします。
思考モデルは焦点を導き、思考を形作るのに役立ちます。特定のレンズを通して見れば、テスターはある項目に気付くでしょう。レンズ(モデル)を変えれば、テスターは別の項目に気付くでしょう。
特定のプロジェクトでどのようなビュー、モデル、あるいは複数のモデルを使用できるかには、契約上の制限があるかもしれませんが、単一のモデルを使用するようテスターを制限するルールはありません。大部分のソフトウェアプロジェクトは、テストで多数の思考モデルを使用する必要があります。
検査および監査としてのテスト
良いテストは、統制のとれた、思慮深い作業によって行われます。文書化された要件をテストするのも、1つの形です。多くの場合、問題は、どのように要件をテストするかという点にあります。特定の手順に従うというのもテストの1つの形です。これには、公開のデモで使用されるケースを明確にする、あるいは特定の問題シナリオを再現するなどがあるでしょう。パフォーマンス特性やさまざまな負荷を処理する能力を探ることもテストです。これらはすべて、「検査としてのテスト」の良い例です。ソフトウェアの作成後に検査を行っているのです。
良いテストを行うには、コミュニケーションが必須です。現実のコミュニケーションは、Emailでやり取りされる文書とは違います。コミュニケーションは双方向かつ対話的です。講義や独り語りではありません。すべての関係者が一致して連携していることを確かめるために、対話が必要です。
頻繁に連携が失敗するところに、プロジェクトの背後の動機や目的があります。どのニーズが満たされ、どの問題が対処されているでしょうか？良いテストは、プロジェクトの背後にある動機、現れるはずの変化に着目します。良いテストは、システム自体やソフトウェアを使用するユーザーへの影響を理解しようとします。
テスト自体は何も保証しません。良いテストは、安心に疑問を投げかけます。可能性を探り、発見されたことについて質問します。多くの場合、ソフトウェアが作成された後にテストが適用されますが、要件の理解や設計の適用性を評価し、潜在的な仮定や推測を検討するのにテストを利用するほうが、はるかに効果的です。こういったことは、品質監査としてのソフトウェアテストの例です。
良いソフトウェアテストは、現存のシステムへの影響について言及します。ソフトウェアテストは、プロジェクトのステークホルダーに利用されることによって、ステークホルダーの役に立ちます。ソフトウェアプロジェクトの究極のステークホルダーは、製品の顧客やエンドユーザーです。品質管理システムの第一の目標は、顧客満足度を最大化することです。
ソフトウェアテストが、製造物あるいは工業製品に対する物理的検査や機械的試験に代わるものということを考慮すると、テストは品質プログラムにおけるテストの機能から離れることはできません。
テストは成熟した品質管理システムの重要な一部です。テストは役割を果たすことができます。テストを完全に切り離すことはありえません。ソフトウェアテスターやソフトウェアテストが品質の高い「ビジネス」にとって重要でないとみなすのは不誠実です。テストは品質の高いビジネスそのものです。
参考文献:
Kaner, Falk & Nguyen, Testing Computer Software, 2nd Edition, Wiley, 1999
Charles Mill, The Quality Audit: A Management Evaluation Tool, MCGraw-Hill, 1988
J.P. Russel (ed.), The ASQ Auditing Handbook, 4th Edition, ASQ Audit Division, 2012
Philip B. Crosby, Quality is Free, McGraw-Hill, 1979
W. Edwards Deming, Out of the Crisis, MIT, Center for Advanced Engineering Study, 1988
Joseph M Juran, Juran’s Quality Control Handbook, 4th Edition, McGraw-Hill, 1988
Taguchi & Wu, Introduction to Offline Quality Control, Central Japan Quality Control, Assn, 1979
Peter G. Walenは、ソフトウェア開発、テスト、アジャイルプラクティスで25年以上の経験を持っています。ソフトウェアがどのように動作し、他のソフトウェアと連携するか、またソフトウェアを利用するユーザーをチームが理解できるよう支援に尽くしています。Agile Alliance、Scrum Alliance、American Society for Quality (ASQ)のメンバーであり、ソフトウェアミートアップに熱心に参加し、カンファレンスでもたびたび講演しています。
（この記事は、開発元Gurock社の Blog 「Quality and Testing」2020年3月10日の翻訳記事です。）
