Agile QA Night!! 2 レポート

Agile QA Night!! 2 に一般参加してきました。
D3さんのイベントに行ったのは今回が初めてです。
というより、QAエンジニアとしてQAのイベントに参加すること自体が初めてです。どきどき。

概要

connpass

#D3QA でツイートされた内容(Twitter)
togetter (まとめ感謝)

• Agile開発の現場にいるQAエンジニアがどのようにプロジェクトに関わっているか、というテーマで開催しているMeetupです。

• 今回は特に以下の話が重点的にあったかなという印象。

  • ウォーターフォールの現場との違いは？
  • 同じAgileでも企業によってQAの在り方は変わるの？

発表1: 【WACATE再演】組み込みマニュアルテスターだった私が、Web系自動テストエンジニアに！？テストエンジニアに求められるスキルと今後のキャリア

• 登壇者: えっちゅーさん

• 資料

• 要約

  • 「組み込み系・受託または客先常駐・ウォーターフォール」の現場から
    「Web系・自社開発・アジャイル」の現場へと転職したえっちゅーさん。
  • チーム体制も持てる裁量もテストに対する考え方も異なっているため戸惑っていたものの、基礎を大事にすることでこれまでの経験が活かせると気付いたとか。
  • 基礎知識、現場に適応できるほど理解してますか？

発表2: 転職しても変わらなかった動きと転職して変わった意識

• 登壇者: ブロッコリーさん

• 資料

• 要約

  • (すみません、メモ取り切れていないので抜け漏れあります)

  • 前職では…

    • 実装完了後にQAが入るため、不具合を検出しても手遅れになりがちだった
    • 自動テストが ルンバ効果 状態
      • ルンバは動かす前に部家の片付けが必要
      • 自動テストも、それ以前にやることあるよね、という話
      • 参考: テスト自動化とお掃除ロボット

  • 現職では…

    • 自動テストを使う範囲を狭めて、その分設計レビューに時間を使っている
    • 現状把握のために状況に合ったメトリクスを用意する
      • 「もうすぐできますよ」といったあいまいな逃げができなくなる

  • テスト技法の大切さ

    • そもそもこれってどうなればOKなんだっけ？という視点を忘れない
      • 例えば「半角英数字で入力」と「半角 の 英数字で入力」では期待値が変わってしまう
    • テスト技法をベースに進めると、開発担当者もQAの観点が理解しやすくなる

発表3: WFとAgileで変わったこと変わらなかったこと

• 登壇者: コヤマンさん

• 資料

• 要約

  • 越境的な動きを続けてきたコヤマンさん。
    企画書を見せてもらうよう交渉したり、時には意志決定会議にも参加したり(!!!)
  • 開発チームが仕様を考えているときに、違う視点からフィードバックできるのがQAの強み
  • 現職では
    • 何をテストするかはリスクベースで考える(出たらマズいものは何か)
    • やれることは全部やる。判断基準は「この日にリリースすることで生まれる価値」。
      逆に「リスクが高いからリリースしない」と舵を切ることもできる。
  • テストの目的と活動はどの現場でも同じ。細かいやり方は状況で変わる。
  • いずれの現場でも、開発者の考えている範囲の外側を指摘できると喜ばれる。

発表4: アジャイル開発でのテストのやり方〜私の場合〜

• 登壇者: まつさん

• 資料

• 要約

  • アジャイル開発のテストは主に2種類
    • 餅つき型
      • スプリントの中で 開発→テスト→開発→テスト と繰り返す
      • 切れ間なくテストが続くのでだんだん疲れが……
    • 管理メイン型
      • スプリントの前半に開発、後半にテスト
      • 前半にテストの準備ができるから効率的？ただの小さいウォーターフォールでは…？
  • アジャイルのスピードについていくには
    • 各自仕様書読み込み → 集まってみんなで観点を出し合う
      • 観点の共有と認識合わせ、そして開発への疑問点の洗い出しにつながる
    • 早い段階で大きいバグを見つけるために、以下の順でテストを行う
      1. スモークテスト(セッションベースドで)
      2. 組み合わせが複雑なところをテストケースで実施
      3. 複雑な手順の実施
      4. 総仕上げでざっくりと全体チェック
    • 自動テストは今回追加された機能「以外」をテストするために使う
      • 新規機能の自動テストは、テスト完了後に行うこと
  • 餅つき型は後から実装された機能のテストが手薄になりがちなので注意

パネルディスカッション

Sli.do に寄せられた質問に登壇された皆さんが答えるお時間。

• 顧客フィードバックとどう向き合うか

  • Googleフォームに入力されたFBがそのままJIRAチケット化される仕組みを採用している。
  • QAよりも開発チームの方が要望をすくうことが多いかもしれない。

• E2Eテストでどんなツールを使っているか

  • GaugeとSeleniumを組み合わせて使っている
    • 参考: Gaugeによるe2eテスト
  • E2Eドリブンだとボリュームがふくらみそう
    • E2Eを増やしすぎると保守がキツくなる
    • 重くなってきたら、どの部分をUnitテストに移行できるかを考える

• 開発者が単体テストを書いていない場合

  • テスト計画で責任の所在を決める(ここはUnitテストでここからは手動、とか)。
    テストを書かせる方向にハンドリングしよう。
  • テスト書かない・書きたくないエンジニアは採用しない(!!)

• 探索的テストの結果をどうステークホルダーに説明するか

  • テストノートを作る。どんなことをテストしたかなど。
    • アジャイルのサイクルが速くなるにつれ書いてる時間がなくなったけど……
  • 探索的テストで何を見ようとしているかは事前に報告しておく

• もし組み込みシステムのQAに戻ったら、現場をどう変えていきたいか

  • まずテスト自動化
  • デイリービルド体制を整えたい

• 静的レビュー文化を作りたいけどスキルのある人がいない

  • 誰も完璧に知り尽くしている人はいない。
  • レビュワーが「何がやりたいんだっけ？」と問いかけることで気付きが生まれることが大事。
  • レビュワーだから何か指摘しなきゃいけないわけではない。
  • そもそもレビューの目的が明確になってないと、誰が適切な人かもわからないのでは

• 「状況に合ったメトリクス」(ブロッコリーさんのセッションで出た話)、最初に何を採用すればいいのか

  • DDPを見る
    • 参考: DDP（Defect Detection Percentage）を考えてみた
  • よく使われるところがどこかヒアリングする
  • 開発のボリュームが大きくていっぱいいっぱいになっている人が作った部分は、気を付けて見るようにしている

• 脆弱性試験、性能試験はどうしているか

  • セキュリティはその道のプロに。
  • 新卒に脆弱性だらけのサイトを修正させる研修がある

• 餅つき型でしんどいです

  • 機能別に専任者を設けて切り抜けるしかない。後は探索的テストなどでボリューム調整するなど。
  • 少し集まって分析しあう時間を設ける
  • ボトルネックがどこにあるのか考える
    • テストが重いのか開発のスピードが速すぎるのかで問題が違う
  • ひとりで頑張るのはアンチパターン。協力者を増やそう！

まとめ・所感

JSTQBのような基礎をベースに、「何をテストしたいのか」という視点を持ち続けよう！
という話がどのセッションでも共通にあったという印象です。
色んな現場を経験すると、基礎の侮れなさに気付くのでしょうか……

パネルディスカッションでは個別のセッションには出てこなかった細かい手法にも言及されていました。
知らない用語も多々あったので、少しずつ調べながら自身のチームに合ったやり方を探っていきたいですね。