top of page
  • usk o4ra

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

前提条件

ゆるふわWeb系QAの戯言です。


きっかけ

アジャイルでどうテストすればいいかという悩みの本質は、ほとんどテストではなく、それ以前の問題に起因するのでは?という話を聞いて、自分なり考えてみた。



アジャイル開発でテストが難しい理由はQAプロセス設計の難しいことが大きな原因では?

たぶん、WFだとあんまり考えないで順序通りに実施してもそこそこ上手くいく。それは、WFの開発プロセスが確立しているので、その対比でやればいいためだと思う。 ただ、アジャイル開発の場合、開発プロセスがかっちりしていないことがあるので、QAのプロセスを考えるのがけっこう難しい。QAプロセスが迷子になりやすい。


私の場合はどうしている?

メンヘラ駆動テストのプラクティス「Giraffe earrings standing upside down(あなたが一番ほしいものをあげる)」を駆使してプロセスを設計している。そのため、割といつ何をやればいいかが設計しやすいのではと思っている。

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

最新記事

すべて表示

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

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

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

bottom of page