なぜ品質とテストを自分で読むのか
出してよいか、受け入れてよいかを決めるのは、発注する側です。作った会社の「大丈夫です」だけで決めると、本番で困ったときに、検収の後の話になります。技術の中身ではなく、数の組み合わせと受け入れの手順を読みます。
このタブで使う例（あけぼの損保の改修・作り物）
テストの種類
テストは段（テストレベル）に分かれ、段ごとに試す物とだれが試すかが違います。同じ名前でも会社によって中身が違うので、名前の意味を確かめます。テストの書き方そのものは、Stack Map のテストのタブとField Map のテストの計画のタブにあります。
テストの段の早見表 考え方のヒント
「現場でよく聞く名前」は、IPA の実践集（結合テスト・総合テスト（ベンダ確認））とデジタル庁の解説書（単体・結合・総合・受入）の呼び方です。会社によって違うので、見積もりや計画の段で意味を確かめます。
バグの数の読み方
バグ（不具合）の数は、テストの進み・未解決の数・重さ・週ごとの推移と一緒に読みます。0 件は「無い」証明ではありません。下の練習で、4 つの推移から出してよいかを決めてください。
練習: バグの推移から、出してよいかを決める（あけぼの損保の改修の総合テスト・数は作り物） 考え方のヒント
あなたの判断
判定の目安の 5 つ（全部試した・未解決 0・見つかる数が減った・重い未解決 0・テスト 1 件あたりで見つかる数が下がった）は、IPA の実践集のテストを終える評価の考え方をもとに、このタブで決めた作り物の線です。
受け入れのテスト
受け入れのテストは、発注する側が主体で、使う人が入って、本番に近いデータで行います。検査の基準を作り、決めた期間の内に合否を書面で出します。検収とその後の責任は、Field Map の「受け入れテストと検収」にもあります。
決めたことを残す形
出すかを決める記録・不具合の推移の表・受け入れテストの計画のひな形です。記録と表には、上の練習のいまの例と判断が入ります。そのままコピーして、文書や表計算に貼って使えます。
出すかを決める記録（Markdown） 考え方のヒント
不具合の推移の表 考え方のヒント
受け入れテストの計画（Markdown） 考え方のヒント
項目は、デジタル庁の解説書の受入テストの計画書の記載事項と、IPA のモデル契約の検査仕様書（第 27 条）・検査期間（第 28 条）から入れました。
落とし穴
品質とテストの結果を読むとき、受け入れるときに、よくはまる所です。
AI 時代の品質とテスト（下書きは速く・確かめと判断は人）
テストケースの下書きや不具合の要約は、AI で速くなります。期待する結果の確かめ、元の一覧との照らし合わせ、個人の情報を入れないこと、出すかの判断は、人が持ちます。
チェックリスト
テストの結果を読むとき・受け入れるとき・出すかを決めるときに、チェックを付けてください（この端末にだけ残ります）。考え方のヒント