回答編集履歴
3
２ケース追記
test
CHANGED
|
@@ -4,9 +4,13 @@
|
|
|
4
4
|
|
|
5
5
|
|
|
6
6
|
|
|
7
|
+
実際に何を意図しているかは聞かないと判明しないと思いますが、ありそうな推測を挙げてみます。
|
|
8
|
+
|
|
9
|
+
|
|
10
|
+
|
|
7
11
|
**推測1**
|
|
8
12
|
|
|
9
|
-
契約上の責任回避のための作業である
|
|
13
|
+
契約上の責任回避のための作業であるケース
|
|
10
14
|
|
|
11
15
|
|
|
12
16
|
|
|
@@ -26,7 +30,9 @@
|
|
|
26
30
|
|
|
27
31
|
**推測2**
|
|
28
32
|
|
|
29
|
-
今後の修正でのデグレーションを防ぐための作業
|
|
33
|
+
今後の修正でのデグレーションを防ぐための作業であるケース
|
|
34
|
+
|
|
35
|
+
|
|
30
36
|
|
|
31
37
|
今書かれているテスト設計書をベースに、ユニットテスト（自動テスト）を起こすつもりである。と希望的な観測をした場合は以下の様な意味で一定の意義はあるのかなと思います。
|
|
32
38
|
|
|
@@ -45,3 +51,51 @@
|
|
|
45
51
|
単語の定義の問題であるケース。
|
|
46
52
|
|
|
47
53
|
慣習的に「単体テストの設計書」と呼称されているものが実は「現在の仕様の確認/調査書」であるだけのケース。。。
|
|
54
|
+
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
---
|
|
58
|
+
|
|
59
|
+
追記2
|
|
60
|
+
|
|
61
|
+
**推測１-２**
|
|
62
|
+
|
|
63
|
+
|
|
64
|
+
|
|
65
|
+
推測１に近いですが、「とにかく納品物としてテスト仕様書が必要である（もしくは、になった）」ケース。
|
|
66
|
+
|
|
67
|
+
「発注側の組織内ルールとしてコードカバレッジ100%のテスト仕様書が必要」でかつ、「形式的には内部監査に耐えられる内容であること」が求められているが、予算/納期的に真面目に作るのは無理なので、今回の様なケースになることはありがちです。
|
|
68
|
+
|
|
69
|
+
受注時には約束してなかったテスト仕様書を当然の様に求められて、断り切れなかったとか、慣習的にそういった流れになってるとか。
|
|
70
|
+
|
|
71
|
+
|
|
72
|
+
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
|
|
77
|
+
**推測2+3**
|
|
78
|
+
|
|
79
|
+
網羅的な仕様確認の起点となるドキュメント作成であるケース。
|
|
80
|
+
|
|
81
|
+
実は、現在出来上がってるのものが、一種のプロトタイプ的なバージョンで、これをもとに最終仕様の検討などがされる場合にはあり得るケース。
|
|
82
|
+
|
|
83
|
+
|
|
84
|
+
|
|
85
|
+
まずは現在の仕様を把握し、わかっている範囲のテスト仕様書を書く（=現時点での単体詳細仕様書[主に正常系]が出来上がる）。
|
|
86
|
+
|
|
87
|
+
これをベースにして、全体の仕様書も作成する。
|
|
88
|
+
|
|
89
|
+
全体の仕様書が出来上がったら、単体仕様書をもう一度精査して、抜けているケースが無いかを確認していく。
|
|
90
|
+
|
|
91
|
+
|
|
92
|
+
|
|
93
|
+
---
|
|
94
|
+
|
|
95
|
+
|
|
96
|
+
|
|
97
|
+
**色々推測を書きましたが、結局は指示した人に聞かないとわからないと思いますので
|
|
98
|
+
|
|
99
|
+
（角が立たない様に）意図を尋ねられればベストだとは思います。
|
|
100
|
+
|
|
101
|
+
例えば、「出来るだけ見やすい/使いやすいものを作りたいので、この資料って誰がどうやって使うものなのか教えていただけませんか？」という感じとかでしょうか。**
|
2
追記
test
CHANGED
|
@@ -33,3 +33,15 @@
|
|
|
33
33
|
|
|
34
34
|
|
|
35
35
|
仕様としては結合テストのテストで担保し（こちらは仕様書ベースでテストを書くのかも）、単体テストは「テストを書いた時点から単体ベースでは変更がないことを担保する」ことに注力することで、今後単体レベルでの仕様変更はきちんと管理されるようになる。。。
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
追記
|
|
42
|
+
|
|
43
|
+
**推測3**
|
|
44
|
+
|
|
45
|
+
単語の定義の問題であるケース。
|
|
46
|
+
|
|
47
|
+
慣習的に「単体テストの設計書」と呼称されているものが実は「現在の仕様の確認/調査書」であるだけのケース。。。
|
1
修正
test
CHANGED
|
@@ -18,7 +18,7 @@
|
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
|
-
問題があったら、「仕様
|
|
21
|
+
問題があったら、「仕様の解釈としての実装はテストケースの通りです。検収頂きましたよね？」と言い張ります。（法的に有効かどうかは別の話ですが。）
|
|
22
22
|
|
|
23
23
|
---
|
|
24
24
|
|