ソフトウェアのテスト設計に思うこと 3

今週もテストアーキテクチャ設計をやっていた。

テストアーキテクチャ設計とはいかのあたりを参考にしてもらえればいいかと。

https://www.jasst.jp/symposium/jasst12tokyo/pdf/A2-3.pdf

https://jasst.jp/symposium/jasst13tokyo/pdf/A2-4.pdf

特に機能性の部分ではあるが、製品の心臓部である。

というか、機能がなければ、なにも動かない、動かせない(笑

そんな機能を分析・整理をして、どのように動作すればいいのか(ふるまえばいいのか) を考え、予期するリスクを例外として正しくエラー処理させるように機能に盛り込んでいく。

そんななか、(詳細)設計書に記述がないものを、どうしてテスト設計でいれているかと聞かれた。

設計書丸写しな (テスト) 設計はいらんだろ。

開発、テスト限らず設計書が CPM法で丸写しなものであるなら技術者いらん。機械で翻訳すれば出来上がる。

っと説明はした。

その発端は、データの送受信に、(なぜか)データを加工する処理が同時に埋め込まれている、技術的負債コードの代表例だ。

(詳細) 設計書では、これは暗黙知(隠蔽化) されていたため、別の機能としてテストアーキテクチャ設計をしていたのだが、処理順序が違う(処理とテストアーキテクチャの図が違う)と指摘があった。

で、確認すると、データの送受信に、データ加工処理が同時にしているとのこと。

今回はしょうがないので、リファクタリングするため、テストアーキテクチャ設計に赤枠、赤文字で技術的負債とデカデカと書いて負債を見えるかしておきました。

そんなこんなで、負債を発見して次につなげていくのもテスト設計かなと思った今週末でした。