オフショア開発スタートアップ、オフショア開発事例、オフショア開発ラボ型

【オフショア開発失敗事例】テストケースの未作成によるトラブル

10 View

この失敗事例はオフショア開発ラボ型でテストケースを作らなかったことでスケジュール遅延が起こり、その後機能の認識違いへのトラブルに発展したケースです。

失敗の解説

オフショア開発を含め、システム開発では完成したシステムの状態の認識があっていることが必要です。

この完成した状態の認識は、システム開発を行う上で非常にズレやすい内容です。

そのため、さまざまな情報を整理し、詳細まで要件にあっているかテストを行っていきます。

この失敗事例では、テストケースを作成しなかったことで、完成した状態の認識がずれました。

そのズレを直すために、スケジュール遅延が発生し、大きな修正がトラブルに発展した事例です。

プロジェクトの主な問題

システム開発において、完成した状態の共通の認識は、とても大事です。

システムの機能や要件は広く多岐にわたるため、詳細まで認識を合わせておかないと、システム全体に影響が発生します。

テストケースは作成しなくても、分かりやすい機能については大きなズレは発生しません。

しかし、小さなズレがさまざまな場所に影響し、修正に大きな時間と手間が発生し、大きなトラブルにつながりました。

具体的な対策方法

他の失敗事例でも発生しているように、オフショア開発の失敗事例の多くはテストに関連することで発生しています。

テストは、地味で、手間のかかる作業です。そのため、後回しになりがちです。

しかし、今回の事例のように1つずつのテストは小さくても、大きなズレとなり、不具合や修正に繋がります。

対策するには、契約まえに機能とテストを必ず作成しましょう。ラボ型であれば、開発サイクルを決定するときに、機能とテストは1セットです。

その後のプロジェクトの経過

オフラボのサポートもと、テストケースの作成、実施の徹底を行いました。

発生してしまった認識違いやテスト未実施については、地道に修正を行うしか方法はなく、テストを作成し、致命的な機能修正から優先順位を決めて、開発を進めました。

関連記事

【オフショア開発失敗事例紹介】 決済サービスの申請トラブル

2022/11/28 オフショア開発の基本 詳しく

【オフショア開発失敗事例】決済システムの申請トラブル

2022/11/24 オフショア開発の基本 詳しく

【オフショア開発失敗事例紹介】テスト後の修正を拒否された事例

2022/11/23 オフショア開発の基本 詳しく

【オフショア開発失敗事例】タスク管理トラブル

2022/11/23 オフショア開発の基本 詳しく

【オフショア開発失敗事例】日本語での情報共有の誤解

2022/11/22 オフショア開発の基本 詳しく