top of page

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

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


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

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

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


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

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


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


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


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

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


っと説明はした。


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


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



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


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


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



閲覧数:10回0件のコメント

最新記事

すべて表示

ここ最近ぼんやり考えていたことだけど、非機能テストってどうやって理解させていくのかというのことを悩んでます。 とりあえず、個人的に非機能、機能とか分けること自体ナンセンスとか思っている人です、はい。 非機能テストってわりと探索的テストに近いことが多いと感じているのですが、「テスト」だけではなく、さまざまな情報や知識があってこそ探索的テスト (学習してフィードバック)ができると思っています。 非機能

ここ最近、思ってきたのは、以下のマインド (文化) が根底にあるような気がした。 バグ修正 = 品質向上 バグが修正されたら、部分的に品質は向上するだろうがそれは、あくまで外科手術的なものにすぎないと思っている。 摘出手術、移植などで患部は取り除いた (取り換えた) のかもしれないが、それは品質向上なのか?ということ。 バグの要因分析はしているものの、なんとなくそれをやっただけで (過去の文化が悪

ここ最近、QA、テストのプロセスや手法を聞くことが多いですが、既存の製品や機能などのバグに対してのQA、テストはあまり聞かれません。 開発担当者がバグの修正をして終わりなのでしょうか 最近では、新規開発チームから、既存のバグを修正する(だけではないですが)部署に異動となり品質を考えるようになったので、日陰作業ですが、日々のバグ修正とリリースについて、どのようにされているのか気になります。

bottom of page