QA組織が最後の砦から脱却するために

QA Tech Night vol.2の内容です。
https://qatechnight.connpass.com/event/200528/

Transcript

1. ©Akatsuki Inc. QA組織が最後の砦から
 脱却するために
 株式会社アカツキ福岡
 山﨑 友貴
 
 QA Tech Night vol.2 2021-01-28 

2. ©Akatsuki Inc. この資料で一番伝えたいこと
 最後の砦は響きは良いし
 すごくかっこいいけれど、
 それは、大きなリスクを伴うということ。
 
 
 QA組織が最後に、どんっ、と構えるだけなのはもったいない。 
 ｢最後｣という言葉にとらわれないために、QA組織は、 
 テスト対象が完成する前からテストしていく方が良いと考えます。 
 今日はエンジニアという立場で、 
 QA組織に所属している自分が思うことを率直に伝えられたら、と思います。 

3. ©Akatsuki Inc. 今日お話しすること、しないこと
 • QA組織の在り方について
 ◦ 概念的、抽象的な話
 • 開発現場でQA組織がぶつかる問題について 
 ◦ あるある事例紹介
 ◦ 問題の原因はどこにあるのだろうか？
 • QA組織が理想的な在り方に向かうための方法 
 ◦ QAの専門性やテスト自動化について
 • 具体的なノウハウや方法論
 ◦ こうすればテストはうまくいく！
 ◦ こうすれば自動化はうまくいく！

4. ©Akatsuki Inc. どの目線で話すか
 • ソーシャルゲームアプリケーション開発目線 
 ◦ 新規でゼロからリリースまでを開発するプロジェクトではなく、
 リリース後に運営を続けているプロジェクトの話がメインです
 ◦ 日々の運用における開発ではなく、バージョンアップのための新規開発がメインです
 ◦ 弊社は、開発チーム内にQAメンバーが在籍しています
 • QA組織に属するエンジニア目線 
 ◦ QA領域の自動化、効率化を行うエンジニアとして話します
 ◦ ゲーム開発経験は積んでいる前提はあり
 ◦ QA組織づくりにも力を入れています
 • クライアントテスト目線
 ◦ サーバ側で行うテストより、クライアント側のテストの話がメインです

5. ©Akatsuki Inc. 前提の話
 0

6. ©Akatsuki Inc. 自己紹介
 株式会社アカツキ福岡
 
 山﨑 友貴 tomotaka-yamasaki
 
 Job: Engineer
 JSTQB FL資格保有
 2015
 株式会社アカツキ エンジニア 新卒入社
 オリジナルタイトルのゲーム運営チーム
 クライアントエンジニア
 他社IPタイトルのゲーム運営チーム
 クライアントエンジニア
 2017
 他社IPタイトルのゲーム運営チーム
 クライアントエンジニアチームリーダー
 2019
 株式会社アカツキ福岡 出向
 テストの自動化や効率化のチーム立ち上げ
 現在
 各プロジェクトのテスト自動化、効率化に取り組みなが ら、QA組織づくりに従事

7. ©Akatsuki Inc. 1
 2
 3
 4
 本日のテーマ
 最後の砦とは一体なんだろうか？ 
 なぜ、最後の砦となってはいけないのか？ 
 
 最後の砦から脱却するために必要なこととは？ 
 まとめ

8. ©Akatsuki Inc. 前提の話
 アカツキとアカツキ福岡の関係について 
 アカツキ福岡は子会社ではあるが、同じプロジェクトのワンチームで動いている。 
 現在、全社リモートワークにより距離の壁がなくなっている。 
 0
 プロジェクトA アカツキ(東京) - 開発本体 アカツキ福岡 - QAチーム Zoomによる連携

9. ©Akatsuki Inc. 前提の話
 アカツキのプロジェクトチーム体制について 
 0
 プロジェクトチームに
 属しながら、
 横串で連携している
 プロジェクトA
 QA
 福岡
 開発
 QA
 東京
 プロジェクトB
 QA
 福岡
 開発
 QA
 東京
 …
 品質管理チーム(CAPS) 

10. ©Akatsuki Inc. 前提の話
 アカツキのプロジェクトチームとテスト自動化、業務効率化チームの関係 
 0
 プロジェクトA
 QA
 福岡
 開発
 QA
 東京
 プロジェクトB
 QA
 福岡
 開発
 QA
 東京
 …
 品質管理チーム(CAPS) 
 テスト自動化
 業務効率化
 チーム
 第三者視点で
 プロジェクトに介入

11. ©Akatsuki Inc. 前提の話
 アカツキの品質管理チーム、CAPSとは 
 ｢顧客とプロダクトの満足度最大化｣を追求する集団。 
 ゲーム開発の役割の1つである｢検証｣｢カスタマーサポート｣をメインで担当する。 
 0
 株式会社 アカツキ | CAPS - ゲーム業界未経験者の登竜門 

12. ©Akatsuki Inc. 前提の話
 CAPSが目指す6つの最大化とは 
 • 製品の満足度最大化(QA)
 • 最高の感動体験最大化(CX)
 • 面白さの満足度最大化(ゲームの面白さの追求) 
 • エンジニアリング貢献最大化(テスト自動化、効率化) 
 • 製品/チームの安全性への貢献最大化(リスクマネジメント) 
 • 人の幸福度と能力の最大化(組織づくり) 
 0

13. ©Akatsuki Inc. 前提の話
 CAPSが目指す6つの最大化とは 
 0
 • 製品の満足度最大化(QA)
 • 最高の感動体験最大化(CX)
 • 面白さの満足度最大化(ゲームの面白さの追求) 
 • エンジニアリング貢献最大化(テスト自動化、効率化) 
 • 製品/チームの安全性への貢献最大化(リスクマネジメント) 
 • 人の幸福度と能力の最大化(組織づくり) 
 本日お話しするのは
 ここの領域の
 あれこれです。

14. ©Akatsuki Inc. 本題に入ります

15. ©Akatsuki Inc. 最後の砦とは
 一体なんだろうか？
 1

16. ©Akatsuki Inc. 最後の砦とは一体なんだろうか？ 
 概要
 • QA組織は、最後の砦、と称されることが弊社内でもよくあります 
 • 便利な言葉なのでよく使われますが、 
 QA組織はそうあるべきではないと思っています 
 • ここからのお話
 ◦ 最後の砦とは一体なんだろうか？ 
 ◦ なぜ、最後の砦となってはいけないのか？ 
 ◦ 最後の砦から脱却するために必要なこととは？ 
 1

17. ©Akatsuki Inc. 最後の砦とは一体なんだろうか？ 
 最後の砦のイメージとは 
 1
 最終防衛ラインの
 私たちが頑張る！
 絶対に不具合出さない！
 QAメンバー
 かっこいい！頼む！
 君たちだけが頼りだ！
 QA組織以外の メンバー

18. ©Akatsuki Inc. 最後の砦とは一体なんだろうか？ 
 最後の砦のイメージを言語化してみる 
 ｢最後｣の｢砦｣
 1
 プロダクトのリリーススケジュール 
 における最後の工程 
 リリース前に不具合を 
 発見する役割

19. ©Akatsuki Inc. 最後の砦とは一体なんだろうか？ 
 ゲームアプリケーションのバージョンアップまでの流れ(一例) 
 1
 ディレクター
 機能仕様書
 完成
 エンジニア/
 デザイナー
 機能完成
 機能開発のライン
 feature
 freeze
 code
 freeze
 free
 debug
 v.X.x.x
 リリース！
 feature freeze: 機能追加のリミット
 code freeze: コード変更のリミット

20. ©Akatsuki Inc. 最後の砦とは一体なんだろうか？ 
 ゲームアプリケーションのバージョンアップまでの流れ(一例) 
 1
 ディレクター
 機能仕様書
 完成
 エンジニア/
 デザイナー
 機能完成
 機能開発のライン
 feature
 freeze
 code
 freeze
 free
 debug
 v.X.x.x
 リリース！
 この辺でテストをがっつり 
 行っている。最後の砦。 
 feature freeze: 機能追加のリミット
 code freeze: コード変更のリミット

21. ©Akatsuki Inc. なぜ、最後の砦と
 なってはいけないのか？
 2

22. ©Akatsuki Inc. なぜ、最後の砦となってはいけないのか？ 
 QAチームのテスト実行までの流れ 
 • 機能の仕様書を元に、エンジニアは実装を完了させる 
 • QAチームはその間、テスト設計、テスト実装を行う 
 ◦ 機能が完成しないと動作させながらテストを行うことができない 
 • 機能が完成したらQAチームはテスト実行を行う 
 ◦ リリースまでにクリティカルな不具合を修正していく 
 2

23. ©Akatsuki Inc. なぜ、最後の砦となってはいけないのか？ 
 最後の砦として機能しているフリーデバッグ 
 • フリーデバッグ
 ◦ 期間を設定し、探索的テストに近いテスト形式で行われている
 ◦ このテスト期間に重大な不具合が発見されることが稀にある
 2

24. ©Akatsuki Inc. なぜ、最後の砦となってはいけないのか？ 
 なぜ、最後の砦と言われるのか？ 
 最後の最後(フリーデバッグ)で重大な不具合を防ぐ。
 ファインプレー。
 その功績が讃えられ、
 QA組織は最後の砦、と呼ばれるようになりましたと、さ。
 2

25. ©Akatsuki Inc. なぜ、最後の砦となってはいけないのか？ 
 なぜ、最後の砦と言われるのか？ 
 めでたし、めでたし…？
 2

26. ©Akatsuki Inc. • QA組織としては、｢最後の砦｣は 褒め言葉ではない
 • 自分たちがミスったら終わり、という状況は 健全ではない
 • 最後の砦だと言われたら、悔しいと思いたい
 なぜ、最後の砦となってはいけないのか？ 
 最後の砦であることを誇りに思ってはいけない 
 2

27. ©Akatsuki Inc. なぜ、最後の砦となってはいけないのか？ 
 最後の砦という役割が引き起こす3つのこと 
 • 最後の砦でどーんと構えているため、機能が完全にできてからテストを始める 
 • ディレクター、エンジニア、デザイナーなどが引き起こすスケジュール遅延を 
 全てQAチームが背負うことになる 
 • 結果、自らもスケジュール遅延することになる、そして休日出勤 
 2
 テストの開始が遅延する

28. ©Akatsuki Inc. なぜ、最後の砦となってはいけないのか？ 
 最後の砦という役割が引き起こす3つのこと 
 • 絶対に遅らせることができないリリーススケジュールの 
 最後の最後で不具合を発見する 
 • プロジェクトメンバーはあらゆるステークホルダーとの調整を行うこととなる 
 • ユーザに予定通り機能が届けられなくなってしまう 
 2
 クリティカルな場面で
 リリースが遅延する

29. ©Akatsuki Inc. なぜ、最後の砦となってはいけないのか？ 
 最後の砦という役割が引き起こす3つのこと 
 • 最後の砦である彼らに任せればきっと不具合を見つけてくれる、 
 だからユニットテストは書かなくていいか、というエンジニアの慢心 
 • リリース後に不具合が発覚、過度な期待があるがゆえに 
 責任の所在をQAチームに求めてしまう 
 2
 QAチームへの
 過度な期待を生む

30. ©Akatsuki Inc. 最後の砦から脱却する
 ために必要なこととは？
 3

31. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 脱却するために考えたいこと 
 • テストはいつから始まっているのか？ 
 • 不具合の原因を考えるのは誰か？ 
 • 品質について考えるのは誰か？ 
 3

32. ©Akatsuki Inc. テストはいつから
 始まっているのか？

33. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 テストはいつから始まっているのか？ 
 テストの7原則 その3
 早期テストで時間とコストを節約
 
 
 • テスト対象が完成する前からテストは始まっている 
 • テスト工程は影響要素が多すぎるため、 
 テスト工数にいくらバッファを積んでもスケジュールを圧迫してしまう 
 • 全てをシフトレフトで考えていく必要がある
 3

34. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 テスト対象が完成する前からテストは始まっている 
 • 機能仕様書pre-fix段階でもテスト可能 
 ◦ 仕様の抜け漏れをチェックする 
 ◦ ゲームが面白くなるのかをチェックする、など 
 
 • コード設計レビュー、コードレビュー段階でもテスト可能 
 ◦ エンジニアの考慮漏れを指摘する 
 ◦ その機能のコードがマージされる前に動作チェックする、など 
 3
 機能仕様書
 pre-fix
 機能仕様書
 完成
 コード設計
 レビュー
 コード
 レビュー
 機能
 完成
 ※ 機能完成までを詳細化 

35. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 仕様書pre-fix、完成時点で行うテスト設計 
 マインドマップでテスト設計する
 
 • テスト観点の洗い出し
 ◦ マインドマップを用いて、テスト観点を
 洗い出す
 • テスト観点のレビュー
 ◦ QAチームだけではなく、機能の開発に
 関わる全てのメンバーがレビューする
 3
 JaSST2019東京 三銃⼠モデルを適応してみた！ -Next Generation 次世代の挑戦 より
36. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 コード設計レビュー時点で行うテスト設計 
 エンジニアのコード設計レビューにQAも参加する
 
 • エンジニアはコードを書き始める前に設計を行う 
 • エンジニア同士で設計が妥当かどうか、レビューを行う 
 • そのレビュー会にQAも参加する 
 ◦ リファクタリングの有無を認識する
 ◦ 仕様書から予測できない影響範囲を認識する
 ◦ エンジニアの考慮漏れを指摘する
 3

37. ©Akatsuki Inc. 不具合の原因を考えるのは誰か？

38. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 不具合の原因を考えるのは誰か？ 
 不具合の原因を決定づけるのは、
 エンジニアの役割だと思います。
 
 ただ、考えるのはエンジニアだけで良い？
 3

39. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 テスターとデバッガーの違い 
 3
 故障、不正を発見するのはテスター
 不具合を修正するのはデバッガー
 
 
 • テスターはテストを行い、故障、不正を検知する役割 
 • デバッガーは故障、不正を引き起こしている欠陥を見つけ、分析、修正する役割 

40. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 不具合の事象のみに焦点を当てたコミュニケーション 
 故障や不正が起こったときに、事象を報告するだけになるのはもったいない。 
 3
 不具合出てます。
 〇〇という状況でした。 
 QAメンバー
 クライアント
 エンジニア
 ありがとうございます。 
 修正します。
 あ、これは
 サーバ側の
 不具合だな。

41. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 不具合の原因にまで焦点を当てたコミュニケーション 
 大まかにでも良いので、QAチーム側で原因を探る。 
 3
 QAメンバー
 サーバ
 エンジニア
 確かこの処理は サーバで行われ ていたはず。
 不具合出てます。
 〇〇という状況でした。 
 ありがとうございます。 
 修正します。

42. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 不具合の原因はQAも考えた方が、きっと良い未来になる 
 QAも不具合の原因を考えたい。
 
 
 開発チームに属するQAは多くの情報を知ることができる。 
 従って、不具合を報告するだけではなく、 
 原因となる欠陥の仮説を立てて、 
 エンジニアとコミュニケーションしたい。 
 そのためにエンジニア的視点を持つことが非常に重要。
 3

43. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 エンジニア的視点とは？ 
 • アプリケーションの内側を理解する、ということ 
 ◦ システムの概要を理解する 
 ◦ データ構造を理解する 
 ◦ 通信タイミングを理解する 
 ◦ ハードウェアを理解する 
 ◦ ビルド方法を理解する 
 ◦ ソースコードを読み、複雑度を理解する、など 
 3

44. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 エンジニア的視点を持つことのメリット、デメリット 
 3
 • テスト精度が向上する 
 ◦ 欠陥の偏在を見つけることができる 
 ◦ エラー推測の精度が向上する 
 ◦ ソースコード変更の影響範囲が分かる 
 • エンジニアとより深い議論ができる 
 ◦ エンジニアの話す専門的な内容が理解できる 
 ◦ 不具合の修正方針を提案できる 
 ◦ ユニットテストに対して適切に突っ込める 
 • テスト業務を効率化できる 
 ◦ 自動化、効率化できる箇所を精査できる 
 メリット
 • 学習ハードル、コストが高い 
 ◦ エンジニアの技術的な知識を身につけるハードルが高い 
 ◦ 独学で1から学ぶにはコストが高い 
 • 内部構造を知りすぎてしまう 
 ◦ エンジニアの確証バイアスをQAでカバーできない 
 ◦ テストの抜け漏れが発生する 
 デメリット

45. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 エンジニア的視点重要、とは言っても… 
 テスターの域を超えているのでは？
 3

46. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 テスターの域を超えているのでは？ 
 そう、思います。
 3

47. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 QA組織のスペシャリティを強化する 
 • JSTQB、IVECをベースとしてQAの専門領域を整理 
 ◦ QAスペシャリスト、QAマネージャの2つの役割を定義 
 ◦ 専門性を高めるためのキャリアパスを設計 
 • 専門領域を理解するため、QAスペシャリスト勉強会を実施 
 ◦ JSTQBを軸に、チームの課題について3ヶ月間議論 
 3

48. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 QAのスペシャリティの定義を一言で 
 3
 QA
 スペシャリスト
 QA
 マネージャ
 QAスペシャリストはテクニカルな領域でチー ムをリードし、QAマネージャやエンジニアと連 携し、最高品質のプロダクトをユーザに提供 することを目指す。
 QAマネージャはテストチームの価値を全方 向に伝えるとともに、テストプロセス全体を最 適化し、最高品質のプロダクトをユーザに提 供することを目指す。 
 テストチームの成果に興味を持っている方はチーム内外にたくさんいる。その方々が求めていることをQAマネー ジャは理解し、的確な情報を提供する必要がある。
 そのコミュニケーション手段を取り続けることで、テストチームの価値を他のチームメンバーが認識することがで き、正当に評価されるようになる。
 QAマネージャはテストチーム以外の関係者と積極的にコミュニケーションを取りながら、テストプロセスの改善を 繰り返し、最高品質のプロダクトをユーザに提供することをチームで目指す。
 プロダクトのテスト分析、テスト設計、テスト実装、テクニカルな領域でのテスト実行を行う。
 また、同値分析法、デシジョンテーブルなどのテスト技法を熟知し、エンジニアリングの観点を持ちながら、テス トチームをリードする。
 更に、効率的な探索的テストを行うための仕組みづくりやエラー推測などでも力を発揮する。
 QAスペシャリストはエンジニアリングの知識を持ち、エンジニアと対等に議論することによって通常では見つか らない不具合の発見や、不具合を早期発見するためのテスト設計を行い、最高品質のプロダクトをユーザに提 供することをチームで目指す。

49. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 QAのスペシャリティの定義の概要 
 3

50. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 QAのスペシャリティの定義の一例 
 3

51. ©Akatsuki Inc. 品質について考えるのは誰か？

52. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 品質について考えるのは誰か？ 
 3
 品質は
 プロジェクトメンバー全員が
 考えるもの。
 
 • QA組織だけが品質を考えてはいけない 
 • ただし、｢品質に対して、誰が最終責任を持つか｣は決める必要がある 

53. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 開発エンジニアとQAの心理の違い 
 3
 • 主目的は、プロダクトを設計して構築すること 
 • 解決策の設計と構築により大きな関心があり、解決策に誤りがあるかには関心があまりない 
 開発エンジニア
 • 主目的は、プロダクトの検証と妥当性確認、リリース前の欠陥の検出 
 • 好奇心、プロとしての悲観的な考え、批判的な視点、細部まで見逃さない注意力、 
 良好で建設的なコミュニケーションと関係を保つモチベーションが必要 
 QA
 ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02”. JSTQB 認定テスト技術者資格. 2019-11-11., (アクセス日 2021-01-25). p.26
54. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 開発エンジニアも本気で品質について考える 
 開発エンジニアも品質について考え、
 QAチームに歩み寄らなければならない
 
 • 開発エンジニアとQAがお互いに持っているマインドの専門性を理解する 
 ◦ 不足している部分を補完し合う
 • プロダクト品質を向上させる、といった 共通の目的を軸に議論することが大切
 ◦ 同じチームに属している利点を活かす
 • エンジニア的視点、でQAに歩み寄ってもらうだけではアンフェア 
 3

55. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 開発エンジニアとQAの心理の違いとは何か？ 
 • Akatsuki Advent Calendar 2020 に参加
 • ｢QAが普段考えていること、思っていること、大切に していることを開発エンジニアにも知ってもらいた い｣、その一心で書いた記事
 • テストの7原則や、開発エンジニアとQAの心理の違い についてまとめている
 3
 開発エンジニアとQAの心理の違いとは何か？ - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.) 

56. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 エンジニア的な品質改善アプローチ 
 3
 エンジニアは
 テストを自動化することができる
 
 • 自動化することで不具合を早期発見することができる 
 ◦ シフトレフトに繋がる一手になり得る
 • テスト自動化はCEDEC2020でも多く見られる 
 ◦ 最近ホットなテーマ

57. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 テスト自動化は銀の弾丸ではない 
 • テストを自動化することで品質が上がるとは限らない 
 テストだけでは品質が上がらないのと同じである。 
 
 • テストを自動化することでQAのコストが下がるとは限らない 
 自動化システムをメンテナンスし続けなければならない。 
 
 • 全てのテストを自動化すべきではない 
 全てのテストには目的がある。 
 
 • テスト自動化システムは片手間では完成しない 
 強い推進力が必要である。 
 
 • リリース後のアプリケーションのテストを自動化するのは至難の業である 
 自動化できる設計になっていない場合がある。 
 3

58. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 結局、テスト自動化は良いのか悪いのか？ 
 3
 テストの目的を定めた上で、
 CIに組み込まれた自動化システムは
 不具合の早期発見に繋がる。

59. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 テスト自動化への取り組みについて 
 • インゲーム(バトル)リグレッションテストの自動化を第三者視点から試みている 
 ◦ 組合せ爆発への対処
 • 自動化の方法
 ◦ Script方式(操作をスクリプトで自動化)
 ◦ Record & Playback方式(手動プレイを記録、再現して自動化)
 ◦ AI方式(操作をAIで自動化)
 • ゲームの操作自動化の難点
 ◦ ランダム要素の固定問題
 ◦ ゲーム内演出とプレイ結果の分離問題
 3

60. ©Akatsuki Inc. 最後の砦から脱却するために必要なこととは？ 
 テスト自動化を考慮すべきタイミング 
 3
 テスト自動化は
 リリース前の開発時点から考慮すべき。
 
 これで、シフトレフトに大いに貢献できる。 

61. ©Akatsuki Inc. まとめ
 最後の砦とは？なぜ最後の砦ではだめなのか？ 
 • 最後の砦とは一体なんだろうか？ 
 ◦ プロダクトのリリーススケジュールにおける最後の工程で不具合を発見する役割
 
 • なぜ、最後の砦となってはいけないのか？ 
 ◦ テストの開始が遅延する
 ◦ クリティカルな場面でリリースが遅延する
 ◦ QAチームへの過度な期待を生む
 4

62. ©Akatsuki Inc. まとめ
 最後の砦から脱却するために考えたいこと 
 • テストはいつから始まっているのか？ 
 ◦ テスト対象が完成する前からテストは始まっている
 ◦ 全てをシフトレフトで考える
 • 不具合の原因を考えるのは誰か？ 
 ◦ エンジニア的視点を持ち、QAメンバーも不具合の原因を考える
 • 品質について考えるのは誰か？ 
 ◦ プロジェクトメンバー全員が品質について考える
 ◦ 開発エンジニアとQAはお互いに持っているマインドの専門性を理解し、議論する
 ◦ 開発エンジニアはテスト自動化という観点で品質を考える
 4

63. ©Akatsuki Inc. まとめ
 最後の砦から脱却するために取り組んでいること 
 • マインドマップレビューやコード設計レビューを利用し、テストを設計する 
 • QAのスペシャリティを定義し、エンジニア的視点やマネジメントを高める 
 • 開発チームの外側から、リグレッションテストの自動化に取り組んでいる 
 4

64. ©Akatsuki Inc. まとめ
 最後の砦からの脱却に必要なこと 
 4
 QA組織が最後の砦から脱却するために
 QAはエンジニア的視点、
 開発エンジニアはテスト自動化を考慮しながら
 シフトレフトを推進する。

65. ©Akatsuki Inc. まとめ
 最後の砦からの脱却に必要なこと 
 4
 最後の砦だけではなく、たくさんの砦を作ろう。

66. ©Akatsuki Inc.