【連載】テスト計画

  • このエントリーをはてなブックマークに追加

テストとは、不具合を発見するためにするのであって、不具合がないことを確認することではありません。
このことを意識すると、テストのた
では、テスト計画はどのように作成すればよいでしょうか?

単体テスト

単体の定義は、画面単位・関数は関数単位で考えるが妥当になる。注意すべきは、非機能含めたカバレッジ(網羅性)である。ようは、IF 文、CASE 文の全パターンを疎通させテストするのである。
また、データベースに想定したデータが登録・更新されていることを確認する。

結合テスト

結合の定義は、画面・機能間の前後間のデータ連携を確認する。ITは機能間の連携で成り立つ。前後間の矛盾がないことを確認する。

総合(システム)テスト

総合テストでは、全ての機能の流れをテストする。流れは業務視点でシナリオを作成してテストをする。

連携テスト

連携テストでは、他システムとのデータ連携のテストをします。

ユーザーテスト

実際に利用するユーザーが操作し、要望通りの仕様になっているか確認します。

運用テスト

ユーザ部門が実際に利用して確認するテストである。注意は機能ではなく、運用視点でテストをすることである。当然、システムを入れ替えれば、運用も改善する。運用設計の矛盾も発見して改善する。
重要なのは、どう運用するかである。
常に課題はつきまとう。1つ1つ課題を優先順位が高い順に解決していかなければならない。しかも、課題は次々と増えていき、いくらやっても減らないことは想定する。だから、効率よく情報連携する仕組みが必要になる。また、マメなコミュニケーションが必要になる。このルールが大切になる。

  • このエントリーをはてなブックマークに追加

SNSでもご購読できます。