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

ここ最近、機能性部分のテスト設計を行っているが、このテスト設計は開発設計書を補完するものだと思う。

(あくまで機能部分です)

そして、実装した機能に対しての意味付け(理由)を可視化・明示するものほかにならないとは思った。

考え方、見え方次第になるが、バグがあったときに、なぜバグではないのかを説明する義務が発生する。

速度が遅いとかいうのもバグの一つだ。

開発担当者に、なぜこの実装となるのかをしつこく聞く。

結局のところ、これを繰り返すための設計を作り、実装の意味づけをしていくことではないかと思っている。

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

最新記事

すべて表示

前提条件 ゆるふわWeb系QAの戯言です。 きっかけ アジャイルでどうテストすればいいかという悩みの本質は、ほとんどテストではなく、それ以前の問題に起因するのでは?という話を聞いて、自分なり考えてみた。 アジャイル開発でテストが難しい理由はQAプロセス設計の難しいことが大きな原因では? たぶん、WFだとあんまり考えないで順序通りに実施してもそこそこ上手くいく。それは、WFの開発プロセスが確立してい

今週もテストアーキテクチャ設計をやっていた。 テストアーキテクチャ設計とはいかのあたりを参考にしてもらえればいいかと。 https://www.jasst.jp/symposium/jasst12tokyo/pdf/A2-3.pdf https://jasst.jp/symposium/jasst13tokyo/pdf/A2-4.pdf 特に機能性の部分ではあるが、製品の心臓部である。 というか、

ソフトウェアのテスト設計の役目って何だろうと思ったこと そもそも設計書が完璧であれば、チェックシートだけでいいと思う今日この頃。 ただ、設計が100% になることは、そうそうないので、それを補完していくのがテスト設計の役目じゃないかなと思い、ここ最近は設計書の暗黙領域を可視化することに注力している。 そして、テストが複雑になるときは設計の説明を受けるが、この説明が長くなったり、難しくなったりする