3/9(木)、10(金)で行われたJaSSTソフトウェアテストシンポジウム-JaSST'23 Tokyoに参加してきました！
2日目に聴講したセッションと感想をざっくりまとめます。
- 「AIテスト自動化ツールの向かう先」
- 「シフトレフトの失敗事例から学ぶ次のアプローチ」
- 「テストウェアのデータモデル」
- 「特徴の異なる複数の自社プロダクトの品質への向き合い方を、ワイガヤします」
- 「本の品質はどのように作られるのか ～プロマネとして書籍編集者がしていること」
- 全体的な感想
「AIテスト自動化ツールの向かう先」
伊藤 望さん（MagicPod）
小田 祥平さん（mabl Inc.）
近澤 良さん（オーティファイ）
松木 晋祐さん（JaSST東京実行委員会）
テスト自動化の三世代
1. キャプチャリプレイ、画像認識
コードの自動生成による保守の煩雑さ、実行時の不安定性
2. UIオブジェクト（locator）、データ・キーワード駆動
依然として保守コストかかる。自動化に開発技術が必要になって人材難
3. AdutoDetect（locatorの半自動取得）、Self-healing
2の課題を解決。多量のテストレポートの仕分け、テスト実行時間の長大化
明日はどっちだ？
- 自動修復の深化（locatorだけでなくコマンドの提案）
- 「ChatGPT-Powerd」をうたう自動テストツールが登場する
- AIが作ったテストケースをどうレビューする？
- レビューするAが別で出てくる？（画像生成のAIだと生成するAIと、AIによる生成か判定するAIがあるらしい）
- 非機能系への進出
- mablだとアクセシビリティテストはすでに出ている
- Visual Regression
- チェックボックスがチェックされてるかを自動テストでチェックするのは地味に面倒
- サービスのドキュメントをAIに覚えさせてそこからテストシナリオ作ってもらう
- Autfyのヘルプページを学習させてテストシナリオ作ってもらったところ結構いいものを作ってきたらしい
- AIは細かく指示をするとそれに合わせて出力してくれる
- 人間が試されているｗ
- 翻訳みたいに、機械翻訳→おかしいところだけ人が直す、みたいな流れになるかも？
- 自動テストケース生成がくるか！？
- monitoringとtestingのオーバーラップ
- 本番環境でテストツール動かすとか
- datadogもE2Eテスト領域に参画している
- テスト自動化領域はまだパイの奪い合いをする段階じゃない
感想
未来の話を聞けてよかった～！ 人間はAIに分かりやすい指示を出して生成されたケースの選択とか修正だけするようになっていく未来になるのかなあとワクワクしながら聞いてました。discordでのありましたけど、これ毎年やってもらって定点観測したい！
「シフトレフトの失敗事例から学ぶ次のアプローチ」
高橋 信弘さん（AGEST）
シフトレフトできていますか？
シフトレフト：早いダニあkで欠陥を見つけるために静的テストと動的テストの両方を開発ライフサイクルのなるべく早い時期に開始すべき
シフトレフト導入施策
課題
大規模な現場
テスト観点が不明確
異なるテストを実施
テスト関連資料が多数
施策
- テストフェーズごとの観点整理を実施（成功）
- QAによる仕様レビュープロセスの導入（成功）
- 参考にされた論文
https://www.juse.or.jp/sqip/workshop/report/attachs/2011/SQiP3-1.pdf
- GQM法による品質特性ごとのメトリクス設定（失敗）
- 参考にされた論文
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア…
-
-
- 導入後のイメージの共有不足
- 対象範囲が広かった
- マネージメント層とリーダ層の齟齬（マネジメント層の承認が通らなかったため導入失敗）
-
よりよいシフトレフトを求めて
にしさんの資料
What should you shift left
- 従来も「目的」はたてて、「方法」も検討していたが、「共に考える」発想がなかった
- 開発者とのコミュニケーション
- 開発テストの最適化
- モブテストの導入
全員参加で品質を向上していく！
感想
実際の例を紹介いただけて面白かったです。discordでもGQM法に皆さん興味はあるけど使いにくさを感じてるんだなというのが分かりました。個人的にもゴールと問いの設定が難しいと感じてます。質問でもGQM法大人気でしたｗ
「テストウェアのデータモデル」
朱峰 錦司さん、鈴木 一裕さん
利用者側の目線
課題：解決策が見いだせない系
- テストケースの単位とグルーピング
- 一覧性の低下 → スプレッドシート側で解決できる？
- 保守性の低下 → データ駆動の機能サポートで解決できる？
- テストモデルとの相性
- 記法が定義されたモデル 専用ツールで生成したテストケースを管理ツール側に移すとトレーサビリティがおちる
- 記法が定義されてないモデル マトリクスで管理したいやつなど不便
課題：ベストプラクティス集めたい系
- テストケースの管理構造
- テスト実行のステータス
- 成功を期待できないケースが増えてくると事態が複雑化する（今期では直さないバグなど）
- 情報のトレーサビリティ
- トレーサビリティ情報をどう役立てるかはあまり語られない
- 自分たちにとって「どの情報に価値があるか」考えよう
提供者側の目線
テストケース管理の二大流派
- チケット型（TestRailとか）
- 基本的にツールの方で属性=フィールドを縛っている
- スプレッドシート型（Quality Forwardとか）
- 列の定義を自由にできる
※個人的には日本発のはスプレッドシート型が多いなーと思ってます
グルーピング
- お好きに（入れ子あり）フォルダ構造で
- 「テストスイート」という一段階の縛り
一覧性について
WebのUX/UIの世界
一覧の参照時に個々のケースまで見たいか？
テストモデルとのトレーサビリティ
前提：強いトレーサビリティは無理ゲー
弱いトレサビが無難と考えられる
管理構造の考察
観点とか目的でタグを絞り込む
感想
実行委員から「骨太」なセッションをしてくれとの要望で企画されたセッションだそうですが、マジで骨太でした！ テストケース管理ツールのタイプから課題、それに対するツール提供側がどう考えてるかを聞けてよかったです。
「特徴の異なる複数の自社プロダクトの品質への向き合い方を、ワイガヤします」
荒川 健太郎さん、伊藤 潤平さん、坂口 祐樹さん、山﨑 友藤さん、吉田 千鶴さん（ウイングアーク１ｓｔ）
QAのコミュニケーションを活性化する話
課題
- JIRAだけでチケットの管理を行おうとすると課題がある
- 時間がたつとサブタスク側で情報が更新されず、正しい情報がフィルタで出てこない
- チケット数が多くなるとJIRAフィルターだと一覧性が低くなってしまう
→MotionBoardに連携させて、親とサブチケット一覧で見られるようにしている
dejiren（チャット型iPaaS）のバーチャルアシスタントを介してboardの情報を得られる
チャットで情報が取れるのですぐコミュニケーションが取れる！
開発のプロセスで品質を作りこむ話
前提
開発が中でテストをして、QAが後からレビューする
課題
成果物に対するレビューを行うため、どうしても後からの指摘となってしまう
解決
テスト計画：全員に共有して常にだれもが見れる状態に
dejirenにアップしてinvoiceAgent（文書管理ツール）に接続
テストや業務の効率化の話
検証観点のテンプレート化
→新規で作成されるときにも半自動で反映できるように！
感想
自社プロダクト囲みながらわいわいやってるのが、チームの雰囲気がうかがえて良かったです。自社プロダクト使い込んでるのもいいなー。
「本の品質はどのように作られるのか ～プロマネとして書籍編集者がしていること」
傳 智之さん（技術評論社）
品質の高い本≒いい本
「ためになる×お金ぬなる」の最大化を目指す
1. 価値の源泉を探す
- 企画を決める
- 「作るべき品質」を決めるのは難しい
- ネタを探すな、人を探せ
- 方向性を共有する、ただし共有できたと思っても後から食い違いが起こることも
- 「はじめに」を最初にまとめて羅針盤／基点にする
- 小さく試せる場を作る（Webで連載してみる）
2. 時間とコストと向き合う
- 時間とともに品質は変わる 「一番乗り」は大事な品質になりうる
- 「いつ出せるか？」が不確実な場合も
- オンリーワンに賭ける
- 割り切ることで陳腐化を最小限に
- タイミングが来るまで待つ
- ゆとりを作るためにプロジェクト（企画）を増やす 利益の出る企画と利益的には微妙なチャレンジングな企画を組み合わせる
コンテンツを磨く
- 「引き出す」の限界 ないものは引き出せない
- 客観性wピ指揮したうえで主観を恐れず捉える
- 特徴を浮き彫りにする10の質問
- 理解のためにどこに注目すべきか
- どこから始めればいいか
- 最低限抑えるべきことは
- 覚えやすくするには
- やらないことは
- 何が厄介なのか
- それでどうよくなるのか
- なぜそうなっているのか
- ほかのやり方ではだめか
- トレードオフをどうするか
- 流れを意識して構成を考える
- ドラえもんメソッド
- 目次の演出を考える
- 「わかりやすい文章」の品質基準（ルール）を守る
- 欠陥をどこまで減らせるか
- 校正あるある 何やっても見逃すときは見逃す…
- 修正の落とし穴 修正すべきところの見逃しや修正自体の間違いを見逃す
- バイアスを意識してゆとりをつくる
- レビューをお願いするときの注意点 心理的安全性が保たれる方に依頼
魅力を伝える
- 品質が意味を成すまでのプロセスにかかわる
- タイトルの要件 読みたくなる、知ってもらいやすい
- なんのためのデザイン？
- 最適な版型を選ぶ （四六と呼ばれる版型は出版社によって大きさ違うらしい）
- ページごとの見せ方・情報量を決める
- 紙を選ぶ 本文用紙
- 全体最適となる価格を考える
- プロモーションを検討する
- 営業を支援する
価値を育てる
- アップデートで実績を延ばす
- 改定＋さらに変化を付けて売り伸ばしにつなげる
- 点を面に展開する 本格入門シリーズ
- 本ではないプロダクトへ
- 「なんでPC書じゃない本を作ってるの？」 PC書の棚では届かない読者および著者にリーチする
- 小さな挑戦、1つの出会いから「相互理解で広がる世界」へ
感想
本を作ることについて、ソフトウェアとの共通点や比較などを交えて話してくださってとても興味深かったです。本好きなのでこういうお話聞けるの楽しい！
JaSSTの翌日用事があって本屋に行ったのですが、タイトルのつけ方やレイアウト、カバーの紙などの観点が加わって、棚を見るのがいつもより楽しかったです。
全体的な感想
セッションはここに独立してますが、JaSST全体のテーマに沿って「あ、これ前聞いたセッションとつながるところあるな」という感覚がありました。discordでわいわいできる感じもあって一緒に見てる人とのライブ感も味わえてよかったです（来年はオフライン会場もあるとより嬉しい）
今年も楽しくてためになるJaSST Tokyoをありがとうございました！
