テストする人。

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

いいんちょを引退することにした

いいんちょエントリーもこれで5回くらいになるらしい。
と思ったら6回目でした。そうk・・・6年も(共同いれて)委員長てやってきたのか

underscore42rina.hatenablog.com

underscore42rina.hatenablog.com

underscore42rina.hatenablog.com

underscore42rina.hatenablog.com

underscore42rina.hatenablog.com

今年のJaSST九州

言わずもがなだけど、今年も大盛会でおわりました。
関係各社のみなさま、ほんとに今年もありがとうございました。

本会については、みなさまがよきブログエントリーを書いてくださっているので、ご覧ください。
わたしは懇親会でチームについていろいろ相談したり
ことばについて質問したりしました。

今年の委員会

今年は共同実行委員長をはじめ、プログラム委員長(って名目もしや出てないのでは・・・今回の一番の立役者です)や
若い委員が主軸となって動いていました。
わたしはほんとに何もやってない年になりました。委員会に参加したくらいの記憶しかありません。
あとお菓子の買い出しと経費精算の監督。

もういいかげん引退したほうがよいと思う

準備の途中から 結構決めていたのですけど、今度こそ委員を引退しようと思っていました。
ほんとは去年くらいから委員長は次にうつるべきだと思っていたので、ほんとはそこで引退したほうがよかったかもしれないです。

わたしの発言の声が大きくなった

委員会ミーティングのときに、私の発言がキッカケで、何度か場の雰囲気が悪くなりました(もしかしたら周りは気にしてないかもだけど、自分はそう感じました)
声の大きい人は、いることで良いことはあんまりないです。助言が命令に感じるなら(しかも自分自身で)その行動を正すか止めた方がいいです。
やめる=発言しない なら、いない方がいいです。

あたらしい雰囲気は大事にした方がいいと思う

今のチームは、開発エンジニアがチームにいたり、委員それぞれが個別に社外活動にコミットしている人たちが増えて
今までとまた雰囲気が(もちろんいい意味で)変わってきているかなって思っています。
それを近くで支えるとかってできるでもいいんでしょうけど、
普通に自走できる人たちなので、新しいチームでさらに爆走していくのを楽しみにしています。

・・・といっても、やっぱりJaSST九州を長年やってきたので、さみしいなぁ。

JaSST九州とわたし

最初にJaSSTに参加したのがJaSST'12 Kyushuで
13年から実行委員をやって(それもなんかぶっ飛ばして働いて)
それからはずっと共同実行委員長と実行委員長をやっていて
色んな方にお世話になって助けられてすごしてきたんだなぁってあらためておもいます。

ていうか、来年から普通に参加できるのか!最高かよ!

引退したらどうするの?

ひとまず、委員長はせずに、委員としても外れる予定です。アドバイザーはリクエストがあればしたいです。
(この辺はわたしがちゃんと残作業をクリアにできるかにもよるかもしれない)

ってことで、他は以下。

JaSST全体のお手伝いをしたい

今年からJaSST全体の担当理事になりました。
現在も少しずつではありますが、JaSST全体でのお手伝いとかをしています。

JaSSTというシンポジウムには、全国に数百人の実行委員がいます。
また15年以上の歴史もあります。
これらをすべてボランティアという形で運営しています。

そのため、まだまだできることがあったり、見えていない困っていることがあったり
せっかくの組織が活かしきれていないこともあったりするかもしれません。

今後はそういうことについて、カイゼンとかお手伝いとかできるといいなぁと思っています。

初心にかえる

最近は全然勉強会とかできてないし、登壇もできてないし、普通に勉強できてないなぁと思います。
もっかい最初からちっちゃく何かはじめられたらいいなぁってお気持ちです。
(それもあってABDはじめました。たのしい❤️

underscore42rina.hatenablog.com

シラバスをABDでやるとおもしろかったよ。って話

すっごく久しぶりに自分で自分がやりたいゆるい勉強会をやりました。

q-te.connpass.com

ABDについては↓を参考にしてください(当日もしました) kuranuki.sonicgarden.jp

なんでABD?

一度ABDの勉強会(しかもオンライン)に参加してみて、
積本常習犯のわたしには すごくあっているなーと思っていました。

それで、自分が読めていない本とかをABDでやってみるとよさそうだなって思って
今回やってみました。

なんでシラバス

ABDをするには、参加者が本を所持する必要があります。
その点、JSTQBシラバスはPDFが無料公開されているので、インターネットに接続すればだれでも無料で手に入ります。

仕事でAgileに関わることが増えたので、今回アジャイルシラバスをテーマにしました。

当日どうだった?

当日は3人しか集まらず、開催してよいか不安でしたが、結果3人でも十分勉強になりました。
ABDは私が一度したことがある程度でしたが、それなりにできたかなって思います。

ABDのよい点は色々ありますが、用意はほとんど必要ないです。
ファシリテーターが用意するもの ]

- 紙(今回はA4用紙にしました。6枚×参加人数分)  
- ペン(太目)人数分  
- 紙をとめるテープ(マグネットでもよかったな)  
- ふせん  
- 練習用の概要を印刷した紙  

ABDのファシリテート用の資料を作りかけたんですが、前述のサイトにABDのやり方サンプルが丁寧に書いてあったので
そちらのサイトを見せながら説明しました。

なので、事前準備はほぼなしでした!

ここがよかった:ABD

  • 読む、要点をまとめる、発表する、ディスカッションできる とアウトプットの機会が短時間にたくさんできた

 1時間半の間に、全員でこれらをするのですが、時間全然足りないし、集中しないといけない時間があってとっても疲れますが
 単に一人で読むより、発表することにより、一人で読むより短時間で理解が深まったと全員が体感できました。
 人が説明することによって、知っていた話や、知らなかった話を共有することができ、その後質問やディスカッションをすることで
 シラバスに書いていないような話も知ることができてよかった。

  • 3人と少人数だったけど、その分全員が共有も話も平等にできた

 人数が少なかった分、全部はまったくできなかったが、3人が同じだけ話したり、全員で共有することができたのがよかった。
 ファシリテーターも慣れていない(ABDファシリは初めてするし)けど、割とスムーズにできたと思う。人数が多かったらもっとわたわたしたかも。

ここがよかった:シラバス

  • アジャイル活動でのテスト担当者のありかたがわかった

 あれ?こんなところまでテスト担当者は入り込んでいいんだ。という気付きがあったのが大きい。
 また、テスト計画の内容なども記載されていて、明日から試してみたいなと思える内容も書いてありました。

  • アジャイルの説明も多く、あらためて勉強することができた

 アジャイルの説明は聞き覚えがあるものも多いのですが、今だからわかることとか
 今課題だと思っていたことのヒントが書いてあったのでよかったです。ちょっともうちょっとちゃんと読んでみよう

次回のABD会は?

来年早々にできたらいいなと思います。
今回1章がおわったので、人数と参加者層によりますが、できれば2章を中心にやりたいです。

探索的テスターが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#)