国民宿舎はらぺこ 大浴場

職場で QA という言葉を使ったら、思ったとおり通じなかった。あの状況を見る限り、無理もないか、とは思ってたけど。とりあえず、QA について、おいらのキャリアで身についていることをメモっておこうと思う。

QA とは?

Quality Assurance の略。品質保証。

ソフトウェア開発における QA

基本的には、以下の4つの観点に基づいて行われるべきである。

1. 期待通りに動作すること。
2. リソースリークが発生していないこと。
3. パフォーマンスが十分であること。
4. 上記を証明するすべてのテストにおいて、カバレッジが満たされていること。

行うべき作業は主にテスト（動作検証）だが、テストをすれば QA が満たされたということにはならない。どのようなテストを行い、その結果がどうなったかを文書にまとめ、報告できる状態にすることで、初めて QA は満たされたと看做すことができる。

要求に対する QA

「1. 期待通りに動作すること。」の「期待」とは、究極的には顧客の要求である。要求には、潜在要求も含まれる。顧客がそれを言ったかどうかではなく、ユースケースを取りまとめ、要求内容を整理する中で洗い出しておく必要がある。レビューは、そうしたものを追求するためのひとつの手段である。

QA の成果物

設計の成果物として設計文書があり、開発の成果物としてプログラムがある。QA の成果物もプログラムであるが、それとは別に、QA を証明するための報告書が必要になる。

作成すべき報告書は、大まかには以下の三つ。実際にはこのような構成ではなくて、機能別、または観点別に、これらの内容が満たされるように記述するという形でも良いと思う。

• テスト仕様書

  テスト項目一覧と、その内容を記述したもの。また、テスト項目ごとにその目的 (対応する設計上の項目、過去に発見されたバグの内容、等) も記述されているべき。

• テスト結果報告書

  期待動作はテスト仕様書に記述されているはずなので、基本的には、ここではテストにパスしたかどうかだけを書けばいい。実際には実施したテストの回数とテストごとの項目数、テストごとに新たに発見されたバグの数、修正された数などを集計した数字と、それを時系列順に並べたグラフを統計結果として載せたりするが、それ自体は QA を証明する目的というよりは、開発スケジュールに無理が無いかや開発体制に問題が無いかを検証するための目安として用いられるべき性質のものである。

  なお、基本的には、最終的に既存バグは0で無ければならないが、何らかののっぴきならない事由 (時間が無いとか、修正による影響範囲がでかすぎるとか、機種依存バグとかで原因が解明できないとか) により、修正を行うべきではないものとしていくつかのバグが取り残される場合がある (っていうか大抵いくつかは残る)。そのような内容は制約事項として、この文書の中で明記されなければならない。制約事項を書く場合には、そのバグによる不具合が何なのか、その不具合を回避するにはどのように操作すればよいか、といったことを記述する。

• パス解析結果報告書

  カバレッジ (テストにより通るコード上のパス通過) が満たされていることを報告するための報告書。カバレッジが満たされていないということは、テストに抜けがあるということなので、仕様を確認したうえで、テストを追加するなり、不要なコードを削除するなりする必要がある。

  通常は、ツールを用いた解析結果に基づき、モジュールごとに何パーセント、全体で何パーセント通過しているかを記述した上で、通過していないパスがあればそのパスに関する説明を付記する、といった内容になる。

QA とバグ管理

過去に見つかっていたのと同じ内容のバグが、リリースする製品に含まれるようなことは絶対にあってはならない。そのため、バグ管理とテスト管理はリンクしているべきである。

バグの種類、内容にもよるが、バグが発見された場合、その対応として、再現状況の確認、原因の究明、修正、テスト、といったフローを経る。このとき行うテストは通常、このバグを発見したときに行ったテストをそのまま行うべきだが、バグというのは必ずしも発見したときに実施していたテストに対応した内容であるとは限らず、特に手作業でテストを実施している場合などで、テストの意図とは関係なしに偶発的に見つかったというケースは少なくないし、そもそもテストではなく、別の目的でちょっと動かしてみたらたまたま見つかったとか、ユーザーからの報告であるとかいった場合もある。そのようなケースでは、そのバグが再現しないことを確認するためのテストケースを、新たに追加する必要がある。その後のメンテナンスを考えれば、そのようにして追加されたテストが、過去にどのようなバグが発見されたことに由来しているのかを参照できるのは、非常に重要なことである。

回帰テスト

既存のテスト項目を元にテストを実施することを回帰テストと呼ぶ。回帰テストは自動化されていることが理想だが、いずれにせよ、すべての回帰テストを実施するのにどの程度の時間がかかるのかは把握されている必要があり、その時間に基づいて開発スケジュールは組まれるべきである。

回帰テストにかかる時間が短ければ短いほど、テストと修正のサイクルを増やすことができる。例えばすべての回帰テストが自動化によって12時間で回るようになっていれば、テスト実施者が帰り際にバッチを実行し、翌朝からその結果を受けて修正、夜またバッチを実行、という形で毎日テストを実施し、急ピッチで品質を向上させることが可能だ。

QA のゴール

QA のゴールはバグをぎりぎりまで減らすこと、ではありません。そもそも製品の品質は、発見されたバグの数だけで安易に推し量れるものではありません。もちろん、リリースの段階で、製品が十分に安定していることは重要ですが、QA とはあくまで「保証」であり、その製品が何処まで安定して動作しているのかを証明することこそが、QA のゴールであるといえます。

例えば、エレベータには定員と、最大積載重量が明記されています。理想的には、人を何人乗せ、どんなに重いものを一緒にどれだけ乗せても、動作し、事故も起こるべきではありませんが、現実的には、物事には限界があります。そうしたとき、十分な利便性が確保されているならば、運用においては安全性が確保されていることが最も重要であるということになります。例えどんなに頑丈なエレベータを作ってくれたとしても、「とにかく頑丈に作りました」としか言わないメーカーと、「最大 10人まで、総重量 600kg までであれば安全に動作します。 600kg を超える場合にはブザーにより警告を通知し、その間は運転を開始しません」とまで説明してくれるメーカーとでは、どちらが信頼に足るでしょうか?

QA とはそういうことです。すなわち、「こういう風に動かす限りは問題なく動作するよ」ということを、できる限り網羅的に証明すること。そして、その網羅性を確保するために、潜在要求をきっちり洗い出しておくことこそが、重要なのです。

。。。とりあえずこんなところで。後で追記するかも。