- 2025/3/28
- https://jasst.jp/tokyo/25-about/
AIによるソフトウェア品質保証の現在地点とこれから
石川 冬樹さん（国立情報学研究所）
松浦 隼人さん（Autify）
守屋 敬太さん（Autify）
末村 拓也さん（Autify）
- Autify Genesis
- 生成AIでテストケーステストシナリオを作成する
- 仕様書や設計書や操作マニュアルなどがインプット
- テストシナリオとテストコードがアウトプット
- PlaywrightとAutify
- 不足する情報はAIから質問される
- ログインユーザは何使うかとか
- 課題になるところ
- インプットの品質が高くないといけない
- アウトプットの妥当性を人間が判断しないといけない
- Autify NoCode
- ノーコードでテストを作れる
- 手動テストを自動テストに置き換えるのが大変
- 手動は曖昧があってもコンテキストを理解してるから対応できていた
- 自動テストだと品質のばらつきはなくなるが融通がきかなくなる
- 生成AI時代のソフトウェアテスト
- 常識的なことは生成AIは強い
- 曖昧なインプットだとアウトプットも曖昧になる
- 常識的なことなら曖昧でもうまく判断してくれる
現場からお届けします〜モバイルアプリテストにおける工夫と挑戦〜
森田 麻沙美さん（Voicy）
藤 徹さん（マネーフォワード）
梅津 侑弥さん（メルカリ）
- モバイルアプリテストの課題
- 多様化する開発形態
- 頻繁なリリース
- 開発サイクルの高速化
- スピードと品質
- 時間がない中でどう品質を担保するか
- スピードと品質のバランスを保つための工夫
- ストア申請前にリグレッションテスト
- リリース判定テストとして優先度が高い機能のみを手動でチェック
- テストケースを増やしすぎないように
- ストア申請前にリグレッションテスト
タイミーQAのリアルな挑戦：DevOps時代の開発生産性と品質文化を創造する
吉野 正義さん（タイミー）
矢尻 真実さん（タイミー）
山下 さなえさん（タイミー）
岸 健さん（タイミー）
片野 晃一さん（タイミー）
松田 幸典さん（タイミー）
- タイミーの組織構造
- チームトポロジーがベースになっている
- ストリームアイランドチームが14
- エンジニアは150人
- QAチームはイネーブリングチームとしての立ち位置
- QAチームは6人
- 2023/3にできた
- テスターはいない
- エンジニアがやる
- 価値あるプロダクトを素早く届ける
- 自立して品質の高いものを素早く届ける
- Capaability/Agility/Reliability
- QAコーチの役割
- スクラムチームが自律的に品質保証できるようにあらゆることをする
- 障害発生時にも中に入ってポストモーテムも参加し改善を考えている
- ODC分析による欠陥の分析
- SETの取り組み
- 自動テストコードの作成や実行のための環境整備
- 継続的に運用していくための整備
コドモンのQAの今までとこれから-XPによる成長と見えてきた課題-
砂川 雅裕さん（コドモン）
https://speakerdeck.com/codmoninc/codmons-qa-journey
- コドモンの開発とQA
- 創業期は体系的なテストの整備がなかった
- スクラム導入
- 自動テスト導入
- うまくいかずAutify導入し大枠をE2Eで
- XPを導入
- ATDD/TDD
- QAでXP
チーム全員で品質課題の改善のために取り組んだことを振り返る
粟田 恭介さん（ログラス）
https://speakerdeck.com/wooootack/quality-improvement-team-reflection
- 品質ナラティブ
- 責任ナラティブ
- 誰が品質に責任を持つか語られているか
- テストナラティブ
- テストの技術について語られているか
- 価値ナラティブ
- テストの価値について語られているか
- 責任ナラティブ
- スプリントゴール
- タスクベースではなくチームにとって価値があるものを置く
- フェーズを積み重ねていって最後に価値が生まれるような切り方だった
- 小さく価値を生む単位に変えた
- 機能が小さい単位になるのでテストの単位も小さくなる
- テスト分析/設計
- 影響範囲の考慮漏れが起きていた
- いきなりテストケースを出されてレビューするのが難しかった
- テスト分析をするようにしたことで認識があった状態でテストケースを見られるようになった
- 暗黙知の共有にもなった
- 工程が細分化されたことでそれぞれの目的がはっきりした
- 完成の定義
- チームで大事にしたい文化や価値観を含めるようにした
- 新しい取り組みを浸透させやすいように
- 最小限の内容だけにする
SaaSプロダクト開発におけるバグの早期検出のためのAcceptance testの取り組み
冨田 浩史さん（ナレッジワーク）
https://speakerdeck.com/kworkdev/acceptance-test-for-early-bug-detection-in-saas-product-development
- 開発プロセス
- PRD(PDM) - Design(デザイナー) - Design Doc(エンジニア) - 実装 - 開発テスト
- DesignDocのタイミングでQAがテスト分析/設計
- 実装完了してすぐの状態でQAのテストでバグが多発する
- 要件と違った実装になっている
- 手戻りが多発してスピードが低下
- 問題発生のパターン
- 基本動作しかテストしてない
- 実装した範囲内しかテストしてない
- 経験/勘/思いつきでテストしている
- Acceptance Test
- Acceptance Criteriaをテストする
「真の学び」が未来を拓く～成長するエンジニアのマインドセット ～
古畑 慶次さん（生産経営研究所）
- 成長するエンジニアのマインド
- 気構え/意識 > 能力 > 行動
- 内省する
- 自分の心の声に耳を傾ける
- 自分がどうしたいか
- それはなぜか
- どうなったら納得できるか
- 目標と目的を言葉にする
- 自分の心の声に耳を傾ける
- 実践こそすべて
- 体系的な反復が能力を向上させる
- 情報を学びを通して知識にする
- 学びは反復練習
- 組織と人
- 人の成長<->いいサービス/製品
- 問題解決を通して人が成長しサービス/製品がよくなる
- 卓越性の追求
- 人にはできなくて自分にできること
- 問題解決と技術習得
- 行動を変容させる
- 学びは真似から
- 自分の常識を捨てて新しい考え方を受け入れること
- 自分で答えを見つける
- 社内の常識を疑って社外の常識に従う
- 学びは真似から
