テストだけが品質担保の手段ではない!

ソフトウェアの品質を確保するために、発注要件が満たされているかを確認する“テスト”は重要な作業になります。

ただ、開発のプロジェクトにおいては、もちろん納期があるので、テストに使える時間は限りがあります。できるだけテストにかかる時間を短くして、効率よく品質の向上につなげるにはどうしたらいいでしょうか。

そのためには、設計、プログラムの段階でいかに品質を意識して取り組めるかがポイントだと思います。

＜設計＞

設計で重要なのは、設計フェーズで検討した資料もドキュメント化して残すこと。

複雑な要件やいろいろなケースが想定されるようなものを作る場合、設計フェーズでもさまざまなケースを想定をすることは多々あります。どういう時にどうなっていないといけないかという観点の資料を作成しておくことで、後にテストケースやテストの観点を考える時の補助資料にもなります。

さらにそれをドキュメント化して設計書に組み込んでおくことで、設計書レビューの時に、ケースや認識の間違いに気付きやすくなり、プログラマーへのインプット時にもテストの観点等の共有にもつながります。

＜プログラミング＞

プログラミングでは、プログラムの構造を複雑にしないことが重要となります。例えば同じ処理が何度も書かれているものや、無駄な変数を定義していたりなど。

複雑な構造にしないためには、プログラミングをする前に処理構造をきちんと理解することが必要です。

そして、自分で作った物がわかりやすいかどうかを自分で判断するのはなかなか難しいと思うので、他の人にコードレビューしてもらったり、他の人が作成したプログラムを読んだりして、他の人の意見を見聞することで、学んでいくといいと思います。

複雑なプログラムは、理解しづらく、間違いも発見しづらい、テストするのも大変な労力を費やすことになります。わかりやすく構造化された構成になっていることで、他の人が見た時の理解のしやすさ、保守性の向上、テストのしやすさ等の効果が期待できると思います。

品質の向上は、テストで確保するのではなく、設計、プログラミングのタイミングから意識して実施することから始まります。テストだけが品質担保の手段ではないのです。

テスト開始時に品質が悪い場合、不具合を見つけることがテストの主体になってしまい、本来確認すべきソフトウェアの品質のために時間をさけない状況になってしまいます。
だからこそ、テスト開始時にいかに品質を担保してスタートできるかがポイントなのです。

ここの精度が向上することで、テストツールを利用したテストがスムーズに出来たり、テストにかける時間も短縮出来ます。そして、本来確認すべきソフトウェアの品質の確認に重点をおいたテストが可能になり、効率的にテストができるようになると思います。