そんなこんなで、開発フェーズ第６弾の３回目です。
○開発フェーズ
１．概要設計
２．要件定義
３．詳細設計
４．開発
５．テスト（単体、結合など）
６．テスト（受入、検収、承認など呼び方は様々かと）
７．リリース
ユーザー企業が実施するテスト
私は自分の会社しか知らないですが、きっと色々あるんでしょうね
・機能確認はもちろん、異常動作や限界値など徹底的に実施するところ
・基本動作だけ確認してＯＫとするところ
・なにもやらないところ
私の会社は「徹底的にやる」ところです。
ＩＴベンダーが「もう勘弁してください」というくらいやります。
個人的にはユーザー側もきちんとテストすべきだと思います。
ただ、境界線はあるべきだと思いますね。
ここはユーザー側も確認した方がいいけど、ここはベンダー側で保証すべき、と
例えば、レスポンス
これは計測結果などを見ればわかりますが、やっぱり実際に動作確認してみないとわかりません
リプレースシステムだった場合、画面遷移が１秒遅くなるとエンドユーザーから「遅くなった」と言われることもあります。こういうことはユーザーが確認した方が良いと思いますね
なんか書こうと思った内容から外れた・・・方向修正・・・
１．テスト計画書
テスト計画書がテストを成功に導くポイントだと思っています。
ここでどこまで練りこんでおくかで、あとの作業がずいぶん変わります。
ポイントとしては下記だと思います。
・なぜこのテストをするのか？
・何を確認したいのか？
・ＯＫとする基準はなにか？
・テスト実施内容の切り口はなにか？
・どのように実施するか？
ん～なんか当たり前なことだな
テスト計画書はリーダー格メンバーが中心で記述するので、メンバーとＩＴベンダーへ意思を伝えるドキュメントとしても重要です
２．テストケース作成
テスト計画書をもとにテストケースを作成します。
テスト計画書に記述されている内容を網羅的に実施するためにどうすれば良いかを具体的に落としていく作業です。
マトリックス表を作ったり、項目洗い出ししたり、と手法は色々あります。
網羅度を上げるためには基本設計書を理解しておく必要があります。
またユーザー側のテストですので、業務視点からケースを作成することもポイントです。
システム視点だけでなく、実際の業務ではこういう使われ方をする。だからこういう確認が必要、という視点です。
３．チェックリスト作成
テストケースをさらに落とし込んだ資料になります。
テストでは、そのシステムに精通した人だけで実施するわけではないので、誰が読んでも出来る内容にします。ただ、あまりにも細かく記述するとテスト効率が落ちますし、柔軟性がなくなるので、サジ加減が難しいところです。
基本機能確認では、こういうデータを準備して、このボタンを押したら、こうなる（はず）と記述することが多いです。基本的な考え方はその辺に歩いている人を連れて来ても実施出来るように書く、です。
ただ、全資料をこの考え方で記述するとむやみに項目数だけが増えるので、一部のケースだけに留めます。
残りの資料は基本操作やシステムがわかっていることを前提に記述します。
チェックリスト作成は力技な作業になることが多いので、ツールなどを活用すると効率的に作成出来ます。
そんなこんなでテストを実施していくわけですが、テスト中に苦労した事例を次回書こうと思います。