バグ修正のテストプロセス

ここ最近、QA、テストのプロセスや手法を聞くことが多いですが、既存の製品や機能などのバグに対してのQA、テストはあまり聞かれません。

開発担当者がバグの修正をして終わりなのでしょうか

最近では、新規開発チームから、既存のバグを修正する（だけではないですが）部署に異動となり品質を考えるようになったので、日陰作業ですが、日々のバグ修正とリリースについて、どのようにされているのか気になります。

最新記事

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

バグ修正のテストプロセスその2

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

残暑の夜にアジャイル開発でテストすることの難しさを想う

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