(*'▽') わからん!!
そもそも論。
期待値を厳密に明記しろとまでは言わないが(結構めんどいので)、正しさが何なのかをきちんと定義しろよって言う話。
そもそもだよ。
〇〇が正しい事を確認する。
って、これもう「何も言ってないのと同じ」ですよね。
いやだって、普通に考えてみろ。
〇〇が正しくない事を確認する。
なんて話ある訳ないじゃん。
つまり正しくなくていいって事じゃんそれ。
有り得ないじゃん、普通に考えて有り得ないじゃん。
正しい事を確認するって、それは試験仕様書の全ての項目に共通する目的であって、わざわざ言わんでもええわ、っていう話ですよ。
それはただの「大前提」です。
正しい事を確認するのは遍く総ての試験項目にとって共通の目的であり、ただの大前提ですよ。
そんな解り切った事しか書いてないってのは、つまり何も書いてないのと一緒。
int i = 0; // i に 0 を代入する。 i++; // i をインクリメントする。
とかいう頭のおかしな一行コメント書いてるのと同じですよ。
そうじゃなくて。
試験仕様書ってのは「何がどうなってりゃその機能にとっての『正しい』になるのか」をきちんと定義する文書であって、その機能が『正しい』事を証明する方法を示したものじゃないですか。
だからこその試験「仕様」書であって、試験「手順」書ではない訳じゃん。
テスト仕様書よりも、テストコードを増やそう。
そもそも、画面操作とスクリーンショットエビデンスと言う、前時代的なテスト手法ばかりなのがダメ。
紙文化大好き日本人らしくて本当にダメ。
テスト仕様書を用いたブラックボックス的なテストも良いけど、テストコードによるホワイトボックステストをもっと増やすべき。
ブラックボックスとホワイトボックスの適用選択が何より大事だと思うし、それを前提としたクラス設計が大事だし、その為にはコーディングテクニックも学ぶ必要があるんだけど、なんかそう言うのがなかなか実践されないよね、日本の開発現場ってね。
人海戦術大好きだよね。
もっとテストコードを書くべき。
テストコードを書けば、それがそのまま仕様書にもなるし、試験にもなるし、サンプルコードにもなる。
少なくとも、業務実装は良いとして共通部品だとかフレームワークまわりの所だけでも、テストコード主体で実装していくべきだと思う。
余談だけど、テストコードの無いコードはすべてレガシーコードである
と断言している人もいたよ。(出典が何だったか忘れちゃった、Qiitaに書いてたんだったかな?)
なかなかそこまで言い切れる程にはなれないけど、かなり衝撃を受けた覚えがあります。
試験仕様書書くリソースをテストコード実装するのに回そうよ。
そもそも開発環境支援もなにもないExcel方眼紙上で膨大なドキュメント作ってレビューして、、、って、非常にコストのかかる作業じゃないですか。
その労力をテストコード実装に回せば普通にしっかりしたテストコード書けるし、テストコードさえ書いちゃえばテスト実施は機械的に行える上に繰り返しも可能になるじゃんね。
実装からテストまで、ずーっとコード書いていられるから楽しいし、素晴らしい事だらけじゃないか。
もちろん、そうは言っても全部が全部それでやろうとするとかえって大変になるから、部分的・選択的にテスト手法を選択して適用していくべきだと思う。
そこは、プロジェクトに於いてテスト計画を立てる人がシッカリ仕事しなきゃならん、と言うか、そもそもテスト計画を立てるって発想がもしかして無いのか。
まともなアーキテクト不在のプロジェクトだと、そうなっちゃうんだろうねぇ。