テストする人。

ソフトウェアテストってわかんない。テストとQAのゆるゆるブログ。

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

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

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色使ってないし、なんか戦略妄想してました) マインドマップで仕様などを整理してくれる方がいたり それぞれの割り振りを割とサクッと決まっちゃって、なんかいい感じに時間内にテストケースまで落とし込めました。 (というか、わたし、全然テストケースなくて大丈夫なんだっけ?ってなった。大丈夫なんだっけ?)

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

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

ここからプログラム順じゃなくなります。

招待講演:テスト計画の立て方 中野 直樹 氏

www.slideshare.net

最後の講演は、中野直樹さんによる「テスト計画の立て方」です。

f:id:underscore42rina:20190617104133j:plain
招待講演
はじめに、実行委員からの紹介がありました。
今回の講演のキッカケは、JaSST'17 Kyushuの基調講演とのこと。

これ、わたしがお願いした講演だったので、本当にうれしいです。
そして、今回の招待講演を拝聴できてほんとによかった。TL見るだけだったら苦しくてTwitterアプリアンインストールしていたかもしれない。

まず、テスト計画は「道」であることを説明されていました。
道とは「華道」や「茶道」のような「道」であること。
日々の積み重ねでできるものだし、プロジェクトは同じというものはないので、流用するということはできない。といった話をされていました。

f:id:underscore42rina:20190617104143j:plain
テスト戦略をどうやって考えているか

レシピを例に、まったく同じレシピを見たとしても、できあがりは作る人によって違うというお話しをされていました。
できあがりは作る人のスキルであったり、感覚であったりするとのこと。
これはテスト計画も同じことが言えて、やっぱり当人のスキルや感覚で、できあがりがまったく違ってくるとのことでした。

f:id:underscore42rina:20190617104147j:plain
アプローチを考える、テスト計画で語らないこと、7Rules
テスト計画で語らないコトとして、バックキャスト、すなわち、そのプロジェクトのゴールから考えるとよいというお話しをしていました。
ゴールから考えると、テスト計画でたてたスケジュールや、タスクやアプローチに無理がないかわかるようになるそうです。

また、見積りの基準を自分自身の感覚で持つことも大事だとお話しされていました。

最後に、中野さんご自身の7Rulesについて紹介しました。ちなみに7Rulesはフジテレビ系で放送されているTV番組です。

f:id:underscore42rina:20190617104156j:plain
Q&A
講演の最後に質疑応答がありました。
ここで、「7Rulesの中でも、1番大事だと思うものは何ですか?」という質問に
「6番目の【無理と思ったらなおす】を1番大事にしている」と答えていました。(ごめんなさい、このあとにも説明してくださってましたが忘れちゃった)

他にも「インサイトをわかるコツみたいなのはありますか?」という質問に
「基本的に人を見ている。人をみるときに、そのときの温度であったり、当事者意識がありそうな感じかどうかなどをみている」と答えていました。

このセッションのつぶやき

f:id:underscore42rina:20190627104013p:plain https://twitter.com/rina/status/1140140331809136640:embed

f:id:underscore42rina:20190627104041p:plain https://twitter.com/rina/status/1140150319713619968:embed