の7日目です。
昨日は tononoちゃんのエントリーでした。
あ、いっか、
— リナ？ (@____rina____) 2019年11月6日
探索的テスターがuserstoryを作ろうとするとどうなるか
みたいのにしよかな
なぜ、こう思ったのか忘れてしまったんですが、
自らお題を決めてしまったので、このタイトルで記事を書きます。
探索的テスターについて
わたしは、テストやQA、品質とかに関わるお仕事を専門として11年くらいになります。
その中でも、開発に入り込んで、「いかに短く」「いかにお客さまに価値のあるものを」「エンジニアにフィードバックするか」
を重要視してテスト実施をしていたため、いわゆる「探索的テスター」になっていました。
(逆に、事前に「テスト設計をする」とか「下積みテスターとして網羅的にテストを行う」とか「エビデンスを残すことを重視する」
といったことをほぼやってこなかったために、できないこともたくさんあります)
UserStoryとは
みてのとおり、ユーザーの物語です。
構成としては、次のようなフォーマットで作成したりします
- WHO/WHAT/WHYで構成される
- Acceptance Criteriaがある
さっそく作ってみます。
UserStory1：川へいく
おばあさんは汚れ物をもって川にいきます。なぜならば、洗濯をしたいからです。
UserStory2：桃を拾う
おばあさんは川から流れてきた桃を拾います。なぜならば、とても大きな桃は珍しいですし、手に入ることがなくて興味が湧いたからです。
UserStory3：桃を切る
おばあさんは桃を切ります。 なぜならば、 持って帰っておじいさんと食べたかったからです。
UserStory4：きびだんごを作る
おばあさんはきびだんごを作ります。なぜならば、桃太郎の旅支度に持たせたいからです。
はい。桃太郎です。
では、これらにAcceptance Criteriaを入れてみます。
UserStory1
おばあさんは汚れ物をもって川にいきます。なぜならば、洗濯をしたいからです。
Acceptance Criteria
川の水は洗濯可能な純度であること
川の水は洗濯可能なスピードであること
天候が洗濯可能であること
自宅から川までの距離が適切であること
UserStory2
おばあさんは川から流れてきた桃を拾います。なぜならば、とても大きな桃は珍しいですし、手に入ることがなくて興味が湧いたからです。
Acceptance Criteria
川の水は桃を流せる程度の水量・スピードであること
桃の大きさが適切であること
UserStory3
おばあさんは桃を切ります。 なぜならば、 持って帰っておじいさんと食べたかったからです。
Acceptance Criteria
桃は包丁で切れる程度の硬度であること
UserStory4：きびだんごを作る
おばあさんはきびだんごを作ります。なぜならば、桃太郎の旅支度に持たせたいからです。
Acceptance Criteria
きびだんごの材料は適量であること
きびだんごの日持ちが一定期間であること
きびだんごは一定以上の味であること
思いのままに書いたので違うかもしれないです。(きびだんごとかめちゃくちゃ怪しい)
途中で、これはDoneの定義にすべきかもしれないって思うのもありましたが
きっと来年のワタシが答えを持ってきてくれます。
探索的テスターがAcceptanceCriteriaに思いを馳せる
WHYにも思いを馳せるんですけど、おばあさんって重いのもつのが好きなんでしょうか？
というか、桃を持ったときに洗濯物はどうしたんでしょうね。
わたしスタイルの探索的テスターは、妄想をよくします。妄想でテストをします。
どんぶらこの水量やスピードってどんな感じなんでしょうか。
不思議に思ったところはAcceptanceCriteriaないしは、その先のDoneの定義になるかもしれません。
妄想がはかどります。
これを優先度づけしてみます
この3つのUserStoryの優先度をつけてみます。
これを重要だったり、まず価値を届けたいという順にしました。
UserStory3：桃を切る UserStory4：きびだんごを作る UserStory2：桃を拾う UserStory1：川へいく
桃太郎でてきませんけど、桃を切るの大事かなって思いました。
次にきびだんごは一つの大事なプレゼンスなので、次に入れました。
そして、桃を拾うところと川へ行くところです。補足っぽいイメージなので、最後にしてみました。
こうして順番を入れ替えていくと、話しがわからなくなってきました。
ここで、そうだ。これを使おうって思ったのが
UserStoryMappingです。
UserStoryMapping
UserStoryMappingはUserStoryを配置してみるものです(雑な説明)
さきほどのUserStoryですが、実は2つのシーン(もしかしたら3つのシーン)がありました。
シーン1：おばあさんが桃を発見して桃太郎がでてくる シーン2：桃太郎が鬼退治するのを送り出すためにおばあさんが旅支度をする
それぞれのシーンでUserStoryを配置します。
シーン1：おばあさんが桃を発見して桃太郎がでてくる UserStory1：川へいく UserStory2：桃を拾う UserStory3：桃を切る
シーン2：桃太郎が鬼退治するのを送り出すためにおばあさんが旅支度をする UserStory4：きびだんごを作る
ほんとうはもっとUserStoryがあると思うんですけど、こんな感じになるはず。
そして、これで あらすじはわかるようになって、それぞれのUserStoryはバラバラになっても大丈夫になります。
あってよかったUserStoryMapping
(この理解がどれくらいあっているか、危険かもしれないことかわかっていない)
探索的テスターがuserstoryを作ろうとするとどうなるか
探索的テスターがUserstoryを作ろうとすると、
ほんとにWHYがWHYなのか考えはじめる
AcceptanceCriteriaっを本気で考えはじめる
おそらくUserStoryがたくさんできそう。
たくさんできてしまったUserStoryはUserStoryMappingしちゃうと、迷子にならなくていいよ。
・・・これは探索的かどうか関係あったのかな🤔
そもそも探索的テストって
基本的に動かしながらテストを設計して実行してって考えてやっていくスタイルなんですよね。
でもそれを、動かないもの(=お話)に対して、あれこれ考えるって
ふつうの設計(テストですらないのではないかと)なのかなって思いました。
ただ、自分を探索的テスターだと名乗った場合に
別に動いていようと、動いてなかろうと、思考がかわるわけではないんですよね。
動いてくれるほうがヒントがどんどんでてくるので、より確実であったり思考の向き先がそれに引きづられたり
絞り込まれたり、横道にそれたりするだけで
その子たちが出てこないだけで、「あぁかもしれない」「こうかもしれない」は普通にでてくると思うのです。
その普通にでてくるは、テスト設計をしている方にとってはとても普通のことだと思うので
結局一緒じゃん。って思ったのでした。
という、いまさらながらの気付き。
こんなわたしと
Agileなテストの読書会をしませんか？
九州ソフトウェアテスト勉強会のABD Vol.1「アジャイルテスト担当者シラバス その1」というみんなで読む会を開催します。
参加者が4人くらいだったら、パンケーキ食べに行くと思います。
さて明日のアドベントカレンダーは？
まつりちゃんのJaSST九州のお話しのようです。とっても楽しみですね！
