top of page

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

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

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

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

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

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

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

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

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

最新記事

すべて表示

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

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

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

bottom of page