＃8：包括的な統合テストを実施する
納期が迫ってくると、ユニットテストに注力し、エンドツーエンドの統合テストを軽んじる傾向が生み出される。しかし、アプリケーションが他のソフトウェアやハードウェアとうまく連携できない場合、問題が必ず表面化し、業務にも悪影響が及ぶことになる。
＃9：ストレステストは必ず実施する
プロジェクトの歴史をひも解いてみると、品質保証テスト環境では素晴らしい結果を残したにもかかわらず、本番環境における大規模なトランザクションや、予想を超えたトランザクション負荷を処理できなかったというアプリケーションの話で満ちあふれている。このような事態が起こった場合、業務が最も必要とする時にアプリケーションがその要求に応えられなくなる。ITリソースには限りがあり、本番並みの大規模なトランザクション負荷をエミュレートできるだけのテスト環境を準備するのは難しい場合も多い。とは言うものの、アプリケーション開発者は、ストレステストを完了していないアプリケーションの本番移行を良しとしてはいけない。このことはサービス業や航空会社、金融機関、小売業、株式売買関連といった分野において特に重要だ。こういった分野の業務で大規模トランザクションが取り扱えなかった場合、巨額の損失が生じる結果となる。
＃10：まめにプロトタイピングを行う
アプリケーションの準備段階であっても、使い勝手や見た目といった点をエンドユーザーにレビューしてもらうのがよいだろう。工程の初期段階であれば調整は簡単に実施できる。早い段階からエンドユーザーを巻き込むことで、アプリケーションを最終的に配備した際に、それが彼らの期待していたものとは違ったと分かるという、不快な驚きを避けられるようにもなる。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。
