試験の観点について

試験の重要性に気づくとき

システムの各開発工程をいろいろと経験していき、プロジェクト全体をリーダーとして管理していく立場になったときや、仕様は自分が理解しているが、作業を他人に任せ、それを回収をしたときに、なにをもって品質の担保がとればいいのかということに気付かされます。
試験の重要性を開発担当者の立場だったときよりも、プロジェクトリーダーなど管理者側の立場になったときの方が意識するようになります。

現実的に、プロジェクトリーダーなど管理者が全てのテスト結果を細かく見ていくことは難しいと思います。


問題を事前に防ぐためにテストのプロセスを見直せないか考えます。
そこで、開発担当者、テスト担当者だったときのテストに対する認識を振り返ってみると、プロジェクト管理者の立場とは大きな違いに気づきます。


プロジェクトリーダやSEの立場では、テスト担当者にバグを出せる限りだしてほしい、仕様上の漏れ、矛盾点を洗い出してほしいと考えます。


しかし、テスト担当者は、工程を早く終わらせることが第一の目的になってしまうことが多いように思います。指標どおりのバグも出します。件数を競うかのように闇雲に件数を消化します。


これは、テスト担当者の評価は、担当する作業をスケジュールどおり(前倒しで)終わらせられるかどうかという点が優先されてしまうからです。

一般的にテストは誰でもできるものとみなされ、仕様も理解しない新人やコストを抑えるための外注の仕事になっている現実をみても理解がむづかしくないと思います。


極端なところ、テスト担当者は、製造にタッチもしない、仕様にタッチもしないので何が正しく何が間違っているのかがわからないのです。


結局、テスト工程の始めのほうはスケジュールどおりに進んでいても、後ろの工程でそのしわ寄せが生じます。システムのQCは向上しない、バグの発生件数が収束しないということになってしまうことも少なくないと思います。

そもそも何のために試験をするのか?

時間も人も掛かる試験工程を無駄にしないために試験の目的を考え直してみます。


試験の目的は、試験工程とは、設計・製造したものの品質を保証すること


単体試験工程に焦点をあてます、このフェーズで確認できると単体試験以降でないと確認できないことがあると思います。


単体試験の工程だからできることは、ホワイトボックス試験です。
個々の命令が正しい判定で正しく実行されることを確認できる工程に思います。

この単体試験の観点は、「条件網羅」になります。


結合試験、総合試験では、処理されるデータの整合性の確認を行うことになります。
テストケースやシナリオを作成して試験はブラックボックス試験になり、実際にソースを追いながら確認をとることはなくなります。


単体試験自体を自動化するという考え方やデバックを通しながら製造しているから単体試験を省略するという意見もあるようですが、単体試験工程からブラックボックステストを行うということは結合、総合試験と観点が重複するので、単体試験はやっても意味がないという判断に理解できます。


また、結合、総合試験の段階で、「処理が途中で中断してしまう」、「判定が間違っていた」、「メッセージ内容が違う」ような単純な障害が起こると、試験の前提条件が崩れてしまうので、手戻り作業が膨大で試験の実施スピードが遅れてきます。(1つの確認漏れがあったことがわかると同様の確認漏れがあるのではないかと推測します。)

類似の問題がないかの確認を調査、確認、修正をする必要も出てきます。


単体試験の観点を、条件網羅としてソース上のすべてのルートを通します。これにより、処理が途中で中断することが無くなります。


ホワイトボックステストをするメリットは、実装した命令文ごとに実行が正常に行われるかどうか、条件ごとに処理が正しく行われるかを1処理、1分岐ごとに確認することができることです。


このとき重要なのは、試験は境界値や限界値を使って行うことです。


ただ、ホワイトボックステストにもデメリットはあります。

それは、実装した命令文が正しく処理されていることの確認であって、詳細仕様書どおりの機能が実装してあるかどうかを判断することができないことです。

「Around UT」はソースコメントから単体試験項目表を一括出力

これらを踏まえ製造完了時から単体試験工程を効率的に進めるためには、

  1. 製造完了したら、すべてのコメントの記述を見直す。

    ソースコメントを正確に記述することは製造工程の作業です

  2. 漏れのない試験項目表を作成する

    単体テストの工程を自動化するのではなく、試験項目表の作成を自動化


    「Around UT」で試験項目表を作成
    ※コメントの未入力チェックを行うことができます

  3. ソースレビュー(以下を並べてレビュー)

    ・詳細設計書

    ・ソース

    ・単体試験項目表


    詳細設計書とソースをチェックすることで機能の実装漏れを確認

  4. レビュー結果を修正、試験項目表の再出力
  5. 単体試験実施

    試験で使用するパラメータは、境界値、限界値

詳細設計書をもとに単体試験項目表を作成していくのが本来の考え方ですが、詳細設計書からソースも作られます。ソースのコメントをベースに単体試験項目表を自動で作成し、詳細設計書と照らし合わせれば漏れのない単体試験項目表が作成できます。


試験担当者は、パラメータを正しく設定する必要があります。

ソースを追っていきながら試験を進めることになります。


ソースを解釈しなければ試験を完了することができないので、ソースを解釈しながらテストを行うため仕様を意識することにもつながっていきます。




最終更新日:2012年05月18日



inserted by FC2 system