テストする人。

ソフトウェアテストってわかんない。ソフトウェアテスタ-による、ゆるゆるブログ。

探索的テスターがUserstoryを作る話と、UserStoryMappingていいね。って話。

qiita.com

の7日目です。

昨日は tononoちゃんのエントリーでした。

なぜ、こう思ったのか忘れてしまったんですが、
自らお題を決めてしまったので、このタイトルで記事を書きます。

探索的テスターについて

わたしは、テストやQA、品質とかに関わるお仕事を専門として11年くらいになります。
その中でも、開発に入り込んで、「いかに短く」「いかにお客さまに価値のあるものを」「エンジニアにフィードバックするか」
を重要視してテスト実施をしていたため、いわゆる「探索的テスター」になっていました。
(逆に、事前に「テスト設計をする」とか「下積みテスターとして網羅的にテストを行う」とか「エビデンスを残すことを重視する」
といったことをほぼやってこなかったために、できないこともたくさんあります)

UserStoryとは

みてのとおり、ユーザーの物語です。

構成としては、次のようなフォーマットで作成したりします

  • WHO/WHAT/WHYで構成される
  • Acceptance Criteriaがある

さっそく作ってみます。

UserStory1:川へいく
 おばあさんは汚れ物をもって川にいきます。なぜならば、洗濯をしたいからです。  

UserStory2:桃を拾う
  おばあさんは川から流れてきた桃を拾います。なぜならば、とても大きな桃は珍しいですし、手に入ることがなくて興味が湧いたからです。  
 
 UserStory3:桃を切る
    おばあさんは桃を切ります。 なぜならば、 持って帰っておじいさんと食べたかったからです。  
    
  UserStory4:きびだんごを作る
    おばあさんはきびだんごを作ります。なぜならば、桃太郎の旅支度に持たせたいからです。  

はい。桃太郎です。

f:id:underscore42rina:20191204210900p:plain

では、これらに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:桃を切る  

f:id:underscore42rina:20191202161736p:plain

シーン2:桃太郎が鬼退治するのを送り出すためにおばあさんが旅支度をする  
 UserStory4:きびだんごを作る  

f:id:underscore42rina:20191202161758p:plain

ほんとうはもっとUserStoryがあると思うんですけど、こんな感じになるはず。
そして、これで あらすじはわかるようになって、それぞれのUserStoryはバラバラになっても大丈夫になります。

あってよかったUserStoryMapping
(この理解がどれくらいあっているか、危険かもしれないことかわかっていない)

探索的テスターがuserstoryを作ろうとするとどうなるか

探索的テスターがUserstoryを作ろうとすると、
 ほんとにWHYがWHYなのか考えはじめる
 AcceptanceCriteriaっを本気で考えはじめる
おそらくUserStoryがたくさんできそう。
たくさんできてしまったUserStoryはUserStoryMappingしちゃうと、迷子にならなくていいよ。

・・・これは探索的かどうか関係あったのかな🤔

そもそも探索的テストって

基本的に動かしながらテストを設計して実行してって考えてやっていくスタイルなんですよね。
でもそれを、動かないもの(=お話)に対して、あれこれ考えるって
ふつうの設計(テストですらないのではないかと)なのかなって思いました。

ただ、自分を探索的テスターだと名乗った場合に
別に動いていようと、動いてなかろうと、思考がかわるわけではないんですよね。
動いてくれるほうがヒントがどんどんでてくるので、より確実であったり思考の向き先がそれに引きづられたり
絞り込まれたり、横道にそれたりするだけで
その子たちが出てこないだけで、「あぁかもしれない」「こうかもしれない」は普通にでてくると思うのです。

その普通にでてくるは、テスト設計をしている方にとってはとても普通のことだと思うので
結局一緒じゃん。って思ったのでした。

という、いまさらながらの気付き。

こんなわたしと

Agileなテストの読書会をしませんか?

九州ソフトウェアテスト勉強会のABD Vol.1「アジャイルテスト担当者シラバス その1」というみんなで読む会を開催します。

参加者が4人くらいだったら、パンケーキ食べに行くと思います。

さて明日のアドベントカレンダーは?

まつりちゃんのJaSST九州のお話しのようです。とっても楽しみですね!