BizReach QA Meetup というイベントに参加しました

はじめに

2019/7/18に【BizReach QA Meetup】というイベントに参加しました。
発表資料のリンクとイベントに参加した際の自分のメモとtwitterのつぶやきをまとめてみました。
イベントのページはこちら
twitterはこちら：#D3QA

発表1:〜 孫子に学ぶ 〜　QA組織の立上げカタ

やまもとくにおさんの発表

資料の場所

[Biz reach qa meetup] qa team_build from 久仁朗 山本(旧姓 村上)

発表資料の抜粋とメモ

・ビズリーチQAチーム2018年8月に立ち上げ
　 - 立ち上げ時・・QA：開発の割合＝1:300
　 - 現在・・QA55:開発400
　ほとんどがテストチームだけど、PMO/SEPG、教育もやってる。
・ビズリーチQAチーム開発業務全般の品質向上が目的
・9年間QA無しだったところにQA文化を根付かせた。

・「QA」はテストじゃなくて品質保証
・QAの目的：
品質の可視化と向上を促進させ、サービス価値を向上させる。そうすれば自然と会社の市場価値も上がっていくからコストをかける価値は十分にある。
・Total Quality Management を目指している。
・プロダクトのQAだけではなくプロセスのQAもやっている。

基本のカタ

資料より抜粋

彼を知り己を知る
基本のカタ：彼を知り己を知れば百戦あやうからず。
　⇒いわゆる情報収集とか

資料より抜粋

資料より抜粋

事例：QA組織立ち上げ時
・総合テストで組織の20%、結合テスト等も含めると30~40%がQAのコスト。
・QAのコスト感を経営層に伝える。開発の2割が総合テストにかかることはまず説明する。経営層に対してはデータで示すのが効果的。
・「全部はできないよ」と相手に言わせたら、どこまでやるかを聞いていく。入り込みやすい。
・アジャイルサムライでも1つのロールがQAとなっている。スクラムでも、つまり最新の開発手法でもそれぐらい必要。

プロジェクト毎の入りカタ

資料より抜粋

・斥候、遊撃、工兵
分析と調査、探索的テスト、スモークテスト

・共に戦う
QAがいる＝開発と並行してできる。
人それぞれのベロシティを考慮した計画を立てる。
テスト計画で忘れがちなことは個人のベロシティ。これをミスってアサインするとミスる
最初に緻密すぎる計画をたてない。変動を見越して随時見直す。

資料より抜粋

・時間こそが最強のリソース
遅くなってうまくいったことはない。
「あの時だったらあの手が打てたのに。」ってなりがち。
⇒できるだけ早く入って共に戦う姿勢を見せる。
Quality Cost Delivery でDだけは取り返しがつかない、最重要のリソース。良いと思っても期限が過ぎたら使われない。条件にマッチしなければ使われない。早め早めに動いた方が良い。
とりあえず、やれるところからやる。共に戦う姿勢を見せて現場の信頼を得る。
・一方で、勝算無きは戦わず。
ムリはしない。勝てないなら撤退も考える。何を諦めるのか決める。
勝てない＝ビジョンに合わない。工数、予算などの都合がつかない場合のこと。勝ち目が見えない場合は無理しない 。

プロジェクト毎の捌きカタ

資料より抜粋

・最初の握りが大事。
変動要因があることは最初に伝える。とか。

・勝ち方、勝筋、落とし穴。
リソースの判定。
リソース期限を延ばす。
⇒プロジェクトについての勝ち方、落とし所を決めておく。

資料より抜粋

割と当たり前のことが書いてあるが、書いてあること、本当に普段考えている？

QA・テスト組織の育てカタ

資料より抜粋

・テストチームはやり方によっては簡単に開発チームの生産性を下げてしまう。どうしたら会社の生産性を高めることができるか？をちゃんと考え抜く。最善の手を選ぶ。お互いに納得感があることが大事。

終わらせカタ

資料より抜粋

これは終わりカタ（終わらせカタではない）
・メテオ
テストがQA組織がなくなる。
・ハルマゲドン
親会社の判断で消える。
・ラグナロク
組織長同士の戦いで負けた方が消える。

資料より抜粋

これが終わらせカタ。
自分で終わらせる方法

まとめ

資料より抜粋

発表2:とあるQAチームの立ち上げから半年〜1年のお仕事

井芹久美子さんの発表

資料の場所

発表資料の抜粋とメモ

資料より抜粋

資料より抜粋

資料より抜粋

・2週間単位でテストしている。
テスト分析、設計＝1週間
テスト実行＝1週間
開発とQAが1週間ずつずれて、2週間に1度のリリースを行っている。協調×柔軟な関係性。
QAと開発がずれて動くことで無駄なく開発が進められる

・その間開発チーム何している？
　⇒次の設計に向けた設計、PGM

資料より抜粋

・QAと開発の関係
一緒にテストを考えたり、テスト結果を元に開発に聞きに行くことはある。
⇒基本的にQAは独立しているが、完全に単独で存在しているわけではない。

資料より抜粋

・QAはテストだけではない。
過去と比べて気になる変化
このプロセスは何の目的でだれがやっているのか？

勉強会：30分とか1時間とか。できるだけ早くやっていく。

大きい課題
現場の状況を見ながらやっていく。
コミュニケーションミスが発生していそうな用語とか。

資料より抜粋

対応には緩急をつける 小さいものを軽く始める、影響が大きいなら情報収集しつつ少しずつ準備

資料より抜粋

プロダクトのテストプロセス改善だけがQAの仕事ではない。もっと広い

資料より抜粋

テストだけでない、周辺技術やプロセスへの関心もQAには必要。
視野を広げる、テスト以外の改善策も提案したい。
QAがやりたいこと
品質の安定化、向上
⇒開発プロセスのそこかしこにある。

資料より抜粋

・QA経験が少ない/ない人へ
品質に関して自分の考えを持つこと、考える癖をつけること、自分の考えをもつことが大事
やりたいこと、その実現に必要なこと、具体的に考えることが大事

発表3:新卒入社の人達にテストの大切さを伝えた話

ブロッコリーさんの発表

資料の場所

今回の発表資料：https://speakerdeck.com/nihonbuson/bizreach-qa-meetup

・ブロッコリーさんの過去の発表資料っぽいもの

発表資料の抜粋とメモ

ここでの新卒社員は開発の人。QAではない。

新卒研修の内容

資料より抜粋

研修監修者からはTDDのやり方のレクチャーを1日でとオーダーを受けたが、テストについての考え方から2日使うように変更した。

資料より抜粋

・2日間で研修
テストに対しての考え方
　⇒TDD以前に必要。TDD以前に知るべきことがある。
テスト設計
自動テストについて
TDD

実際のカリキュラム

資料より抜粋

・JJUGでの資料はこれ

テストの7原則
このあたりが参考になりそうな気がした。
・テスト担当者なら絶対に覚えておきたい『ソフトウェアテストの7原則』
・ソフトウェアテストの7原則について経験と照らし合わせて考えてみる
・システムテストの観点と七原則
・ソフトウェアテストの基礎：ソフトウェアテストの7原則
・7payの会見から学ぶソフトウェアテストの7原則

資料より抜粋

1日目1限目＝1日目の午前
1日目2限目＝1日目の午後一

テスト設計の目的：なぜテスト設計が必要か

資料より抜粋

CFD
この辺かな・・・。
・ソフトウェアテストの本質を振り返る
・テスト技法「CFD」実践ワークショップ ワークショップの取り組み～ 現場での実践を目指して ～

高位テストケース＝ハイレベルテストケース
低位テストケース＝ローレベルテストケース
これらの考えは開発者の視点で大事なこと。開発者が適切なテストケースを作れるようにするために必要。

ハイレベルテストケース／ローレベルテストケース
・テストケースの表現と粒度（マニアック編～ISTQB（JSTQB）の情報から考える）
・ハイレベルテストケースとローレベルテストケース
・テスト条件とは何かの解説ぽい記事

資料より抜粋

テスト自動化の8原則
・テスト自動化研究会
・テスト自動化の8原則について

E2E：自動テストのE2E

資料より抜粋

TDD：ライブコーディングを動画として撮ってそれを見せた。

資料より抜粋

・ソフトスキル
モブプロすることで、ついて来れない人に合わせてチームで協業することを学ばせた。
モブワーク&TDDでfizzbuzzをやる。レベルの高低差があるチーム内での協業を学んでもらう

資料より抜粋

Code smell：どういうコードが汚いのか

・Tennis-Refactoring-Kata
わざと汚いコードがGitHubにあがっている。
⇒これかな？
https://github.com/emilybache/Tennis-Refactoring-Kata

・TDDサイクルが短い
Tennis-Refactoring-Kataで「汚いコードだな・・・」とか言ってた人が自分でレガシーコードを書いていたりする。
このテストコードがなぜ必要なのかを考える。

資料より抜粋

・cyber‑dojo
何時何分にテストを回してその結果がグリーンだったのかレッドだったのかがわかる。
TDDのサイクルを長くすると、20時にグリーンだったのが20時5分でコンパイルエラーになったりする。それを直すのに5分かかったりする。
⇒TDDのサイクルを長くするとエラーの状態から回復するのに時間がかかる。長時間テストを通さないことが負債になる。

資料より抜粋

モブプログラミングにおける交代のタイミング：http://nihonbuson.hatenadiary.jp/entry/2018/12/25/193000

・詰め込み研修なので、全部理解されなくとも、聞いたことはないよりかは、知っていた方がよいだろう、と思ってやった。

研修を受けた新卒の感想

TDDの話がないに注目。
テストの考え方に関する感想が多かったのが良かった点だと思っている。

懇親会

私は不参加でした。twitterのつぶやきだけピックアップしておきます。

【質問】
ビズリーチさんのQAってバッググラウンドが様々でかつ経験値高い人の集まりですが、QAとして意見や方向性が違ったりした時どうやってまとまってますか？
【頂いた回答】
確かにバッググラウンドややってきたことは違うけど、皆、外の勉強会やイベントに出て「色んなやり方がある」と分かってる人たちだから、自分のやり方や意見に固執する、って感じはない。むしろ「こんな記事あったよ」とかどんどん情報を発信共有する雰囲気。

・モブワークの効果。
例えばプログラミングが得意な人は、意外と自分が説明できないことに気づく。メンバー同士、思うように進まずもどかしい思いをするのことで、チームとして意識を合わせていくことの大切さを学ぶ。

・ハイレベルテストケースの効果。
テストの意図を残す。ローレベルテストケースだけでは意図が残らない。座学を初日に実施して、2日目のワークで身をもって体感してもらう。

・実装に追われているとHowに囚われてしまい、テストのことを考えることができなくなる。それを後悔する様子が研修後の新卒チームに見られた。

・新卒でない社員(開発メンバー)には、初日の研修(テストの目的や考え方)の研修のみ実施した。こちらも好評だった。