セミナーメモ（TOKYO TEST FEST2024）

このページは何？

2024年11月15日に行われたQAセミナーについて書いたメモです。
トピックや内容、それを受けての所感などを徒然なるままに書いていきます。
本記事では一部の講演のみ抜粋して内容や感想を書きます。
講演の全容は以下URLをご参照ください
https://tokyotestfest.com/

どんなセミナー？

タイトルは「TOKYO TEST FEST」
JTC（Japan Test Community）が主催するQAやソフトウェアテストのカンファレンスです。
おそらく今年が初の開催？
このJTCは英語話者のQAエンジニアが多くおり、今回のカンファレンスも体感7割くらいが
外国籍の方のように見受けられました。
当然講演も英語ですが、同時通訳がついています。

CI/CDの未来：Testing.next – 川口耕介 様

• AIが書いたことを人間がテストする未来
• コードは書きやすくなっているが、テストに渋滞が起こってしまう
  • 解決策：テストを各フェーズに広げる（シフトレフト、シフトライト）
  • ドイツでは実際に本番環境のデータを分析してトラフィックのテストをするプロダクトもあるらしい。究極のシフトライト！
• 火が小さければすぐ消せる＝早く見つけること（observability）が重要
  • Elimitante Liskからmanage Liskへ
• 数日ダウンする金融システムと、ほとんどダウンしないGoogle、もはや障害に対する考え方が違う
• リリースサイクル＆フローの複雑化により、テスト工数が肥大化し、並列化に莫大なコストがかかるようになる
• 依存関係を明確にすることで、テストすべき範囲を明確にする
• コードも増え、テストも増え、テストによるFeedbackが増える→sustainableでない
  • AIを用いたトリアージを行う
  • バグが起きた時の調査をAIに任せる→起きるようになったビルドなど

モダンQAエンジニアのセキュリティテスト – Gloria Chow (グロリア・チョウ)　様

• DevSecOpsという考え方
• サイバー攻撃の増加
  • 去年より30％増
  • アプリケーションレイヤーへの攻撃は去年より86％増
• QA:engineer=1:4~5
• Security:enginner=1:100
  • しかしながらdevopsにおいて、QAとsecurity testingの位置付けは変わらない
• QAがsecurity testerになるためには？
  • Mindset
    • Think like an attacker（攻撃者のように考える）
    • Ask yourself what can go wrong（意訳：どこが壊れそうかを考える）
  • テストケース作成時は以下に注目
    • Authentification
    • Authorization
    • Data validation
    • Error handling
    • Business logic
  • たくさん勉強する→ISTQBにもSecurity tests certificationがある
  • プラクティスが完璧にする
  • 今の会社で機会を探す

最大限の品質を最小限のテスターで – Martijn Goossens (マルティン)　様

• QAボトルネックになりがち
• スクラムは大体9人くらい
  • そのうちQAは1人…というのは正しくない
• Holistic Quality Mindset
  • その組織における「品質とは何か？」を理解する
• 負荷の山をならす＝シフトレフト・シフトライト
• シフトレフト・シフトライトの実現のためには？
  • 仲間の輪を広げる（エンジニアやPOなど）
  • 自動化の仲間も同様
  • その仲間の中にはAIも含まれる
    • AIにUnitTestを書かせる
• Shift leftに最重要なこと
  • 要求分析
  • テスト計画
  • UT
• Shift right に必要なこと
  • 壊れても安全なこと
    • カナリアリリース
  • デバッグしやすいこと
    • Feature Flag
  • 学習しやすいこと(インサイトを獲得しやすいこと？）
    • A/Bテスト
    • ユーザーフィードバック
• 「Qualityを外側へ」一人じゃできないから仲間を集める

受け入れ条件で品質をブーストする – 福田里奈　様

• 受け入れ条件があることのメリット
  • PM：何が満たされていて、満たされていないかを早く理解できる
  • エンジニア：開発をスムーズにする
  • デザイナー：聞き漏らした
  • QA：無駄を省く
• 受け入れ条件を設定するための3要素
  • 1:テストケースと受け入れ条件を組み合わせる（テストケースを受け入れ条件に置き換えちゃう？）
  • 2:同期レビュー
  • 3:↑への全チーム参加
• テストケースをQAだけでなくみんなのものにする
• 効果的なレビューのための3step
  • 　（ドキュメントを）よむ
  • 　尋ねる
  • 　チェックする
• 　レビューにかける時間
  • 　1sprint1wとして、1h

大規模言語モデルの評価とアプリケーションの品質確保 – Galina Naydenova (ガリーナ・ナイデノワ) 様

• LLMが複雑化している今、正確性以上の品質が求められる
  • 流暢性とかニュアンスとかスピードとか
• 同じインプットでも同じアウトプットとは限らない
• みんなどうやってLLMを評価してるの？（以下高い順）
  • 1:人間のレビュー
  • 2:ツールやメトリクス
  • 3:ユーザーからのデータ収集
  • 4:LLM評価のためのLLM
  • 5:外部ソフト
  • 6:アカデミックベンチマーク
• LLMにおける「クオリティとは何か」 の定義が一番難しい

良いから素晴らしいへ: 品質コンサルタントとして役割を進化させる – Udit GATTANI(ウディット・ガッタニ) 様

• 誤ったテストピラミッド
  • icecorn（アイスのコーン型）
  • Hourglass（砂時計型）
  • Umbrella （傘型）
  • →ミドルレイヤー、ボトムレイヤーへのフォーカスが必要。各レイヤーで自動化をしていく
• QAコンサルになるためにの役割と必要なスキル
  • やるべきこと
    • スキルの多様化
    • テストピラミッドの構築
    • シフトレフト
    • パイプライン統合
    • ソフトスキル
  • やるべきでないこと
    • 部分最適を求める
    • 手動テストへの過度な依存
    • 一貫性のないフレームワーク

E2Eテスト自動化の健全性を定量化する– 伊藤望　様

自動テストの健全性をどう定量化するか

• コスト削減？→NO
• バグ検出？→NO
• DORAメトリクス？→NO
• ビジネススコア？→NO
  • 答えは「中止なくサービス（=magicpod）を継続してくれるか」
• magicpodのヘルススコアの計算ロジック
  • MAX100Pt
    • 少なくとも１日１回回ってるか　35
    • テストが成功しているか　　　　35
    • テストがメンテ可能か　　　　　20
    • その他　　　　　　　　　　　　10
  • 詳細（の一部）
    • テストケース数
      • 20個以上作ってるとfull pt
    • テストケース作成に関わった人数？
      • 4人以上が使ってると full pt
    • 共通ステップの割合
      • 全テストの10-20%だと full pt
    • Long Testの割合
      • Long testが10％以下ならfull pt
        • 200-300step だとlong test
    • stable locatersの割合
      • 80%以上でstable locatersを使っていれば full pt
    • テストの頻度
      • 平均4.2日/週以上テストを回してればfull pt
• ヘルスコアを測れるようにしたことで、継続率が上がった
• エンジニアの助けなしでE2Eテスト自動化はなしえない
  • CIへの統合とか

量子物理学とソフトウェアテストのパラレルワールド – Baris Sarialioglu (バリス)　様

• 【大前提】難しすぎてあまり理解できませんでしたw
• 量子物理学とソフトウェアテストの共通点
  • その1
    • 量子物理学：相反する二つの状態が同時に成立する（寝てる状態と起きてる状態など）シュレディンガーの猫的な。
    • ソフトウェアテスト：やってみるまで品質の良し悪しはわからない。計測することでどんな状態かがわかる
  • その2
    • 量子物理学：量子が関連しあってる。1つの量子の状態が変わると他の量子も影響を受ける
    • ソフトウェアテスト：1つのバグが見つかると、他のバグも芋づる式に見つかる。発生箇所を超えて。
  • その3
    • 量子物理学：量子トンネル効果。あるものがあるものを手助けする効果。
    • ソフトウェアテスト：バグが色んなテストプロセスをすり抜けて本番に出る（何かがバグがすり抜けることを手助けしている）
  • その4
    • 量子物理学：ハイゼンベルグの不確定性。量子の場所と運動量が、これらが両方同時にわかることはない
    • ソフトウェアテスト：意図せず起きたバグは、意図して起こそうと思うと全然再現しなくなる。いわゆるハイゼンバグはこの「ハイゼンベルグの不確定性」に由来する言葉らしい
  • その5
    • 量子物理学：量子がある特性をとった時にノイズや電磁波などを発する
    • ソフトウェアテスト：STGでは問題なかったのに、本番に行くと起きる

所感雑感

• シフトライト寄りの考え方が頻繁に聞こえた印象
  • バグをなくすのではなく、バグをマネジメントする
• AIの話題も当然出てきたが、QAへの具体的な活用事例はまだ少ない印象
  • どちらかというと、「エンジニアが楽になるよね。だからQAは大変になるよね」な感じ
  • そういうような状況も、シフトレフト・ライトがトレンドになることに寄与していそう
• 上流→CI/CD パイプラインの構築、Automation(Test Pylamidの実現)
• 下流→risk management（detect early / solve early /カナリアリリース） 、feedback loopの実現
• 登壇者に発表を促すフレーズ　”The stage is yours”
• 日本のLTとは少し違うテーマで面白かった。
  • 量子物理学とテストの共通点なんて、この場じゃないと聞く機会がないと思うw
• PJでやってみようと思ったこと
  • テストピラミッドの構築（エンジニアさんに協力を仰ぐ）
  • シフトライトのための提案（FeatureFlagの改善）
  • うちのプロダクトの品質って何？をみんなで考えてみる