この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Agile QA Night!! 2 #D3QA
2019年6月20日に開催されたAgile QA Night!! 2のレポートです。参加申し込みは最終的に196/120人という注目のイベントでした。
僕自身QAが居るチームだった経験がとても少ないので、アジャイルなチームの中でQAが何を考えて、どう過ごしているのかを知りたくて参加しました。
先に、今回覚えた良い単語 ルンバ効果 。テスト自動化する前にやることあるよね、という文脈で使われていました。詳しくは下の資料をご覧ください。
会の様子は Togetter でもまとめられていました Agile QA Night!! 2 #D3QA - Togetter
セッション
【WACATE再演】組み込みマニュアルテスターだった私が、Web系自動テストエンジニアに！？テストエンジニアに求められるスキルと今後のキャリア
※ 再演ということで以前の公開されている資料を参照しています。
要約
組み込み系からWeb系に転職して変わったことはいっぱいある。だけども基礎知識は変わらないので、それを基にそれをそれぞれの現場で大切にしている事を自分で考えて適応していこう。また、転職してコードも書くようになった。「出来ない事ができるようになるの、楽しい〜」
転職しても変わらなかった動きと転職して変わった意識
要約
転職してリリースサイクルは短くなったが、そんなに動きは変わらない。 変化した事は、実装する前に”何で作りたいんだっけ？”から関わったり、よりメトリクスとテスト技術を重視するようになったこと。
WFとAgileで変わったこと変わらなかったこと
要約
多国籍大規模重厚な複合機の組み込みプロジェクトから、B2B Webサービスに転職。前職から有効なテストになるように「企画書を見れる範囲でよいので見せてください」とか、意思決定会議に参加するなど越境していた。転職して計画を守ることから、ユーザーの価値を大事にするように変わった。 製品やテストの目的、開発チームの外側をフォローすること、テストは状況次第ということは変わらない。
アジャイル開発でのテストのやり方 〜私の場合〜
まつ さん
要約
テスターちゃん【4コマ漫画】 を書いてる。
特殊なデバイスのテストをしていた。開発チームとの関わり方は2パターンあった。
- 餅つき型: 完成した部分をテストする、それを繰り返す。 -> 疲弊しやすい
- 管理メイン型: スプリント後半にテスト スプリント後半にテストする
最初、有るべきテストプロセスを当てはめてみたが、辛い。形骸化していつか回らなくなる。なので、QAチームで観点の共有や認識合わせを先に行った。探査的テストをメインに必要な箇所をスクリプトテスト、自動化は今回追加された以外の部分を主要部分おこなった。
パネルディスカッション
Slido - Audience Interaction Made Easy を使って投票形式で行いました。登壇した方々がSlidoで上がった質問に対して回答する形です。
- 顧客フィードバックをどう収集してるか
- GoogleフォームからJiraになる、一番早くて4時間でリリースした
- 会話ログから日本語の流行り廃りが分析されてQA/開発チームに来てた
- B2Bだと営業から情報が来る
- E2Eテストを書く前にまずは自然言語で書いてる、使用されてるツールはなに？
- Open Source Test Automation Framework | GaugeとSelenium - Web Browser Automationを使ってる、関連付けて書く
- E2Eは増えると遅くなるので厳選してる
- 並列化とか、これから
- Cucumber 遅くなったらUnit
- どうすれば仕様（E2E自動テスト）を書いたてからテストできるようになるのか
- 愚直に、ちょっとずつ
- 何も無い時にQAとして入っていく時にどうしてるか
- 製品の存在意義ってなんだ -> そこはE2Eテストされてる
- 開発者が単体テストを書く文化が根付いてない状態で書いてもらうには？
- 開発者と一緒にテスト計画を立て、明確にUnitTest/API叩く/手でやるを明確に分けてあげる -> 手でやるところは減らそうぜ
- テスト嫌いな人は採用しない/居ない、各テストでどこまでやればいいのかの話をする
- そもそも(Unit)テストを書かないとCommitできない
- 探索的テストの結果が妥当であると同会社に説明してるか
- テストノート（どういうことをやったか）を書いてた前は。
- ログをとったりケースに残す。リスク大きいものに関連するものをやってるよ。後は信頼感あると聞かれない。
- ログ残してない、信頼してもらってる。不具合はチーム全体の責任。責められることはない。探索的テストとはいえ、ある程度プランニングをして合意している。
- WebQAをした経験を組み込みQA（や前職）に活かせることはあるか？
- 基礎は変わらない、ここ大丈夫？提案する、ちょっとずつ自動化
- リスクベースでやる、デイリービルドする
- 基礎は変わらない、実行は開発者がしているので、実行の部分でわかったことを伝えていければ良くなる
- 静的レビューの文化を作りたいが、スキルや業務理解できる人がいない
- 誰も完璧じゃないので、スキルとか業務理解とか以前に、「本来何やりたいんだっけ？」とか会話の中で気づいたりする。ちょっと相談したいレベルで会話してみては
- なんの、なんのためのレビューなのか？コード、要件？レビューの目的を明確化して適切な人がレビューする
- 現状を知るために、状況に合ったメトリクスを用意する、最初に採用するメトリクスは何？
- 定性的になっちゃってるもの、起票〜完了、直近何チケット解決したか
- テストの質を見るならDDP(Defect Detection Percentage )がKPI、開発ならリードタイム、必要になったら取る
- 開発としてはないかな、お客さんがどこを使ってるかは取ってる
- レベル1−5がどれくらいあるのか、どの開発者に修正が寄ってるか
- 企画と開発とQAの関わり方
- Face to Faceがよいが、QAは拠点が違ったので、出張させてもらってた。ビデオ通話つけっぱなしでバーチャルまつやさん
- エンジニア、デザイナ、営業、アナリスト、顔合わせながらやってる。どういうふうに使ってる？とか知ってる人に常にやりとりできる状態
- スクラムイベントで企画/マーケ/セールスに来てもらう、PBIに提案、グラフは誰でも見れる
- アジャイル開発で、XSS、CSRFなど脆弱性試験は性能試験はどうやってる？
- 強い専用チームが居る、2週間くらい、いじめてもらってる。基本はコードレビュー＆静的解析。新卒に脆弱性のあるサイトを渡して防いでもらい、ボコボコにする
- 餅は餅屋、Proがやるのがベター。別チームでチェックしてた
- QAよりも、他の強いエンジニアチームがやってた
- 餅つき型でQAしてる。今できてる機能のテストで手一杯。リスクを抽出するとか、全く余裕がない。
- 全く同じ状況だった。人を分けることはした。がんばる。これあかんなという感じになった。1時間とか集まって会話して軽い分析はしてた
- ボトルネックがどこ？テストが遅い？QAだけじゃなく、チームの仕事。人員コントロールミスなので、人増やすor開発がテストするなどチームで解決する
- ちょっと話してみる
- 何か良い書籍とか資料 Foundation Level Extension シラバス アジャイルテスト担当者
まとめ
基本は変わらないけど、プロダクトの目的や状況に応じたテストをしている。有るべき形のテストや前例踏襲のテストを適用してもうまくいかない。という、QAの世界もエンジニアリングやプロセスの世界もそこは一緒なんだなって感じました。現場や時代によって変化するやり方も大事ですが、根本にある考え方って財産ですね。