top of page

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

ここ最近、思ってきたのは、以下のマインド (文化) が根底にあるような気がした。

バグ修正 = 品質向上


バグが修正されたら、部分的に品質は向上するだろうがそれは、あくまで外科手術的なものにすぎないと思っている。


摘出手術、移植などで患部は取り除いた (取り換えた) のかもしれないが、それは品質向上なのか?ということ。


バグの要因分析はしているものの、なんとなくそれをやっただけで (過去の文化が悪かったとか) 終わってしまったりとかでモヤモヤ感が一層増大する。


弱点 (体が弱いとかとか) があれば定期的な検診や検査、メンテナンスをするよね?

おれも膝をけがしているから、定期的な検査、メンテナンスするけどw


バグやデグレが多いし、影響がよくわからんとか言うのであればリグレッションテストとか何か定期的な検査をするんじゃないかな?


そういう発想が芽生えないのは、やはり上記のバグ修正=品質向上で止まっていると思われる。


もちろん、100% 完全なテストなんて無理なので効果が高いところからするのは当然だけどね。


そういうマインド(文化)を変えていきたいとは切に思った。



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

最新記事

すべて表示

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

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

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

bottom of page