テスト設計レビューで伝えた言葉まとめ
-
nihonbuson
- 2948
- 1
- 3
- 0
-
- いいね！0
broccoli
@nihonbuson
QAのお仕事の一つとして、要件定義段階や設計段階（Scrumでいうリファインメント）でのレビュアーがあるけど、そこでの私からの質問って結構細かいと自覚してる。 ただ、そうしているのには理由がある。（続く）
2021-03-26 10:23:56
broccoli
@nihonbuson
ただ、それって 「開発者はそこまで考慮して設計とか考えてる？」 と問い詰めたいというよりも、 「こういう面倒くさいパターンもありえるけどどうする？（心の声：面倒な部分だからスコープ外にするよね？）」 という感じで質問してます。
2021-03-26 10:24:45
broccoli
@nihonbuson
あとは、 「こういう懸念事項もあるけどどうする？（心の声：この懸念事項は今回は対処しないだろうけど、とりあえずみんなで把握しとこうね）」 とかもある。
2021-03-26 10:25:05
broccoli
@nihonbuson
レビューでの指摘って、機能をどんどん複雑化に向かうためのものではなく、スコープ外をハッキリさせて機能をどんどんシンプルにしていくためにもあると思ってます。 複雑な機能って、かける工数の割には、得られるリターンが少ないと思うし、メンテナンスコスト増大の原因に繋がると思うので…。
2021-03-26 10:25:31
broccoli
@nihonbuson
ここに書いたような（心の声）がきちんと伝わっているとは限らないので、最近は、（心の声）もちゃんと表現するように心掛けている。
2021-03-26 10:27:46テスト設計レビューでは気になるところを聞いている話
broccoli
@nihonbuson
最近、テスト設計レビューの時に、 「このチケットのテスト設計をやってて、気になってるところはどこ？」 「ここは複雑そうだなーと思ったところはどこ？」 というような質問を投げかけるようにしてる
2021-09-19 23:40:48
broccoli
@nihonbuson
特に、テスト設計レビューと言いつつも、テスト実装ぐらいの粒度になっている場合には効果的。 そういう書きっぷりの場合、成果物をパッと見ただけではテストの意図が読み取れないけど、質疑応答を通じて「じゃあ、その複雑そうな部分をはっきりさせよう」と言って、モデリングへ向かえたりする
2021-09-19 23:44:34
broccoli
@nihonbuson
実際には本来のテストプロセスから逆行しているんだけど、テスト設計者本人が複雑に感じている部分をハッキリしていく様が見えるので、本人のモチベーションも高く吸収しやすくなる。 結果として、次回以降のテスト設計に役立てる期待ができる。
2021-09-19 23:48:13
broccoli
@nihonbuson
また、「テストの意図は？」と直接聞かれるよりも、答えやすいのかもしれない。 成果物だけでは見えないけど、確実に何かを考えてテスト設計をしているはず。 質問から考えを伝えられるようになると、将来、レビュアーの1人になった時も、今度は自分以外の成果物に対しても意見を言えるかもしれない。
2021-09-19 23:53:07アクティビティ図はまずはシンプルに考えようという話
broccoli
@nihonbuson
最近、観点出しをしている中で、 複数のユーザーのやり取りが頻繁に出てくるな… →ユーザーを軸として表現してみよう →やり取りも多いし、アクティビティ図を使ってみよう という流れになった。
2021-09-22 08:45:35
broccoli
@nihonbuson
それで、アクティビティ図をいざ書き出してみると、色々なパターンを考えちゃう。 それはそれですごく良いことなんだけど、複雑になって見通しが悪くなっちゃうのも良くないので、今回はそれぞれでケースを分けて表記するように心がけてる。
2021-09-22 08:46:03
broccoli
@nihonbuson
例えば、基本形が 業務A→業務B→業務C だったとする。 業務Aと業務Bの間に業務Dが発生する場合を考えている途中で、 「あ、けど、業務Aをやってたら、業務Cの後に業務Eが入ってくることもあるよね」 と気づいてしまうこともある。
2021-09-22 08:46:27
broccoli
@nihonbuson
その時は、 業務A→業務D→業務B→業務C→業務E とはせずに、 業務A→業務D→業務B→業務C 業務A→業務B→業務C→業務E の2つに分ける。 なぜなら、気にしている内容（テストの目的になりうるもの）が違うから。 ケース数自体が非常に多くなってしまうかもしれないけど、一旦この方針で進めてる。
2021-09-22 08:47:06
broccoli
@nihonbuson
見通せないぐらいケース数が多くなってしまったら、改めて整理を考えれば良い。 ただ、最初からケース数を少なくしようと頑張って、1つのケースにくっつけた結果、「これって何を見たかったんだっけ？」となる事態だけは避けたい。 整理の方法はケースを1つに繋げるだけでなく、構造化もあるので。
2021-09-22 08:49:41
broccoli
@nihonbuson
ちなみに、書籍『The BDD Books – Formulation』の中にある考え方も似たようなものである気がする。 色々と考えたい事柄の中から、必須な部分は何かを捉えることについて書かれてる。 leanpub.com/bddbooks-formu…
2021-09-22 08:53:18
broccoli
@nihonbuson
BDDに持っていくまでの1つとして書かれているけど、テスト設計をするにあたっても重要な考え方な気がするなー。 （というか、この作業自身がテスト設計に1つな気もする）
2021-09-22 08:56:35テスト実装を意識し過ぎたテスト設計を作成すると、テストの意図が見えづらくなるという話
broccoli
@nihonbuson
昨日は、 ・テスト設計時にテスト実装まで考慮した表現をしてしまうと、テストの意図が見えづらくなるよ ・複数のテスト設計の結果を元にして最適化したテストデータを作成するのは良いけど、作成したテストデータを、ひとかたまりのテスト設計の因子水準として示すのは止めよう。 という話をした。
2021-09-29 07:35:02
broccoli
@nihonbuson
例えば、 因子A｜因子B 水準L｜水準O 水準L｜水準P 水準M｜水準O 水準M｜水準P となるテスト設計成果物と 因子B｜因子C 水準O｜水準X 水準P｜水準Y 水準O｜水準Z となるテスト設計の成果物があったとする。
2021-09-29 07:35:49
broccoli
@nihonbuson
因子Bと因子Cの表が不完全ですね…。 因子B｜因子C 水準O｜水準X 水準O｜水準Y←今回はやらない 水準O｜水準Z 水準P｜水準X←今回はやらない 水準P｜水準Y 水準P｜水準Z←今回はやらない と、6つ考えたが、2つの因子は組み合わせ関係なくそれぞれ1回は見れば良さそうなので、3つに削ったとします。
2021-09-29 07:43:56
broccoli
@nihonbuson
これらの結果を元に、最適な作成するテストデータを考えると、 因子A｜因子B｜因子C 水準L｜水準O｜水準X 水準L｜水準P｜水準Y 水準M｜水準O｜水準Z 水準M｜水準P｜水準Y となるかもしれない。
2021-09-29 07:36:21
broccoli
@nihonbuson
しかし、テスト設計の成果物を示さないで、作成するテストデータのみを示すと、「水準Pと水準Yは因子Aがどんな場合でも、この組み合わせで使わなければならない」と読み取ってしまうかもしれない。
2021-09-29 07:37:40
broccoli
@nihonbuson
最終的なテストデータのみを示すと、 ・テストの意図が見えづらくなる ・テスト設計の考え直しが発生した場合、その時点での最適なテストデータは最適にはならなくなる ・テスト実施者や、リリース後の見直し時にこのテスト設計をもう一度見ても、なぜこのようなテストデータにしたのか分からなくなる
2021-09-29 07:38:34