テストする人。

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

Fusicを卒業します

[https://twitter.com/rina/status/988560508407177218?s=21:embed]

これ、送別会の出来事で、本当にびっくりしました。 送別会で勤続のプレゼントをしてくれる会社とかないと思う!!!

はじめに

Fusicを退職することになりました。 約10年お世話になりました。

テストをお仕事にしたキッカケ

 Fusicに入社したのは、偶然のできごとでした。
前職だったシステム開発会社は結婚を機に退職し、事務の仕事をしようと職業訓練校に通っていました。
そのカリキュラムにインターン制度があって、そのインターン先がFusicでした。

インターン中に事務のお手伝いも特になく、前職の開発経験があるということでテストをすることに。 インターン終了後、そのまま雇っていただくことになりました。

当時はテスターという職種はFusicにはなく、10年経った今でも、
あまりこの会社の規模でQA部門もなく、テストだけしているという人は少ないように思います。
本当に偶然でした。

子どもとわたし

 わたしには子どもがいますが、先日9歳のお誕生日を迎えました。
Fusicに入社後すぐに子どもに恵まれました。

入社後すぐということで不安に思っていましたが、
会社は快く産休・育休を取得させてくれました。

妊娠当時は2度ほどぎっくり腰で1週間休むようなこともありましたが、
それにも臨機応変に対応してくださいました。

会社での働き方とわたし

ただでさえ、子どものことがあったのですが
さらに家庭の事情でほぼ1~2年単位で生活環境が変わってしまい、
その都度、役員と話し合い、わたしが働きやすい環境を受け入れてくださいました。

本当に毎年のようにわたしのわがままをとおしていただいて感謝しきりです。
本当にありがとうございます。

社外活動とわたし

Fusicでは、多くのエンジニアが勉強会に参加したり運営したり登壇したりしています。

それが普通の環境にいたので、私自身かなり自然に勉強会という文化に慣れ親しんでいます。
(それでも当時はテストの勉強会がなくて大変でした)

Fusicでは、遠方のシンポジウムやワークショップに旅費交通費、参加費用すべて出していただきました。(ASTERレポートとか社外活動についてはそちらから行っていますが、それも出勤扱いで行ってるものが多いです)
正社員でも契約社員でも区別なく投資してもらえる環境も、他ではなかなか聞くことがありません。
今の自分ができたのも、ここの環境のおかげです。

さらに、退職後も勉強会で会議室を使っていいよ。とまで言っていただいています。
太っ腹すぎ!

なぜ卒業するのか

 これだけ書いていて、本当になぜ卒業するのか
今までしてもらったこと、一緒にやってきたことなどを考えると
今から環境をかえることは、わたしも本当に不安です。

ですが、Fusicの20の信条でもあり、わたし自身もずっとモットーとしている
「やらぬ後悔より、やって後悔」 を実施することにしました。

フルリモートワークのテスターになります。

これからのわたし

今後もテストのお仕事をすることが決まっています。
今も本当に自由にさせていただいていましたが、
さらに自由になるべく踏み出してみようとしています。

勤務地ですが、県外からのフルリモートワークになるため、自宅にいることになります。

自宅は、福岡市内から1時間以上かかるので、
人にお会いできる機会が減ってしまいますが
月に1度程度は勉強会とか市内に行きたいなぁと思っています。

また、北九州市内へも同じくらいの時間で行けるようになりますので(なんなら飯塚も)
今まで行けなかった方面の勉強会も参加しやすくなるかもしれません。

テストの勉強会したいとかの話もあるとうれしいです。
ぜひお声がけください。

また、リモートでできることもどんどん増やしたいので
そういう活動も増やしたいなと思います。

お礼

最初から最後まで10年という長い間わがままばかり言ってきました。
本当にお世話になりました。
本当にありがとうございました。

これでFusicとの関係が終わるということはなく、違う形でこれからもお世話になるつもりですので どうぞよろしくお願いします。

Issue勉強会をしてきたよ

いつもお世話になっている秋山さんたちと 勉強会をしてきました。

“Issueの書き方と伝え方”勉強会 - connpass

テーマはIssue

Issueってなぁに?

JSTQBでいうとインシデントレポートにあたります。
他にもチケットとかバグ票とか呼ばれると思います。

私のお仕事では、Github Issueを使っていることと、
バグだけでなく、テスト中にあがった質問や改善要望も登録するためIssueと呼んでいます。

どんなことをしたの?

勉強会は、4人の発表者の話と質疑応答をしました。

上のリンクに掲載されています

私はこれ

www.slideshare.net

ゆるい会というコンセプトでしたが、なかなか真面目だったかも?緊張したし、発表後腹筋筋肉痛になりました。

プリンmgmgタイムも美味しかったしまじめ?でした。
楽しかったです。

なかでも、いくつか気になるトピックがありました。

余計なことを書かない

事実だけを書き、それ以上のことを書かないというような話がありました。

私は余計なこと?をまぁまぁ書きます。 双方が納得するための説明がないと、しあわせになれないので。

なので、 ・問題に思うこと ・その理由 ・どうしたらよいか ・対応することによる懸念点 まで書くこともあります。

担当エンジニアの顔が見えるので、彼らの得意・不得意なところも吸収しつつ、技術で解決できないかなーとか思っています よくあるのは、UIや日本語などです。

しあわせになるIssue

割と辛い思いをされている方が多いのだなぁという印象が強かったです。

「仕様です で返される 」とか

とはいえ、私自身似たような経験をしたこともあったのですが、 今はほぼないんですよね。。なんでだろう。

一番大きいのが、各issueに対して納得できる回答が返ってくるからなのかなぁと思います。 仕様だったとして、きちんとクライアントさまに懸念点も含めて合意が取れていることがわかれば、そんなにギスギスすることもないから辛くないのですよね。

うとのエンジニアはお客さまの顔が見える仕事をしているわけですが、私はエンジニアの顔が見える仕事をしています。

誰でもわかるIssueを書くことも大事なのですが、せっかく顔が見えるのであれば、相手に合わせたIssueを書くことでしあわせになってたんだなぁと思いました。

[Github Issue]Assignされた一覧に詳細画面からワンクリックで遷移したい

Github Issueの詳細画面でAssignをクリックすると
Assignされたユーザーのページに画面遷移されます。

f:id:underscore42rina:20180327135126p:plain

以前は、同じプロジェクトでかつ、クリックしたAssignで絞り込まれたIssue一覧が表示されている仕様でした。

私はテストのIssue報告にGithub Issueを使っているので、1アクションだったのが2アクションになるのは死活問題です。

こんなかんじ

■以前

1. Issue詳細で確認する
2. Assigneeをクリックして次の自分が確認するIssueを表示する

■今

1. Issue詳細で確認する
2. IssuesタブからIssues一覧を表示する
3. Assigneeで自分を絞り込みする

と困っていたら、
我らが@take-cheezeが解決してくれた!神かよ!

導入方法

  1. TampremonkeyChromeに追加します
  2. https://gist.github.com/take-cheeze/98b8b65329f7dd237ca28ac8c348597c からRawボタンをクリックします

f:id:underscore42rina:20180327135250p:plain これで、Issueの詳細画面からAssignをクリックしても、次のIssueが探しやすくなりました💛

ありがとうありがとう 🌸

困ったから解決まで

30分!

f:id:underscore42rina:20180327213213p:plain (https://twitter.com/rina/status/978256470247538688)

神かよ!

twitter.com

JaSST'18 Tokyoに行ってきた!

JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo

このブログを何度かご覧のみなさまならご存じかと思いますが、 日本最大のソフトウェアテストのシンポジウム JaSST'18 Tokyoに行ってきました。

なぜ行ったのか

やはり日本最大のシンポジウムだけあって、各プログラムがとてもおもしろそう。
海外の講演者をお招きしているので、世界のテスト事情を聴講できるチャンスです。

さらに今回は、私が所属しているJaSST Kyushuのプログラムやテーマのヒントを探るというのも ミッションにありました。

何があったのか

ここでは、私が聴講したもののいくつかをピックアップして、感想を書きます。

きっと各セッション内容は 色んなブログのエントリーがあると思うので 探してみてくださいね:)

基調講演とチュートリアル

基調講演:Advances in Continuous Integration Testing at Google. John Micco(Google

まとめての感想になりますが、こちらではJohn Micco氏による基調講演とチュートリアルを受けました。

私は普段、受託開発と自社サービスのテストを選任でやっています。 探索的テストが得意なテスターなのですが、ものの見事に打ち崩された感じです。

Googleではすべてテストを自動化しています。
そのため、手動でテスト実行しているテスターもいなければ、 Issueを書く必要もないかもしれません
(いや、でもバグの結果をエンジニアにフィードバックしているて言ってたので フィードバック書く文章力や表現力は必要なのかも。

ではMicco氏は何をしているかというと、それらの自動テストの結果をデータとして持っていて おかしな動きをしていないか見ているそうです。

自動テストというと、OK/NGやGreen/Red、Pass/Failなどを思いだされると思うのですが、
それだけでなくFlakyな状態をみています。

フレーキーとはテスト実行をすると、PassしたりFailしたりするようなものを指すそうです。

チュートリアルでは、Micco氏がチュートリアルのために用意したデータと前もって作成してくれたSQLファイルを使って
データの集め方を教えていただきました。

基調講演で聴いた内容だけでは、Googleだから。という感じもどことなくしていたのですが
チュートリアルを受けてみると、今あるプログラムコードや、テスト実行結果をとっていれば
それをもとに、意外と似たようなことができちゃうかもしれないな。と思いました。

ちなみにMiccoさんと二日目の夜に一緒にお酒を飲む機会があったのですが 英語が超苦手な私とも話してくださいました(周りに沢山ヘルプだしたけど)
全然講演の話しなかった私のバカバカ。

Web.JaSST~ウェブ系QAがみんなのお悩みに全力で提案を返す会~

JaSST Tokyoでは数年前からWeb.JaSSTというプログラムがあります。
私もWebのシステムのテストをしているので(ここではWeb ServiceのQAという意味だったので、たまに私のスコープと外れる) 毎回参加しています。

今回は事前に参加者からいただいたお悩みを、チームで回答するというものでした。

こちらにTweetのまとめもあります

togetter.com

今回の内容に関しては、Webだから~ という内容は少なかったのではないかなーと思います:)
いつも思っていることなのですが、WebやWebサービスにだけ特化した情報はもちろんないわけではないのですが
それよりも、どの世界(組み込みやエンプラ、受託システム)でも、似たような話はたくさんあります。

きっと選り好みせず、色んな話を聞いて、自分の世界に落とし込める、変換できると
より多くの知見が得られるなぁと思います。

今回のパネルメンバーはWeb.QAという勉強会もやっているそうなので
いつも指くわえてみています。 うらやましい。

計画立案とふりかえりでリスクを捉えよう!~SaPIDTOC:未来予想型チーム運営WS(テスト編)~安達 賢二(株式会社HBA)水野 昇幸(TOC/TOCfE北海道)

このタッグのワークショップやBootCampが最近注目しているわけですが、
JaSSTでチュートリアルが受けられる!ということで受けました。

とはいっても、SaPIDの触りであったり、TOCの触りであったりは、他の勉強会で振れたことはありました。

今回は150分という時間。
まま長そうに見えるかもしれませんが、私にとってはまだまだ時間が足りませんでした。

SaPIDは問題解決手法の1つですが、問題に向き合うことが難しいです。
適当に何処かで聞いたことのある問題を言うと『それで具体的にどんな嫌なことがありましたか?』と掘り下げられます
日本語がまだまだ不自由。

当たり前ではありますが、チュートリアルを一回受けただけで習得できるようなものは そんなに多くないと思うので、今回の経験を機に、日々ちょっとずつやってみるといいよね。って思っています。

二人の話し方とかもすごい好きだったりします。

また、今回3人チームになって挑んだのですが、ふだんメトリクスとか進捗スケジュールを見ることがなくて
すごい勉強になったり楽しかったりしました。
自分の読みがあってる みたいなこともできるんだなーってちょっと好きになりました。(本来の目的と違うだろうけど)

JaSST Tokyoのココがすごい

セッションの内容の片鱗がおわかりいただけたかなーと思いますが、
他にもいろいろすごいことや楽しいことがたくさんありました。

どこもかしこも有名人だらけ

この日は日本中のテスト好きが集まってきます。

そうすると、右をみても左をみても有名人がいたりいなかったりします。

本会終了後に、関係者入口付近に居たのですが、出てくる人々が
「〇〇で有名な~さん」とか「〇〇で基調講演された~さん」みたいな状況になって面白かったですw

福岡からもたくさんの参加者がきたぞ!

私が初めてJaSST東京に参加したときは、おそらく一人で参加したんじゃないかなーと思います
(九州で括ると、理事の方々がいらっしゃったりしますが)

しかし、年々参加者が増え、今年は実行委員から5人(東京兼任のぞく)や、他の参加でも総勢10名程度参加しました(私が知る範囲で)

一人でも本会ではたくさんの友人たちに会えるので、寂しい思いはしませんが
仲間とくると、これからに活かすためにどうしようか。とこれからの話がしやすくなるなぁと思いました。

たくさんの人に出会える

有名人(の定義も書いていませんが)でも、そうでなくても、たくさんの人を紹介したり挨拶したりできました。
いち参加者でこんなに名刺交換をする機会はここでしかないかもしれません。

今となっては、テストの話だけでなく、生活や社外活動、自分に関する色んなことを相談したり
近況報告できる人たちと集まれる貴重な機会です。(一日目も二日目も飲みに行った)

講演者とまじで話せるぞ

偶然ということもありますが、基調講演のMiccoさんとも、招待講演の柴田さんとも話すことができました。 普通にその辺(失礼)を歩いていますし、情報交換会では独占も可能では・・・というくらいお話しできます。
日本人遠慮しすぎ。というのがよくわかりました。
みんなもっと話したらいいと思うし、講演者の方々も話すの好きな方多いと思っています。

自分の活動の棚卸しができるかも

シンポジウムに行くと、未来のことも、自分の現場に近いことも、さまざまなことを知ることができます。
自分の今の行動や活動があっているのか、必要ないものになるかもしれない
もっと工夫できそうだな とか ただ楽しいだけでなく、今日からどうしようかな。と思う機会に恵まれます。

私の場合、最近はテスト自動化だ、AIだと言われてきていますが、それでも人じゃないと手が届かないことを していると思いあがっていましたが、そんなことすら必要なくなるかも
私なんていなくてよくない?て思いました(少なくともGoogleでは必要ないだろう)

ときどき「自分のようなテストのやり方やテスターは必要なくなるし、必要ないようにすることが自分のミッションかもしれない」 と思っていた時期がありましたが、またもややってまいりました。

色々やっていきたいなぁ

さいごに

登壇者や実行委員をはじめ、各みなさまのおかげで、とても貴重な時間を過ごすことができました。
これらを指くわえてタイムライン眺めるだけにならなくてよかったです。

また、ほぼ参加だけの回も久しぶり(コミュニティブースとか出したりしてたので・・・今回もちょっとだけお手伝いしましたが) だったので、思う存分楽しめました。

実行委員長挨拶で「これからもJaSSTに期待して欲しい。ぼくらはその期待を超えるようにがんばります。だから期待してください」 というような話がありました。
私も地域運営として、同じ気持ちでやらなきゃなぁ

あー、いってよかった:)

チームでポモドーロテクニックDAYをやってみたよ

ということで、所属チーム(プロダクトチームではなく、組織上のチーム)で
「丸一日、ポモドーロをやってみよう!」
をやってみちゃいました。

ポモドーロとは

詳しくは↓とかを参考にしてください。 https://next.rikunabi.com/journal/entry/20161026_M1

ざっくり言うと

  • 「25分の作業+5分の休憩」を4セットし、長めの休憩をいれます。
  • 25分の間におこなうタスクを決めます(25分で終わるものにする必要はありませんが、ある程度細かい方がいいかもしれません)
  • 受験勉強の集中テクニックにも用いられています
  • 集中力を鍛えることで、ゾーン状態やフロー状態に入りやすくなるとも言われています

なぜやったのか

わたしたちのチームは2月に結成されました。
先日チームがどうなりたいか、などを話していて、その中に
"生産性向上" というキーワードがあって、ポモドーロテクニックでそれが達成できるのではないか?ということで
まずはやってみようよ!とリーダーがさくっと決めてくれました。

フットワーク軽っ

時間割

今回チームで試してみる(でもそもそもポモドーロやったことない)ので、
時間割を作成しました。

10:00~10:25 1回目 集中時間
10:25~10:30 1回目 休憩
10:30~10:55 2回目 集中時間
10:55~11:00 2回目 休憩
11:00~11:25 3回目 集中時間
11:25~11:30 3回目 休憩
11:30~11:55 4回目 集中時間
11:55~12:00 4回目 休憩
12:00~13:00 休憩
13:00~13:25 5回目 集中時間
13:25~13:30 5回目 休憩
13:30~13:55 6回目 集中時間
13:55~14:00 6回目 休憩
14:00~14:25 7回目 集中時間
14:25~14:30 7回目 休憩
14:30~14:55 8回目 集中時間
14:55~15:00 8回目 休憩
15:00~15:30 休憩
15:30~15:55 9回目 集中時間
15:55~16:00 9回目 休憩
16:00~16:25 10回目 集中時間
16:25~16:30 10回目 休憩
16:30~16:55 11回目 集中時間
16:55~17:00 11回目 休憩
17:00~17:25 12回目 集中時間
17:25~17:30 12回目 休憩

見るからにつらそう(´Д⊂グスン

ポイント

  • 準備や後片付けも考慮し、10時~17:30までで組み立てました。(基本的な業務時間は09:00~18:00)
  • 12回の集中時間があります。
  • 12時と15時に1時間と30分の長い休憩をとることができるように組み立てました。 (15時は休憩以外にも、メールチェックや他の人とのやりとりなど、今回のタスク以外のことがまとめてできる時間と想定しました)

デメリット

  • 社内外のSNSやメール、電話をシャットオフするため、返答が遅れる
  • 電話があった場合は、基本「折り返し」てもらうなど、周りのサポートが必須
  • 誰かチームメンバーに聞きたいときに連絡がとれない
  • 自分自身が誰かに聞きたいときにも聞けなくなっちゃう

メリット

  • 集中できる!
  • 強制的に休憩を入れるので、リズムよくできる
  • 意外とあっという間に感じる
  • ものすごく疲れるので定時で帰ろうってなっちゃう
  • タスクが進む!

個人的な気づき

  • いつものテストスタイルができない
    私はかなりフリースタイルなテストをやっているので、タスクと時間を決められてしまうと
    寄り道をしたテストがすごくしづらいと感じました。
    また、普段は適切なシステムメッセージを考えたりするのですが、時間に追われるとないがしろにしそうになったので、 別の時間でフォローするか、別にタスクとして設けないといけないなぁと思いました。

また、俯瞰してみようとしなくなりがちになりました。
この辺はタスクの洗い出しと整理ができてないとよろしくないかも。。

  • タスクの洗い出し、事前整理大事
    やっぱりタスクの粒度がそれなりに小さい方が迷いが少なくていいのだろうなと思いました。
    私もいつもより集中できましたが、
    マネージャー業をはじめ、色々忙しいエンジニアがめちゃくちゃタスク消化した!って言ってたので(タスク20個くらい消化したらしい) 事前準備とか大事ね。と思ったのでした。

  • 良い椅子大事!
    今回チームメンバーでおこなうために、会議室でやっていたのですが、
    いつもの椅子(バロンチェアを使っています)じゃないと、すぐお尻が痛くなるというのがメンバー共通の意見でしたw
    次回やるときはバロンチェアまで持ち込むかも

  • 1時間スプリントも不可能ではないかも
    kyon-mm.hatenablog.com

先日

hackertackle.github.io

で、1時間スプリントの話を聞いて、すごいなって思ったわけですが、
少しだけ片鱗というか、あぁこんな感覚をベースにやっているのかな。 という雰囲気だけ感じたつもりになっています。

今回は全く別のお仕事を各々でやっていたのですが、
同じプロジェクトチームでタスクを共有しながらやってみるとかも面白いかもしれないなぁと思いました。
(私も参加するならモブテストとかがいいなぁ)

生産性あがるぞ!

もともと @NoriyukiMizuno がやっているのを知っていて、チームメンバーに展開してみたのだけど
他のメンバーも良い感触だったみたいです。

ポモドーロは一人でもできるし(会社でやるときは、周りの協力が必要なので宣言は必要)
丸一日でなくてもよいので、休日でも気軽に初めてみるとよいかもしれません:)

モブテスト(mob testing)をやってみたよ。その2

underscore42rina.hatenablog.com

2週連続ですが、今週のテストランチでもモブテストをやってみました。
(モブテストってなぁに?て方は、前回のエントリーを見てくださいね)

今回の参加者

前回より増えて12名くらい? 今回はテスト対象を作っているエンジニアや
ディレクターも参加してくださいました:)やったね!

テスト対象

先週とは別の自社で作っているサービスの1画面をテスト対象としました

やってみたふりかえり

成果

Issueが7件(うち、バグが2件とか?)でした。やっぱり効果はあるようです

よかったこと

1回目のふりかえりで「2回目はさらにテスト対象を絞ろう。画面ではなく1項目についてテストしよう」という案が出て採用しました。
テストスコープを狭くすることで、4分をぐっとバグを出すことに注力できたんじゃないかと思います。

また、最近自社に入ってきた非エンジニア(でもエンジニア出身かな)の方も参加くださったのですが
終わったあとに前職の心配をしてしまう程度にテストに対する意識を肌で感じていただけたっぽいです。よかった♡

うまくいかなかったこと / カイゼンしたいところ

  • テスト対象が基本的なことだったこともあり、新しい知見が前回ほどなかったかもしれない

 人にはよるけど、既知の内容が前回より多かったような気がしました。
それでも、非エンジニアのメンバーには復習になってよかったかもしれません。

  • ナビゲーターが多すぎた

さすがに11人は多すぎました。最低でも2グループにわけた方がよさそうです。

  • テスト対象、やりたいテストの内容によってはもっと少なくてよいのでは?

参加くださったディレクターからの提案?ですが、今回のテストの内容であれば3人くらいで十分では?という話になりました。
たしかに4分という時間で効率よくであれば、そのくらいでよいかもしれません。
ただし、もっとドメイン知識がいりそうなテスト対象であったり、シナリオテストのような内容であれば人数が多くてもいいかもね
という話になりました。

  • やっぱりふりかえり6分は短い

2回目のテストまでに改善する内容を6分でするのは無理があるかなぁと思いました。
それでも上で書いたような案がでて採用できたのはすばらしいと思います!

テストランチという短い時間なので、6分ですることをカイゼンではなく、次のテスト対象(スコープが狭い場合)を決めることに注力したり、
テスト中の説明とかにしてしまうとかの方が消化不良にならなくていいのかも?

次回のテストランチは

モブテストについては、一旦テストランチでのチャレンジは終わりです(すぐやるかもしれないけど)
各プロダクトの開発で入れてみてもいいかもなぁと思います。

次回はこのモブテストが終わってIssueを実際起こすまでに私が考えていることを 共有できるといいなと思っています(それ社内共有ツールに書けばいいじゃん。とも思う)

モブテストをやってみたよ

最近わたしの流行りのテストランチ
毎週思いついたまま、思いつかないときはだらだらと続けています。

今回はモブテスト( mob testing )

モブっていいですよね

モブテストってなんですか?

モブプログラミングのテスト版です。
といってもよくわかっていないので、海外のスライドを何となく読んだり読んでなかったりしながら
「みんな知らないからとりあえずやってみよう。体験してみよう」と思ってチャレンジしました

今回の目的

  • モブテストというのを参加者全員で体験する
  • 参加者のナレッジを共有する
  • わたしのテスト脳を共有してもらう

参加者

9名いました。
エンジニア2名、マーケティングチーム3名、CS兼テスト1名、サポート兼テスト1名とわたし(テスト)です。

やりかた

  • みんなで同じPC、モニター(プロジェクター)、場所でおこないます。
  • テスト実行⇔ふりかえり をおこないます。
  • 実際に操作するドライバーは1名です。
  • どういうテストをするかを指示するナビゲーターはドライバー以外の人です。

今回は時間に対して人数が多いこともあり、1人を書記(やりとりやIssueに書く内容などをメモる人)というロール(役割)を作りました。

特別ルール 書記

モブテストに書記というロールは特に出てこないと思うのですが、
以前ペアテストについての事例発表で書記というロール使ってるて言ってたなぁと思って入れてみました。 http://jasst.jp/symposium/jasst15hokkaido/pdf/S3-1-3b.pdf
http://jasst.jp/symposium/jasst15hokkaido/pdf/S3-1-3.pdf

これは、のちほどIssue起こすときにとっても助かりました!

ドライバー

今回1回目も2回目もわたしがおこないました。

タイムスケジュール

公開されているSlideShareを参考にしつつ、そもそも1時間しかないお昼休みにやりたかったので 無理矢理スケジュールを作成しました。

また、テストはふりかえりを活かすために複数回することを必須としました。

12:00 - 12:30 ご飯&モブテストについての説明&今日のテストアイテムについての説明
12:30 - 12:34 モブテスト1回目
12:34 - 12:40 ふりかえり1回目
12:40 - 12:44 モブテスト2回目
12:44 - 12:50 ふりかえり2回目
12:50 - 片づけ

複数回するっていうのは、昔 kyon_mm さんに 福岡でやってもらった勉強会で教えてもらって、取り入れました。

atnd.org

テスト対象

エンジニア、マーケティングチーム、CSまで色んな方が参加してくれたこともあったので、 わたしたちの会社で作っているサービスの1画面を対象としました。
わたしたちも使っているシステムなので、サービスについての説明はしなくてもOKでした。

やってみたふりかえり

成果

バグが1件、Issueに書いた内容が7件ほどありました。
8分+αの時間でこれだけ出せるのは効果が高いと思いました。

ドライバーをしてみて

「私のテスト脳を共有する」を掲げていたので、手と口をなるべく動かしつつテストしました。 * 今から何を入力するか

はあまり言えないときもありましたが、自分が思っていたよりかなりのことを伝えられたと思います。

一例ですが、スラッシュ区切りのデートピッカーがあった場合
「テキストでスラッシュ以外やスラッシュなしで日付が入れられるか」というナビゲートがありました。
ここで私が話した話

「まず区切り文字なしで入力します。20180131とかですね。(ここではこれは日付として認識できないだろうからそのまま登録できることはないと予測)
 デートピッカーのテキストエリアにコピペではりつけます。
 あ、自動補完でスラッシュが入りました。この場合はそのまま登録できるのでテストOKとします」←区切り文字なしのテストおわり

「次にスラッシュではないものを入れます。これは例えばPostgreSQLなどで使われているハイフン区切りを入れてみます。2018-0-31とかですね。
 デートピッカーのテキストに貼ってみます。あ、これだとハイフンのままですね。
 そのまま登録してみます。登録できちゃいました。(一覧画面が表示される)
 では、もう一度このデータの編集を見てみます。先ほどの値がスラッシュ区切りで表示されているので、私はこれはOKとします」←スラッシュ区切り以外のテストおわり

「どういうことかというと、ハイフンでも日付として認識できて登録できれば登録としてはOKと私は判断します。
 でも、他のデータと表示が違ってしまうと他に影響があるかもしれないので、編集画面をみてみて、表示にも影響がない(他と同じスラッシュ区切りになっていること)を確認しました」

*1

  • テストの実施
  • 入れる理由を話す
  • OKと判断する根拠、そうではない根拠を話す
  • なぜIssueに書くか、書かない理由を話す

などを話しました。いつもテストでやっていることなんですけど、これ話しながらやってみると、自分てここまで考えながらやってんのね。とちょっとびっくりします。

よかったこと

  • 1つの指示で芋づる式にテストがでてくる

モブテストのだいご味の1つだと思いますが、1つテストすると、それに関連して「あれは?」「これは?」というものがでてきました。

  • みんなで楽しんでテストができる
  • 当初の目的は達成できたかも
  • 短時間の実行なのにIssueに書くようなことがでてきた

うまくいかなかったこと / カイゼンしたいところ

  • ふりかえり時間中もテストの話になっちゃう

ドライバーのテストはしていませんが、ふりかえり中もテストの話(あれやったらどうする?みたいな)が続いてしまったので
もっとメリハリつけた方がよかったのかもしれません。

というか、ふりかえりで話すものをもっと限定してしまってもいいかもしれない(ふんわり、次のテストに向けてカイゼンした方がいいことって言ってしまったので) ここは、他の資料も読みつつカイゼンしたいところ

  • Issueの書き方も別に共有したい  後ろに書いていますが、わたしがIssueを書くときに気をつけていることが色々とあるんですが、この流れでそこまでお伝えできたら
     共有という意味では理解しやすかっただろうなぁと思います(モブテストとは離れちゃうけど)
     2回目テストを入れずにふりかえりでそれをやってみてもいいかもしれません。いいのかな

想定外の発見

  • 社内共有ツールと併用できる

普段ちっこい気づきはできるだけ社内共有システム(Tamel)に書くようにしているのですが、今回の時間で
「あ、これ詳しくはTamelに書いてるから」ということが3~4個ありました。社内共有ツール大事。書いててよかった。社内共有ツール。

ただ、書いていても使いどころや、そもそもそんな記事があるって当事者にならないとわからないので、それが短時間に4つも既知の情報を共有できてよかった♡

  • Issueに書く内容や時間も省略できるかもしれない

このあと出てきた内容をサービスプロダクトのIssueに書いたんですが、Issue書くだけで1時間以上かかっちゃったんですね。
Issueは出来事だけを書くわけじゃなく、エビデンスや、どうすべきかを知ってるかぎりのコンテキストも考えつつ
最適解を自分なりに考えて書いています。
今回はサービス担当のエンジニアが参加していなかったのですが、担当エンジニアが参加していたら、考える部分もモブテスト中に解決できるかもしれないので
Issueを書く時間が短縮できるかもしれません。

  • 時間に対してのインプットとアウトプットの量が半端ない! これ↑20分のできごとだからね!ほんとすごい。
    ただ、めちゃくちゃ疲れる!

これを実業務に入れようとすると、適切な頻度や範囲みたいのはあるかなーと思います。 マリオでいうスターとった時間みたいな感じ。

さて次回

すっごい疲れましたが、来週ももうテスト対象のサービスがリクエストきたのでやってみます。
次回はサービス担当エンジニアが参加してくれるので、また違った発見がありそう!Issue問題も解決するといいな:)

Twitterでは「#テストランチ」で水曜日くらいに呟いています。

これこうした方がいいよ。うちはこうしてるよ。とかあったらぜひ教えてください。時間配分とか。

参考にした資料など

教えてくださったみなさま、ありがとうございます♡

Slideshare https://www.slideshare.net/llewellynfalco/mob-testing-72610210

https://www.slideshare.net/maaretp/mob-testing

www.stickyminds.com

devtest.hatenablog.com

本・雑誌

WEB+DB PRESS vol.102「はじめてのペアプロモブプロ」

*1:・・・そういえば区切り文字でNGパターンやってないなぁ