ここ最近ぼんやり考えていたことだけど、非機能テストってどうやって理解させていくのかというのことを悩んでます。
とりあえず、個人的に非機能、機能とか分けること自体ナンセンスとか思っている人です、はい。
非機能テストってわりと探索的テストに近いことが多いと感じているのですが、「テスト」だけではなく、さまざまな情報や知識があってこそ探索的テスト (学習してフィードバック)ができると思っています。
非機能の速度計測テストで○○のリクエストを××以内に処理するとかあったとします。
計測しました、成功 (失敗) でした
。。。。で、終わられると困るんですよね。
単に作業やろ (チェッキング) ということですｗ
それを、あなたはどういうことを学びつつフィードバックしてテストをしていますかという何かしらの可視化をしてフィードバックを得やすくできないものかと、そういうフレームワークっぽいものを用意すれば学習しやすくなりそうなきがするかなぁ
っと、ぼんやりと考えていました。
ここ最近、思ってきたのは、以下のマインド (文化) が根底にあるような気がした。 バグ修正 ＝ 品質向上 バグが修正されたら、部分的に品質は向上するだろうがそれは、あくまで外科手術的なものにすぎないと思っている。 摘出手術、移植などで患部は取り除いた (取り換えた) のかもしれないが、それは品質向上なのか？ということ。 バグの要因分析はしているものの、なんとなくそれをやっただけで (過去の文化が悪
ここ最近、QA、テストのプロセスや手法を聞くことが多いですが、既存の製品や機能などのバグに対してのQA、テストはあまり聞かれません。 開発担当者がバグの修正をして終わりなのでしょうか 最近では、新規開発チームから、既存のバグを修正する（だけではないですが）部署に異動となり品質を考えるようになったので、日陰作業ですが、日々のバグ修正とリリースについて、どのようにされているのか気になります。
前提条件 ゆるふわWeb系QAの戯言です。 きっかけ アジャイルでどうテストすればいいかという悩みの本質は、ほとんどテストではなく、それ以前の問題に起因するのでは？という話を聞いて、自分なり考えてみた。 アジャイル開発でテストが難しい理由はQAプロセス設計の難しいことが大きな原因では？ たぶん、WFだとあんまり考えないで順序通りに実施してもそこそこ上手くいく。それは、WFの開発プロセスが確立してい