実装者が、己の実装が仕様に基づき正しく行われたことを証明するためのドキュメント。
なお、定義については[[追加開発ドキュメント>成果物/追加開発ドキュメント]]参照のこと。
----
#contents
----
* 概要
** 作成目的 [#yd7e2932]
実装者が、[[詳細設計書>成果物/詳細設計書]]の内容＝仕様に基づき実装されているかという観点で試験を行い、その結果を記述するために作成する。
ここで重要なのは、あくまで仕様を担保するためであり、要件の担保ではないということである。
一般的には、ホワイトボックステストを用いるケースが多い。
** 作成単位 [#yd7e2932]
[[詳細設計書>成果物/詳細設計書]]と1:1で作成する。
ただし、仕様によって或いは不具合対応や仕様変更による改版で画面コピーの総量が多くなるため、第一版以降は差分作成が妥当であると考える。
余談だが、10M以上になったUT結果を見ると、常識どころか人格を疑ってしまう。
単に重いと開くのも編集するのも難儀であるし、今はともかく昔のExcelファイルは少し重いとしょっちゅう壊れていた。
** 作成担当 [#yd7e2932]
原則として実装者が作成するが、そうでない場合は、試験項目のレビューを条件として実施するべきと考える。
** 作成タイミング [#yd7e2932]
開発物の改版ベースでメンテナンスを実施する。
但し、緊急事態においては、直接顧客確認をもってokを出すケースもある。
** 更新ルール [#yd7e2932]
プログラムの修正都度。
「仕様はOK、実装がNG」というケースもあり、必ずしも設計書とペアでメンテするわけではない。
* 個別トピック
** テスト項目について
私がこれまで見た中では、八割以上の開発者がまともなテスト項目を作ることができなかった。
その原因は、
-「バグを見つけるためにテストをする」ではなく「バグが無いことを証明する」という誤った認識、テストに対する考え方がそもそも誤っている
-「正しいことを証明する」というスタンスであるが故に、「問題なく動作する」という結果ありきテストをしてしまう（そんなテストに意味はない）
-テスト項目に網羅性を考えない
-IF分の数だけデータパターンが存在するはずなのに、テストケースに落とさない
-検索ヘルプなどSAP標準が関わる部分のテストは不要だと考えている（使い手にとって、不具合が標準だろうとアドオンだろうと関係はない）
などが挙げられる。
時間は取ってしまうが、組めるアプリコンサルなり開発リードなりのレビューを入れた方がよい。
理由は、不具合は発見してからでは、まず原因を正しく把握することから始めるため、最初に出来る限りの品質を担保しておいた方がトータルで費やす時間は減るはずだ。
しかし、開発者は何故「テスト項目をレビューする」というと嫌な顔をするのだろうか？
ひょっとして後ろめたさを自覚しているからでは・・・なんて勘ぐってしまう。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)
