impedance(インピーダンス) 全てに抗え!!

この世の全てに歯向かい、抵抗することでしか存在を見いだせない愚直な漢のオルタナティブ? ブログ

テスト業務の進め方について

システムを構築する際、ユーザーに納品する前に一番最後に作成されたプロダクトについて、

意図したものとなっているかテストを実施する。

そのテストについて、詳細は各プロジェクトごとに異なるが、一般的には以下のように工程が組まれている。

 

単体テスト結合テストシステムテスト→運用テスト。

 

尚、工程を分割しているのは、納品するにあたって、

品質担保するために行わなければならないテストの内容が多岐にわたるため、1工程では全てを網羅しきれない。

そのため、テスト業務自体を幾つかの意図を持たせた単位(工程)に分割し、

その工程ごとに実施、管理することでテスト全体で漏れや重複がないようにしている。

 

ということは、その適切に分割された各工程ごと、その意図に応じたテストをくまなく実施していれば、

運用に耐えうる品質のものを提供できるはずなのだ。

 

でも、実際はどうか?

現実には、商用で何件かシステム故障を摘出されてしまっている。…orz

現実は渋い…。

 

上記にも書いたとおり、各工程でしかるべきテストを実施していれば、商用で問題は起きないはずだ。

ノーミスで十分なテストを行っているのであれば。

 

しかし、現実問題として、各種テスト工程でノーミスで十分なテストを行うことが可能なのか?

 

現実には、テスト作業を進める上、内外とわず阻害となるケースが発生し、残念ながら十分なテストが行いきれない。

そのケースを思いついた分だけ幾つか上げる。

  

  ・ 試験者のスキル

      試験者によって、その機能で行うべきテストの範囲の見極めが甘く、網羅性が不足してしまったケース。

 

      確認する箇所および、タイミングの誤り、試験手順の誤り、テストデータの誤りなどで

      実施したテストが意図したものと異なるものとなってしまったケース。

 

      テスト自体の難易度が高く、確認する箇所が多い、または複雑なため、

      十分に確認しきれないままテスト完了としたケース。

 

      また、試験項目票に則って試験していく上で、試験項目ではない箇所で故障発生している場合があり、

      その部分に着眼点を置いていないためを見逃してしまい、結果的に故障を摘出出来なかったケース。

 

      あと、あえて書くが、手抜きで試験実施を省略としているケース。

 

  ・ 時間的制約

      テスト期間が短いため、一部のテストが行えず、省略してカットオーバーを迎えたケース。

  

  ・ 環境的要因

      他システムとの連携試験時、他システム側に意図したデータが登録されていないため、

      そのデータを使った。意図したテストが行えないケース

 

      また、実際に他システムと連携しておらず、疑似的にそれを実現している環境での試験では、

      その動作が本来の他システムと連動したときのものとの違いにより、

      意図した内容の試験が行えないケース

 

  ・ プログラムの幾多の改修による適切なバージョンでのテスト。

      幾度もプログラム改修が適用されるため、納品されるバージョンでの試験が不足してしまう。

  

  ・ 提供した機能が実際に開放されるタイミングでの相違で発生する問題点

      機能自体はテストを実施し、商用に提供しているのだが、運用側の都合でその機能を抑止しており、

      その後、幾つか別の機能、処理のバージョンアップを行った後、既に提供している機能の開放を行ったケース。

 

      対象の機能にもよるところはあるが、

      このケースではテスト実施した環境と機能開放時の環境がイコールではないため、

      一度品質を担保して提供した機能が、その後のバージョンアップのため、意図した品質が保証されてない状態に陥る。

 

プロジェクトの性質、規模、期間にもよるところもあるだろうが、

結論として、上記に挙げた要因1つ1つ解決して、ノーミスで十分はテストは行いきるのはまず難しいと思う。

最低でも、1度だけのテストでは、行ったテストが十分なものには至らないと考えている。

  ※ だからといって、プロダクトに故障を混入させていいという理由にはならないが...

 

そこでテスト作業について、「何とかしてでも1回で完了させる。」よりも、

「どんなに頑張っても、1回では十分なテストは行いきれない。」という前提で、

テスト業務の各工程を組んだ方が有益なのではと思う。

 

具体的には、一連の試験終了後、冗長気味ではあるが再テストの実施。

特に有識者による再テストが望ましい。

といっても、機能全てを再テストするのは当然不可能なので、

一部のクリティカルな機能。またはスキルが十分でない人間が行った試験等に限定すればいいと思う。

  

または、既にリリースした機能について、以下のような再テストを行った方がいいと思う。

   ・ 前バージョン、および前の前のバージョンで提供した機能の再テスト。

        → ユーザにあまり使われていない機能のため、品質が安定していない。

   ・ 申告が多い機能についての再テスト。

       → 観点に漏れがある可能性があるため、再テストにより、品質保証する。

 

商用で故障を出してしまっている可能性があることを認めることになり、

ユーザ様には事実として言いにくい部分もあるのだが、

この既に提供した機能でも再テストを施すことは、品質を高めることに有効だと考えている。

実際、そこで故障を摘出することがあれば、その後のアクションにより

被害を未然にあるいは、少なく食い止められることも可能と考えている。

 

特に、特に、短いサイクルで結構な規模のシステムバージョンアップを求められるシステムでは、

テスト工程をただ単に直線的を進めるのではなく、

このように途中で厚みを持たせつつ、曲線的に進めていくほうが適切だと考えている。