はじめに
情報システム部の方で、ITに詳しいだろうからという理由で、ビジネス用のシステム開発のマネージメントをするように依頼されることはないでしょうか？
実際は情報システム部の仕事と、ビジネス用システムの開発は大きく異なるものかと思います。
また、非IT企業では、システム開発を依頼する機会も少なく、一発勝負になることも多いです。
そんなお悩みを解決できるよう、いち非IT企業の情報システム部メンバーとして、実体験に基づくシステム開発の依頼の流れをまとめさせていただきました。
システム開発でお悩みの方は、是非見てみてください！
またITベンダーの皆さんにも企業側はこんなこと考えてるんだなーと思ってみていただければ嬉しいです。
テスト計画とは？
目標とする、網羅率・テスト密度・バグ密度を規定し、テストの計画を立てること。各テストの役割についても記載し、テスト全体で総合的に問題を発見できるように見通しを立てること。
試験の構成
- 各試験は対となる設計書が存在するため、それぞれの回答となっているかを確認するように進める。 （単体試験であれば詳細設計、結合試験であれば基本設計を参照する。）
- 試験構成全体において、網羅的に試験ができることが求められる。
- 単体試験でできない範囲を、結合試験で行うといった思想が重要である。
テスト密度・バグ密度
プログラムのステップ数（コメントなどを除いたコード行数）をもとに、テスト件数、バグ件数が妥当であるかを判断するために利用する指標である。IPAが発行している情報を元にシステムに求めるテスト数・バグ数を決定していく。
テスト密度 = テスト件数 / ステップ数
バグ密度 = バグ件数 / ステップ数IPAの指標にはテスト密度、バグ密度は、”最小”・”P25”・”中央”・”P75”・”最大”と分解して記載されている。このどこの四分位数に当てはめていくべきかを検討する必要がある。
このためには、以下等の観点を用いる
| 観点 | レベル |
| 開発規模 | 開発工数などをもとに勘案 |
| 結合箇所 | ○○点 ※システムインターフェイス数など |
| 複雑さ | システムの複雑さ、特別な仕様があるか？など |
| スキル | 開発に必要なスキル、特別な言語を利用するのか？など |
上記を検討したのちに、結合点が多いなどあれば、結合試験時のバグ密度を増やす（P75指標を目標とする）などの検討を行う。
結果確認
テスト密度・バグ密度の結果をもとに確認を実施していく必要がある。
下記URLの考え方が非常に分かりやすいため、リンクを記載する。
[参考URL]
テスト密度・バグ密度は、どこのゾーンにいるからNG/OKというわけではなく、ゾーンを参考にバグ状況を勘案し、対応方針を決定する必要がある。だが、経験上、右バッター外角ゾーンに位置すると危険な場合が多い。これはテスト密度が低い場合であり、テスト件数が十分でない場合は往々にして観点漏れが発生していることが多いと想定されるためである。
コメント