テストする人。

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

探索的テスターが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九州のお話しのようです。とっても楽しみですね!

メニューをレビューしてフィードバックしよう #テストティーパーティ―

今日はこちらに参加していました

connpass.com

これはこれで、JSTQBの話をしたり、美味しく楽しくお話ししていたんですけど、
ちょっと酒が足りねぇと結局2次会で飲みにいき
そこで後半すごく盛りあがったので、そのお話しを。

最初に載せたメニューの画像をみて、レビューして。フィードバックして。というお題です。
ちょっと考えてみてください。

何かこうするともっといいよね。とか、ここよく考えているよね。って出てきましたか?

ここから、二人で色んな話をしたなかで興味深かったものをいくつかご紹介します。

ビールのメーカーは書くべきなのか

ビールといえば、どこのメーカーのビールか気になります。
このお店のビールのメーカーをわざわざ聞かなければわからない、そして聞いてから好きなメーカーではないとがっかりする。
という話がでました。

お店に複数種類置いてある場合はもちろん書いて欲しいですが、
お店に一種類しかない場合、わざわざ書かなくてよい情報ではないか と話しました。

このメニューはA4用紙で、そこに載せられる情報は限られています。

このお店にきたお客さまは、生かどうか、瓶がえらべるならどちらかを選ぶと思いますが
ビールが飲みたいけど、キリンだったらやめる ということは、あんまりないかなと思ったからです。
(でも、生がアサヒで、瓶がキリンだったら、メーカーで選択しなおすかも・・・)

ですので、メニューに載せる優先度の高い項目ではないと判断してんではないかと思いました。
もしかしたら、日によってメーカーが変わるのかもしれないですね。

ノンアルコールビールのありか

ノンアルコールビールの配置を見てみます。
縦書きのメニューの場合、目線は右上→右下→左上→左下 の順に動きます。

一番最初に頼まれることが多いビールが右上なのはすごく納得するのですが、ノンアルコールビールはこの位置でよいのでしょうか?

このお店は、繁華街ではなく、ベッドタウンの駅前にある居酒屋でした。
この町では、駅の駐車場に車を置いて、電車で通勤人も多いです。

そのため、帰りに一杯といっても飲めないお客さまが繁華街に比べて多いので、この配置にしているんじゃないかな?
と話しました。
これは、この場で考えないと、オフィスで考えてもでてこない発想だなーと思い、面白かったです。

みんな、ビール大好きなんですね。
(さらに、ツイートで教えてもらったのですが、シャンディガフの配置もビール関連で寄せてるのかしら?という話も興味深いです)

チューハイの話

このメニューはカテゴリーに金額が書いてあるものと、もう一つ詳細なメニューに金額が書いてあります。
チューハイの場合、すべて同じ値段なので、カテゴリーであろう「チューハイ」に金額が書いてあるのだと思っていました。

ですが、チューハイという(XXチューハイ)ではない飲み物があると教えてもらいました。
知らなかった。
この場合、ただのチューハイはメニューとして存在するのか、「チューハイ」はメニューなのかカテゴリー名かわからない。
という話をしました。

たしかにー

もしチューハイってメニューがあった場合は、どういう表示がわかりやすいのだろう。。。

日本酒の話

このメニューには日本酒がでてきません。
このお店には「飲み比べセット」という日本酒メニューがあり、
別にある日本酒メニューから3品選ぶことができました。

私はこの日本酒飲み比べセットを頼んだわけですが、
普通に好きな日本酒だけ飲みたい人が、たどり着く経路が用意されていません。 なので、メニューに日本酒も記載したた方がよいのではないかと話しました。

・このメニュー
・日本酒飲み比べセット と書かれた特別メニュー(メニューってか飲み比べという文字と金額が書かれているだけのメニュー)
・日本酒のメニュー(10種類くらいカード式に案内が書いてある。ここに一合の金額も書かれている)←このメニューにたどり着けない

ではどうするべきか。

そもそも、お店として飲み比べメニューを推したいのかな?と思いましたが、 わたしであったら、 このメニューにも「日本酒があること」と「メニューは店員まで」という2行を追加したいなって思いました。

その場所についても、あーだこーだ言って、配置だけなら、ハイボールとチューハイの幅を調整して、
その後ろになんとか2行つけたい・・・て感じにしました(ベストな配置かわからない)
ほんとに日本酒のメニューを載せるべきかもわからない

カクテルを組み合わせ条件表記にしない理由(もちろん二人の妄想)

日本酒の配置の話から出てきた話。そもそもカクテルが冗長すぎではないか。という話がありました。
このお店は うどん居酒屋(ウエストではない)で、カクテルという甘い飲み物は頼まれにくいのではないか?という懸念事項もありました。

たしかに、これであれば
シャンディガフ
・ファジーネーブル
・カシス
・ピーチ
(オレンジ・ソーダ・ウーロン)

のようにまとめることもできます。

そこで、普段このお店に来ているお客さま層の話を思い出しました。
このお店では、仕事帰りに立ち寄ったサラリーマンや、近所で働いているガテン系が多いそうです。

・・・もしや、これを頼むのは、そういう人たち(男性としたら)その恋人などではないのか?と想像しました。
その場合、彼女ってメニューを組み合わせで頼むのは、話す言葉が増えてしまいます。
冗長でも、全メニュー書くことで「指さし」でメニューが注文できるのでは?という妄 想をしました。

そうか。組み合わせにしないことでうまれるよさもあるのだなと(妄想なのに)わかって面白かったです。

システムだとどうするか、お客さまが欲しいものは何か

上のような話は、実際のテストやレビュー時に必ずしもでないと思います。
むしろ、システムを作るのであれば、↓のような指摘をしてしまうかもしれません。
・このメニューのグルーピング(カテゴリー分け)は粒度がそろっていないのではないか
・全項目のメニューに金額をつけるべきではないか(公平性)
・文字が重なっていると金額の可読性が下がっているのではないか
・金額の文字の濃さや太さを 濃く、細くした方が可読性があがるのではないか
・文字そろえが可読性を下げていないか

ですが、お客さまとして見たときに、ビールか焼酎かというカテゴリーがわかれていれば
それ以上冗長なメニューの表示は必要ないですし、
金額も書いていないところは、同じ値段なんだな。と読み取れるのであれば、A4で納めるためにはすごくいい表示だと思いました。

結果、このメニューはいいメニューだと思う

以上の説明があり、このメニューはお客さまの行動をよく考えて作られたメニューなんだろうなと思いました。

最後に、では、これをさらに改善して お店の売り上げに貢献できる(=お客さまもリピーターになってもらう)ことを
このメニューで実現させるにはどうしたらいいだろう?って話を最後にしながら帰りました。

このメニュー談義は、以前友人ともしたのですが、すごく面白いです。(手書きがとくによいです)
わたしは、これに似た思考でテストやレビューをすうことが多いので
今回も学びもあり、とても楽しかったです。(そして、これは実際に指摘できる自信がないなって思いました)

今まではQAな人としかやってないのですが、これがビジネスインパクトを得意としたプロデューサーや、デザイナーだったときは
どんな話になるのかなと思うと、もっと楽しそうですね。

ソフトウェアテスト教科書 JSTQB Foundation は買いなおした方がいいの?

www.shoeisha.co.jp

って何人かに聞かれたので、こっちに書いてみようと。

現在、翔泳社を初め、全国の書店やAmazon電子書籍も取り扱いがあります。

雑におススメしたさのグルーピング

①教科書を持っていないし、FLの試験もうけるよ

試験はシラバスでも学習できますが、何か本欲しいというなら
こちらの本を購入されることをおススメします。

②第3版までの教科書を持っているけど、FLの試験もうけるよ

次の試験からは、新シラバスと呼ばれる2018が試験範囲となります。
教科書の第3版は旧シラバスに沿った教科書なので、内容に差があります。
また、用語も変わっています。
できれば新しい教科書を使うほうがよいですが、もし第3版で学習されるのでしたら
シラバスと比較しながら学習された方がよいと思います。

③教科書を持っていないし、試験は受けないよ(またはFLは合格したよ)

シラバスになってFLを受けなおす方は少ないかなと思いますが
参考書としても十分使用できますし、今から取得される方とのコミュニケーションの手段として
使われてもいいかなと思います。

④第3版までの教科書を持っているし、試験は受けないよ(またはFLは合格したよ)

③と同様です。今後の学習のために持っていてもよいかなと思います。

で、何がかわったの?

シラバスが変わった分、教科書も変わっています。 シラバスも教科書も、前回から8年経過して、時代の変化にあわせてかわってきているところがあります。

シラバスの変更点については、
教科書の著者であり、JSTQBの技術委員でもある湯本さんの記事がとても参考になります。*1

note.mu

今回の教科書は、これらの変更を反映したってことですね。

もうひとつ、気を付けたいところ

教科書に関係あるわけではありませんが、このシラバスに準ずる用語はJSTQBにおいては、Advanced levelでは通用しないことがあります。
例えば、新シラバス(Foundation level シラバスVersion 2018.J03)で「同値パーティション」という用語は
Advanced levelでは「同値クラス」にあたります。

ですので、これからFoudation level, Advanced levelを取得しよう、学習しようという方は
それぞれのレベルの用語の読み替えが必要になりますし、場合によっては前のFouncation levelの内容を理解する必要があるかもしれません。
(Advanced levelはFoundation levelを理解している前提ですので)

用語の違いは、ISTQB Glossaryのサイトで各シラバスごとの用語を調べることもPDFにダウンロードもできるのでご安心ください。

glossary.istqb.org

結局買いなおしたほうがいいの?

はい。わたしは購入をおススメします。
わたしは、いまだにシラバスを読んだりすることが多いので、それに準じた教科書があるのはとても心強いです。
理解力があがると期待しています。
資格取得後も見直すことが多いものなので、持っていて(そして持っている分使って)よい本だと思いますよ。

*1:実はわたしも著者であり、JSTQBの技術委員なんですよね。おこがましいことに。。

日本で一番働きたい会社に入って1年がたとうとしている

underscore42rina.hatenablog.com

ようやく なのか まだ なのか 今の会社に入って一年が経とうとしています。

ざっくりクォーター単位でのふりかえり。

2018.10~2018.12

濁流に放流されたかのごとくオンボーデイング。
これがWebサービス業界なのか。。。という情報量と人の流れ。

とにかく、仕事というか、使ったことのないツールやプロセスを使いこなすのに必死でした。
メンターがいてくれたおかげで何とかなりました。いや、なってないときも何とかしてもらってました。

オンボーディングの2週間は東京にいたのだけど、
この間にメンターランチで色んな人とつなげてもらったし
(ここであった「Microserviceはスイミーなんだよ」って名言を残してくれたエンジニアのことはいまだに師匠と呼んでいる。しかし、わたしを弟子だとは思われていない←)
オンボーディング中にたまたま隣の席になった同期入社の同僚は、リモートだけど、いまでも一番仲良し。

わたしは開発拠点の立ち上げメンバーのひとりだったので、
このクォーターは立ち上がれ!がとにもかくにも目標でした。 大変だったなぁ。

そして、このクォーターで今のチームメンバーとやったプロジェクトが
のちに社内表彰されて、とってもうれしかった。し、フォローしてもらったにしろ
よくあれ2か月くらいで出せたなぁと思います。

underscore42rina.hatenablog.com

2019.01~03

underscore42rina.hatenablog.com

会社の社外イベントに登壇&運営しました。 またイベントできたらいいなぁ。 QAとしてでも、開発チームとしてでもいいなって思ってます。

このクォーターの思い出は、東京のエンジニア陣と本格的にお仕事をしたことです。 とくにグローバルメンバーとのコミュニケーションにめっちゃビビッてましたけど 周りの助けもあり、なんとか遂行できたのはよかったなぁと。

このクォーターだったか、次のクォーターだったかで 「リモートでやっている感覚がなかった」のように評価してくださった方がいたのはうれしかったです。

このクォーターの最後の日だったかな に メンターかつこのクォーターのボスとQAグループ(チーム?組織?)が分かれることを知り 夜号泣した。なぜ号泣したかは自分でもわかんないですけど、ボスの元で働きたかったんでしょうね。 はじめて見るものを親と思うタイプなんだと思います、わたし。(迷惑ですね)

今もメンターボスは元気そうです。

2019.04~06

ここからQA兼スクラムマスターを名乗るようになります。
このクォーターではスクラムを教えてもらうエンジニアリングマネージャーに
超お世話になりました。
毎週あきらめずに教えてもらった・・・やさしい・・・

とにかくスクラムというものに慣れなくてどうすりゃいいんや・・・って思った3か月でした。
今もどうすりゃ・・・って思ってるけど、ちょっと開き直ってきたぞ。
来年くらいに、お外にお話しを持っていけるところまで成長できるといいなぁと思っています。

また、このクォーターでは、QAの横断的な活動のファシリテート(というより係がまわってきた)で
めちゃくちゃ疲れました。なぜみんなシュッとできるんや・・・わし・・・わからんぞ・・・ってなってました。
なりすぎて、みんなが参考に作っていたドキュメントでさらにドキュメント作り直しまして
それをさらにきれいにしてもらいまして
なんかとてもいい感じになりました(説明がふわっとしている)

なるほど、プロセスを整理するってこういうことなんだな。
ってちょっと思いました。

ここでドキュメントをきれいにしてもらった同僚には、今も別のパートナーとして過ごしているので
勝手にパートナーのように思っています(こうしてみると、勝手に懐いている性質あるな、わたし)

あと、ちょっとだけサブチームのファシリみたいなこともしていました。
ほんとにちょっとだけだったけど、話しを聞くと悩みってあるのね。と思いました。

2019.07~09

と、わたしたちにとってのスクラムマスター像が見えた感がしたのがとっても大きかったです。

ここで、QA兼スクラムマスター兼プロデューサーの子分 というあたらしい(勝手な)職種を追加します。
がっつり設計にも入り込んで、要件定義やドキュメント修正もするようになりました。

最近はモブプログラミング(わたしは隣で画面フィードバックをする係)や1DaySprintができるんじゃって
挑戦している感じです。とても楽しい。

おかげで、もはや何の人なのかわからないという感じになっています。
といっても、別に今までの会社にいたときとマインドは変わっていないし、何ならようやく
前々職のマインドを活かして仕事できてる感じがあるので、自分にとっては”テストする人。”から変わってないのです。

また、プロジェクトでは、絵にテストしたいことの全体像とか詳細なことを書いてみるようになりました。
(今までも自分のノートには書いてたけど)
自分の理解度はめっちゃあがるので、もうちょっとちゃんと書けるといいのかなと思うのと
結局UMLが書けるようになればいいような気もするけど、絵の方が馴染みやすいんですが、言い訳ですかね。。
かわいいUMLがかけるようになりたい。

QAの活動は、主に横断的な活動の思い出が強いです。
一つ、前述した同僚とパートナーでファシリをやっています。
といっても、個人活動に重きをおいていたので、これでみんなの期待度はどうだったのかは
これからわかる(のかわからないのか)予定です。
継続するなら、もうちょっと力入れるほうがいいのか悩みどころ・・・

でも、相談できるパートナーがいるっていいなぁと思いました。

そして、もうひとつ。わたしの入社の理由の大きな要因でもあった最初のボスが退職しました。 退職ブログでちょっと泣きそうになったし、一緒に世界一のQAチームを作ることを夢みていたので残念だけど、まぁわたしもどーにかやるさ。

一年たった

クォーターごとにふりかえりの時期があるので↑みたいに大体思い出ができます。
そう思うといい制度だなぁ。
そして、色々あったなぁと。なんらか成長してそうです。わたし。

今も日本で一番働きたい会社なのか

入社時に「日本で一番働きたい!」と数年思い続けての入社でした。
今は自信をもって”一番です!”と言い切れないかなぁという感じ。
それなりに大変なこともありますし。
とはいっても他に働きたい会社も思いつきません。

でも、今のチームで働くことがとても好きですし
まずは社内で一番イケてるチームになりたいし  あわよくば、日本で一番イケてるチームのひとつになれるといいなぁ。

”はじめてのソフトウェアテスト”を5年やってみた

ついに5年もやってました。びっくり。 fusic.connpass.com

www.slideshare.net

去年からは外部講師というかOGというか、前前職を卒業してからも続けられるイベントってよいですね。

一昨年もブログを書きました。 underscore42rina.hatenablog.com

アンケート結果

今年のアンケート集計結果。その前の年のものを探したけど、見つからなかった・・・きっと毎年とっていると思うのだけど。

f:id:underscore42rina:20190730003805p:plain
満足度

多くの方に満足いただいてよかったです。
参加者はエンジニアが多かったのですが、中には教員や学生もいらっしゃいました。

f:id:underscore42rina:20190730003827p:plain
理解度

多くの方に理解いただけたようです。中にはJSTQB取得者もいらっしゃいましたが、再確認できたと言っていただけてよかったです。

f:id:underscore42rina:20190730003901p:plain
どこで勉強会を知りましたか?
今回一番の失敗。告知募集Conpassなのに、DoorKeeperのままアンケートを作ってしまったこと。

Conpassと書いてくださった方がいたので、その他の中はけっこうConpassで知ったって方が多そうです。

わたしの強み

f:id:underscore42rina:20190726201218j:plain
ワーク1

f:id:underscore42rina:20190726215538j:plain

毎回ワークのあとに、全員に発表してもらうようにしているのですが、その時にホワイトボードに書いていってるのですよ。
そのとき、大体何かコメントなりつっこみなりボケなり言うようにしていて
これって多分そんなにみんながみんなできないかもなーと思いました。

でも参加者のみなさん、毎回新しい回答がでてくるので、ほんとすごいです。

そして、わたしも毎回反省と前より理解できたところと、うまく説明できたところとかあって
学びがあったりします。
今回一番理解が深まっている!

うれしかったこと

f:id:underscore42rina:20190730005809p:plain

誰かがひとりでもテストが好きになったり、楽しくなったりする人がいらっしゃったら それだけで大成功だと思う!

f:id:underscore42rina:20190730005832p:plain

はるばる県外からきてくださった上に、Twitterまではじめてくださった
まじヤバイ!うれしい!(スクショとっちゃってごめんなさい。やめてーってあれば今すぐ削除します!)
このスピード感まじで最高

ということで

f:id:underscore42rina:20190730005438p:plain (https://twitter.com/rina/status/1155725803847471105:embed#)

アウトプットの考えかた

「どうやってアウトプットしてよいかわからない」

「アウトプットすると、間違ったことを書けないし、フィードバックがこわい」

これらは、この最近で聞いた悩み。

結論を書くと、書けばええやん。そんなにみんな見てないし、
でも、意外と役に立つ

って、思っている。

といっても、わたしとか、1日に100ちょっとのビューしかないし、
全然テクニカルでも、役に立つかもわかんないような内容だし、
文章もこんななので、
そもそも目指しているレベルが違うのかもしれない。

ひとまず、わたしの考えを書いてみる。

そもそも

そもそも、わたしは知識もスキルもなくて、アウトプットとか今でもクオリティの観点でとても苦手で、
昔居た会社では、万年アウトプット評価は最下位グループだった。(ほしかったな、上位の人たちがもらっていた封筒)

いまでもクオリティは課題だと思う。
でも、このブログとかも、基本的に考えにブレもズレもないので、
自分なりに持っている考えは書いているのだと思う。

なぜ書くのか

言いたいことがあるからなんだと思う。 おしゃべりが大好きなんですよね。
おしゃべりクソ野郎ではない人も世の中にはたくさんいるのだけど、
冒頭に聞いた悩みを持っている人たちは、少なからず言いたいことがあるなぁと感じた。
ただ、うまく言葉をまとめられない、とか、どういう媒体を使えばいいかわからない。
ということかなと受け取った。

うまくまとめるなら、論文を書くとか、クリティカルシンキングを学ぶというのもあるだろうし、

そもそも、うまくまとめる必要すらない場合もある。Twitterもブログの一部もそうだと思う。
慣れという訓練でもよくなるとおもう。

筋トレと一緒なんだろうな。
一緒かな?

フィードバックはこわくない

まず、うまくまとめなくてもよいもの(Twitterとかブログの一部)は、そもそもフィードバックはほとんどこない。
独り言と思っちゃえばいいとおもう。
といっても、誰かを傷つけないものであることは心がけたい。

でも、本当に目に止まることすらないのだろうなとビューを眺めていると感じる。こわくないよ。

次に、ある程度フォーマルなもの。
所属名をつけて公開するものや、誰かのためのもの、技術などの見解を書いたものなど。これは、何らかのフィードバックを受けるかもしれない。

でも、いままで怖い指摘は受けた記憶はないと思う。
おそらく、サイレントクレームが多いのではないかなと思っている。
こいつ中身ないなと思われたとしても、わざわざ書かれるほどでもないんだろうなぁと。
ほってんとりに乗るような人だときっと大変なのだろう。

とはいえ、未然に防ぐために、先にレビューが必要かもしれない。

所属名を出すようなものや、発表資料や、心配なことがあるときはレビューを出すようにしたり、所属機関のプロセスがあったりする。

レビューアーによっては、本当に傷つくし、げんなりすることもあるけど、だいたいは、未熟なレビューアーだからだったんだなーと思う。

ほとんどの場合、レビューしていただいて、勉強になったし、自分が本当に言いたいことが何だったのか考えなおす機会になっている。
なにより、レビュー文に感動して、それが今のQAの活動の役に立っている。

アウトプットの適切な場所は?

本当にこわいなら、最初は誰も見ないプライベート環境でよいと思う。
それで、こっそり誰かにみてもらうとよい。

そのうち、できるだけ外に見せられるものは、外に置くとよいとおもう。

機密事項があるものは社内の共有場所に。
加工すれば外の一定のメンバー(例えば権限付きのFacebookや、Slackチームなど)にだせそうならそういう場所に。
私は、社名や団体名や個人名を出したいときなどにそうしている。
それすら必要なければ、こういうブログに出している。

できるだけオープンにしておくと、のちのち自分が楽になる。
そんなに秘密にしないといけない情報はないことがわかる。

で、結局どうなのか

アウトプットは、
自分が持っている情報の整理、共有ができる。
その情報が、次のアクションのキッカケになる。
人からのフィードバックで、成長の機会が得られる。

かなと思います。

■追記

WACATE 2019 Summerに行ってきたよ その⑥

前の記事はこちら underscore42rina.hatenablog.com underscore42rina.hatenablog.com underscore42rina.hatenablog.com underscore42rina.hatenablog.com underscore42rina.hatenablog.com

テストの組み立て方 中村 仰志 氏

www.slideshare.net

f:id:underscore42rina:20190617095328j:plain
テストの組み立て方

いよいよ、今回のワークショップの本丸のための事前セッションです。 この辺から、お絵かきに疲れがみえている・・・

ここでは、ワークをする前に知っておきたい知識であったり、 ここで、身につけて、ワークに取り掛かってほしい。という趣旨のセッションだったと思います。

[ワーク]テスト計画・テスト設計 朱峰 錦司

f:id:underscore42rina:20190702100809p:plain

きんちゃんやばい

f:id:underscore42rina:20190702100915p:plain きんちゃん天才か

テスト界隈でも有数の(若手)プレゼンターの 朱峰さんのセッションはすごかった。 久しぶりにみたけど、もう動画撮りたかったよね。天才か。

ここが肝心のワークなのですが、お外に出せるものがない・・・たぶん。

今回は朱峰さんがまじで作ったシステム(このためにワーキンググループ10グループの、インスタンスまで立ててた)を使って テスト計画〜テスト実行まで、やりきりました。すごい。こわい。

ただ、テスト設計(テスト計画〜テストケース作成)は4時間(×6人)、テスト実行は30分(×6人)という制約つき。こわい。

仕様書もシステム仕様書、画面仕様書、API設計書が用意されていました。 この日はどのようなテスト計画にして、テストケースまで落とし込んでみよう。ってことでした。

わたしたちのチームでは、3色ボールペンを使って、仕様書の懸念点を洗い出したり(ごめんなさい私3色使ってないし、なんか戦略妄想してました) マインドマップで仕様などを整理してくれる方がいたり それぞれの割り振りを割とサクッと決まっちゃって、なんかいい感じに時間内にテストケースまで落とし込めました。 (というか、わたし、全然テストケースなくて大丈夫なんだっけ?ってなった。大丈夫なんだっけ?)