「JaSST’25 Tokyo（1日目）」に参加してきました

大規模プロジェクトにおける品質管理の要点と実践

大規模なウォーターフォール案件
要件分析
- 要件が洗い出しきれなかったり暗黙的で隠された要件があったり
- 現場の人に聞くことが大切
- 担当者はシステム寄りな人が多いから
- 100%を目指すと終わらなくなる
  - 時系列で見ていって収束してくるところ
- システム起因のリプレイスでどこまで業務改善を入れるか
  - 利用者は現状で満足してることもある
  - 業務側の教育コストも考える必要
システム設計
- IF同士の不整合があるまま進行してしまうことがある
- 実装レベルで例外とかまで設計して静的チェックできるように
  - スキルの高いメンバーを入れないと難しい
実装テスト
システムテスト
- 一部のテストが数日止まるとか
  - それにちゃんと気付けるようにしないといけない
  - 人が多い時に作業者の声を聞けるように
- 未完成の機能があって一斉にテストを開始できない
受け入れテスト
- ユーザのテストをするための習熟度
- 環境起因の問題
- ユーザによる正確な問題報告
- 使ってもらって初めて分かる要件漏れ

橋爪祐子さん（KINTOテクノロジーズ）
伊藤望さん（MagicPod）
木川広基さん（ポールトゥウィン）
尾崎由有子さん（ポールトゥウィン）

UIテストの自動化ツール
- テスト生産性向上
  - 人は人にしかできないテストに注力
- 開発生産性向上
  - フィードバックがはやいことで記憶が鮮明なうちに対応できる
自動化のおすすめの使い方
- リリースのたびに繰り返す回帰テスト
- 基本的なストーリー
- 異常系など細かいケースはあまりペイしない
- 何をE2Eで何を単体テストでやるかの切り分けは難しい
うまく使えてないケース
- リリースしてからテストしてるようなケース
- 毎日回して安定させてるといい

テストフェーズでバグが多発してリリースが遅れた
振り返り
- 使用誤認しやすい環境
  - 仕様変更があったが気づかずに開発していた
  - Acceptance Criteriaを全員で作るように
- テストが後工程に集中していた
  - リファクタリングしたいところがあったがテストがQAに依存していてやり取りが起きるので諦めた
  - 開発中からテスト
Acceptance Criteria
- 機能が満たすべき条件
- Gherkin記法で書く
- 仕様変更が入ったら必ず修正
- これを元にテストをする
- すべてpassしないとリリースできない
テストの実装
- Playwrightでテスト
- Gherkin記法のファイルを読み込めるプラグインがある
テストの種類
- Unit Testで内部のテスト
- Acceptance Testで仕様のテスト
- E2E Testで外部連携を含めたテスト
開発フロー
- 仕様策定時にAcceptance Criteriaを全員で作る
- 実装前にAcceptance Criteriaを元にAcceptance Testを作る