みなさんの配属された現場では、どんなテストを実施していますか。テストを分類する用語は様々で、それぞれが意味するところも組織やプロジェクトによって様々です。ここでは一般論として概要を説明してみますので、みなさんの現場に照らし合わせて考えてください。

テストの種類と意味を知る

機能やサブシステム、レイヤやライブラリ、モジュール、コンポーネントなどなど、「システムを分割した単位」を表す言葉がたくさんあるとおり、システムの設計の中で重要なアプローチに、大きくてそのままでは扱いづらいものをどのように分割するか、分割したものをどう繋ぎ合わせるか、ということがあります。

みなさんも、プログラミングを担当した箇所で、メソッドや関数を見通しが利く範囲で切り分けたりすることがあると思います。そのように「分割した単位」が、分割した意図に沿って正しく動くかどうか検証するのが単体テスト、分割したそれぞれを繋ぎ合わせて動くかどうか検証するのが結合テスト、というわけです。ですので、「単体テストとはなにか」「結合テストとはなにか」は、そのシステムをどう分割するかにまつわる、各プロジェクトの設計方針によるところが大なものです。

その上で、システム全体としてちゃんと動くか、ここでの「ちゃんと」とは「要件定義したとおりに、業務が回るか」もそうですし、「障害時に復旧できるか」「アクセスが集中してもパフォーマンスが出るか」「長時間連続運転しても大丈夫か」といった観点もあります。これらを検証する全体がシステムテストで、その内部分類として、「ちゃんと」というときの観点によって、業務運用テスト・システム運用テスト・パフォーマンステスト・ストレステストなどがあると考えるとよいでしょう。

テストの種類と意味を知る

テストの準備と実施

多くのプロジェクトでは結合テストとシステムテストを、プロジェクト全体での公式・本格のテストと位置づけています。こうしたテストは、関わる人も多く、作業も複雑となるため、事前の準備が非常に重要となります。

たとえば、結合テストをするためには、結合対象のものがどういう順番で、いつ完成するかといったスケジュールも考慮する必要があります。システムテストなら、本番環境でのテストが望ましいところですが、本番環境はひとつです。場合によっては他のシステムが稼動しているところに相乗りすることもあります。いつどんなテストを実施できるか、トラブルがあったときの対応は万全か、しっかり段取りしなくてはいけません。

もちろん、テストすべき事項を洗い出し、それぞれにテストの手順、必要なデータを明らかにするなど、テストそのもののコンテンツも準備します。多くの人が連携して動く活動だけに、テストが進められなくなるようなバグが出たらどうするかなど、リスクも考慮に入れた段取りが重要です。テストは段取り八分、実施前に勝敗は半分以上決まっています。