Zenn
🧪

ソフトウェアテスト自動化カンファレンス2024 イベントレポート

2024/12/29に公開
イベントレポート
tech

イベント概要

ソフトウェアテスト自動化カンファレンス 2024 を視聴した。
特に印象に残った内容を以下にまとめる。

ソフトウェアテスト自動化カンファレンス 2024 - connpass

一部の講演は後日、テスト自動化研究会の YouTube チャンネル で公開予定とのこと (2024/12/29 時点ではまだ未公開)。

印象に残った内容

テスト自動化失敗から再挑戦しチームにオーナーシップを委譲した話

テスト自動化失敗から再挑戦しチームにオーナーシップを委譲した話/STAC2024 macho - Speaker Deck

  • 1 人でやらずチームみんなを巻き込んで E2E を対応する
    • テストツールの選択
    • E2E の実装
  • Flaky テストの扱い
    • ハッピーパスを P1 として決定づけた
    • P1 が落ちているものはリリース中断

振る舞い駆動開発(BDD)における、自動テスト作成の前に大切にしていること

振る舞い駆動開発(BDD)における、テスト自動化の前に大切にしていること #stac2024 / BDD formulation - Speaker Deck

  • BDD にとって振る舞いとは何かを考えることが大事
    • given-when-then に沿えば良いわけではない
  • ユーザーストーリーをいきなりテストコードにせず、発見・定式化・自動化する
    • PO とテスターと開発者が揃って具体例を持って確認する
      • ビジネスチームが参加していない BDD は意味がない
    • 最悪自動化まで行ってなくても良い。発見・定式化することが大事
  • 発見
    • 明確な具体例を使用してドメインを構造的に理解していく協調作業を行う
      • ラムズフェルド行列: 知らないことをわかっていない状態から知っていることをわかっている状態にする
  • 定式化

アジャイルテストの 4 象限で考える、プロダクト開発の品質への向き合い方

アジャイルテストの 4 象限で考える プロダクト開発の品質への向き合い方 - Speaker Deck

  • 第一象限
    • コードレベルのテスト
    • 開発者エンジニアが実施
      • レイヤーごとにテスト観点を言語化
      • モデルケースの実装を作成しメンバーがコピペで追従できるようにした
  • 第二象限
    • 機能要件に関するテスト
    • QA エンジニアが主導
      • シナリオの整備
      • リグレッションテストを実施
  • 第三象限
    • 探索的なテスト
    • 既存機能の置き換えのため skip
  • 第四象限
    • 非機能要件に関するテスト
    • 開発エンジニアが主導
      • オブザーバビリティの整備、OpenTelemetry を計装
  • パーソナライズ基盤を実施することに
    • 特定プロダクトの内部機能をマイクロサービスとして切り出すようにしたい
    • ステークホルダーが多い、Go に変えたが実務経験メンバーが少ないなどの問題があった
  • 問題を整理する
    • クネビンフレームワークで整理
    • 複雑性に向き合う必要があるとわかった
  • リスクストーミング
    • リスクを言語化
    • どこをテストした方が良いかわかった
  • 品質特性
    • プロダクトが満たすべき品質の特性
    • 目線を揃えて定量的な目標にする
      • → テスト計画を中心に設計・リリース計画を立てた
  • AI をうまく使う
    テストケース漏れがあったが copilot を使うと漏れがなくなったとのこと

学んだこと

  • BDD の解像度が上がった
    • given-when-then に沿えば良いわけではない、とのことで PO、ビジネスチームとの協力が必要とわかった
    • 発見・定式化が大事
  • 問題を分類化することが大事
    • テストを 4 象限に分ける
    • 問題をクネビンフレームワークに整理する
    • リスクストーミングでチームでリスクの言語化を行い、テストする内容を絞った

今後の活用

  • BDD の発見・定式化を意識する
    • 特に発見が足りておらず、後から仕様が追加されることになったことがある
    • 具体例を示して PO と解釈を深めていく
  • 問題の整理をする
    • 問題をクネビンフレームワークに整理する
    • リスクストーミングでチームでリスクの言語化を行う
  • UT の書き方の共有する
    • テストシナリオ
      • AI で機能要件をもとにテストすべき内容を箇条書きにしてもらう
      • それが満たせているか？をチェックする
    • UT
      • テスト実装サンプルを作る
      • hooks に切り出して網羅的にテストを copilot に書いてもらう

所感

自動化の導入から BDD、アジャイルにおけるテストなど幅広い内容で学べたと感じた。
チームに導入したい考えがあり早速チームに共有した。

Discussion