QAのマインドセットってなんなの？ - QAが知るべき97のこと -

JaSST nano vol.2の内容です。
https://jasst-nano.connpass.com/event/215889/

---

# QAが知るべき97のこと

1. 最後の砦にならない
2. Noといえることの大事さ
3. ドメイン知識無くして品質は上がらない
4. 第三者機関がテストしたほうが良いとは限らない
5. テストで品質は上がらない
6. テスト技法は組み合わせよう
7. テストの7原則
8. 外部失敗コストは最小に
9. 良いレビューが最高のプロダクトを生む
10. 品質は誰が考えるのか？
11. テスト対象ではなく｢人｣を見る
12. 論理的テストケースと具体的テストケース
13. テストケースを削る勇気
14. テストしないことを決める
15. テストケースは秘伝のタレにしない
16. 境界値を疑え
17. プログラムの変更を見逃さない
18. 故障の原因はQAも考えよう
19. デビュー作に注意
20. 欠陥は人の誤りである
21. バグという言葉の罠
22. 仕様書に書かれていることが全てではない
23. 当たり前品質と魅力的品質のバランス
24. 魅力的品質は限りなし
25. 守れない品質を言葉にする
26. デバッグではなくテストである
27. 全てのテストに目的あり
28. テストは依頼されるものではない
29. テストは何をどのようにどの順番で行うかが重要である
30. 業務には常に変化を与える
31. 仕様変更を見逃さない
32. テストスケジュールがずれないわけがない
33. 遅れを取り戻すために安易に人を増やさない
34. テスト自動化で品質は上がらない
35. なんでもかんでも自動化するな
36. テスト自動化は片手間ではできない
37. 開発初期から自動化を検討せよ
38. テスト自動化に夢を見るな
39. リファクタリングには最大限の理解と細心の注意を
40. コードの影響範囲を正しく知る
41. エンジニアのテスト範囲は知っておこう
42. プログラミング言語の基本構造を理解する
43. 条件分岐、繰り返しを予想する
44. リリース直前の修正は不具合を生む
45. システムの構造の大枠を理解する
46. ｢エンジニア｣を知る
47. 大事なことはPull Requestに書いてある
48. エンジニアの思考をテストする
49. テストチームの価値とモチベーション
50. 不可能な納期に一生懸命になってはいけない
51. プレッシャーに打ち勝つ
52. 不合理な高い期待には応えない
53. 開発メンバーの一人である自覚を持つ
54. テストは誰でもできるものではない
55. 確証バイアス
56. エンジニアを恐れないで
57. クリエイターの想いを理解する
58. QAは注目の的
59. クロスファンクショナルチームはデバッグが早い
60. HRT
61. テストチームもアジャイルする
62. 運用フェーズのテストプロセスを整備せよ
63. 開発ライフサイクルモデルを理解する
64. シフトレフトとシフトライト
65. 休日を当てにしない
66. QAは専門性の高い職種である
67. 自らの領域の外に出る
68. 人の目はそんなに優秀ではない
69. 人にしかできないテストをせよ
70. アウトプットは重要
71. 経験ではなく原理原則を理解する
72. テスト技法は練習あるのみ
73. QAの世界標準を知る
74. コミュニティに飛び込め
75. テストの奥深さは三角形で語れ
76. テストプロセスは改善し続けろ
77. モニタリングとコントロール
78. 振り返るまでがテストである
79. メトリクスで人を測ってはいけない
80. 抜け漏れを見つけるために図を書こう
81. 組み合わせの多さに爆発しない
82. 探索的テストはマネジメントしよう
83. 最善の技法を適用しよう
84. コードカバレッジ
85. 欠陥報告は分かりやすくシンプルに
86. 欠陥レポートは被ってもいい
87. リスクは排除ではなく全て洗い出す
88. テストツールを便利に使う
89. ツール導入は小さく始める
90. テストの終了定義を怠らない
91. テストプロセスの守破離
92. 欠陥はフェーズ内で阻止せよ
93. 静と動を使いこなす
94. 機能テストと非機能テスト
95. 品質特性はトレードオフ
96. パフォーマンステストはさっさとやる
97. 根本原因を追求しよう

(発表当時のものです)

Transcript

1. QAのマインドセットってなんなの？ QAが知るべき97のこと とも@tomo_tk11 JaSST nano vol.2 2021-07-20 Tue.
2. 2 はじめに伝えたいこと
3. 3 はじめに伝えたいこと メモ取らなくていいですよ！ あとで資料アップロードして Twitter(@tomo_tk11)で公開します！ No notes needed.
4. 4 お話しすること
5. 5 お話しすること 心に刻みたいことを話したいと思ってます。 QAが大切にしたいと 思っていること
6. 6 お話ししないこと
7. 7 お話ししないこと 手に持つ武器の話はまたの機会に。 具体的なQAの実践方法
8. 8 自己紹介 0
9. 自己紹介 とも @tomo_tk11 Job: Engineer JSTQB AL TA資格保有 エンジニアとQAの両軸から色々やってます お酒好きだけど禁酒5ヶ月目 9 2015
 ソーシャルゲーム開発会社 エンジニア 新卒入社 オリジナルタイトルのゲーム運営チーム クライアントエンジニア 他社IPタイトルのゲーム運営チーム クライアントエンジニア 2017
 他社IPタイトルのゲーム運営チーム クライアントエンジニアチームリーダー 2019
 テストの自動化や効率化のチーム立ち上げ 現在
 各プロジェクトのテスト自動化、効率化に取り組みながら、 QA組織づくりに従事
10. 10 QAのマインドセットとは？ 0.1.0
11. 11 マインドセットとは 無意識の思い込み、成果を出すための｢心構え｣ マインドセット Weblio辞書 ｢マインドセット｣より , https://www.weblio.jp/content/マインドセット
12. 心得ってことね。了解。 12
13. 13 QAのマインドセットとは？
14. 14 QAのマインドセットとは 心得ってことね。了解。 QA QA、と言っても たくさんある の マインド セット • ソフトウェア • ハードウェア • Web • ゲーム • 自動車
15. ひと括りに、 QAのマインドセットはこれだ！ とは、とても言えない。 15
16. でもいろんなQAの方に 何かひとつでも持ち帰ってほしい。 16
17. なので、考えました。 17
18. 97 という数字に見覚えはありますか？ 18
19. 19 ◦◦が知るべき97のこと
20. 20 97 Things Every Quality Assurance Should Know QAが 知るべき97のこと
21. 今回は考えた中から、 言いたくて言いたくてたまらないものを 紹介していきたいと思います。 21
22. えっ？ 22
23. 紹介するやつだけ 考えたんじゃないの？ 23
24. いやいや、 ガチで考えました。 24
25. 25 97 Things Every Quality Assurance Should Know QAが 知るべき97のこと 1. 最後の砦にならない 2. Noといえることの大事さ 3. ドメイン知識無くして品質は上がらない 4. 第三者機関がテストしたほうが良いとは限らない 5. テストで品質は上がらない 6. テスト技法は組み合わせよう 7. テストの7原則 8. 外部失敗コストは 最小に 9. 良いレビューが最高のプロダクトを生む 10. 品質は誰が考えるのか？ 11. テスト対象ではなく｢人｣を見る 12. 論理的テストケースと具体的テストケース 13. テストケースを削る勇気 14. テストしないことを決める 15. テストケースは秘伝 のタレにしない 16. 境界値を疑え 17. プログラムの変更を見逃さない 18. 故障の原因はQAも考えよう 19. デビュー作に注意 20. 欠陥は人の誤りである 21. バグという言葉の罠 22. 仕様書に書かれていることが全てではない 23. 当たり前品質と魅力 的品質のバランス 24. 魅力的品質は限りなし 25. 守れない品質を言葉にする 26. デバッグではなくテストである 27. 全てのテストに目的あり 28. テストは依頼されるものではない 29. テストは何をどのようにどの順番で行うかが重要である 30. 業務 には常に変化を与える 31. 仕様変更を見逃さない 32. テストスケジュールがずれないわけがない 33. 遅れを取り戻すために安易に人を増やさない 34. テスト自動化で品質は上がらない 35. なんでもかんでも自動化するな 36. テスト自動化は片手間では できない 37. 開発初期から自動化を検討せよ 38. テスト自動化に夢を見るな 39. リファクタリングには最大限の理解と細心の注意を 40. コードの影響範囲を正しく知る 41. エンジニアのテスト範囲は知っておこう 42. プログラミング言語の基本構造を 理解する 43. 条件分岐、繰り返しを予想する 44. リリース直前の修正は不具合を生む 45. システムの構造の大枠を理解する 46. ｢エンジニア｣を知る 47. 大事なことはPull Requestに書いてある 48. エンジニアの思考をテストする 49. テストチームの価値とモチベーション 50. 不可能な納期に一生懸命になってはいけない 51. プレッシャーに打ち勝つ 52. 不合理な高い期待には応えない 53. 開発メンバーの一人である自覚を持つ 54. テストは誰でもできるものではない 55. 確証バ イアス 56. エンジニアを恐れないで 57. クリエイターの想いを理解する 58. QAは注目の的 59. クロスファンクショナルチームはデバッグが早い 60. HRT 61. テストチームもアジャイルする 62. 運用フェーズのテストプロセスを整備せよ 63. 開発 ライフサイクルモデルを理解する 64. シフトレフトとシフトライト 65. 休日を当てにしない 66. QAは専門性の高い職種である 67. 自らの領域の外に出る 68. 人の目はそんなに優秀ではない 69. 人にしかできないテストをせよ 70. アウトプットは重 要 71. 経験ではなく原理原則を理解する 72. テスト技法は練習あるのみ 73. QAの世界標準を知る 74. コミュニティに飛び込め 75. テストの奥深さは三角形で語れ 76. テストプロセスは改善し続けろ 77. モニタリングとコントロール 78. 振り返る までがテストである 79. メトリクスで人を測ってはいけない 80. 抜け漏れを見つけるために図を書こう 81. 組み合わせの多さに爆発しない 82. 探索的テストはマネジメントしよう 83. 最善の技法を適用しよう 84. コードカバレッジ 85. 欠陥報告は分 かりやすくシンプルに 86. 欠陥レポートは被ってもいい 87. リスクは排除ではなく全て洗い出す 88. テストツールを便利に使う 89. ツール導入は小さく始める 90. テストの終了定義を怠らない 91. テストプロセスの守破離 92. 欠陥はフェーズ内で阻 止せよ 93. 静と動を使いこなす 94. 機能テストと非機能テスト 95. 品質特性はトレードオフ 96. パフォーマンステストはさっさとやる 97. 根本原因を追求しよう
26. 全97個、 スライドの説明欄に記載しています。 26
27. 27 97 Things Every Quality Assurance Should Know QAが 知るべき97のこと
28. 28 それでは6個くらい 紹介していきます。
29. 29 Noといえることの大事さ 2.
30. 30 • どちらにしても迫られた場面でNoといえないと取り返しがつかないことになる • なんでもかんでもNoだと敵対関係を生む ◦ 別に対立構造を生みたいわけではない ◦ Noという相手は一緒に作ってるメンバーである • いいもの作りたいという意思は同じなので、Noといわなくても良いようにしたい 2. Noといえることの大事さ Noといえないのか、Noといいたくないのか、は全然違う
31. 31 デビュー作に注意 19.
32. 32 19. デビュー作に注意 • 何事もはじめが肝心である • 過去やったことがあるものと比較すると、全く新しいものは未知の領域が多すぎる • まずは、前例がないことを検知する • 検知した上で、いつも通りにならないテストをしよう • ｢やったことないですよね？｣って言うの大事 ｢前例のないもの｣であることを検知する
33. 33 ｢エンジニア｣を知る 46.
34. 34 46. ｢エンジニア｣を知る • 実際に動作するテスト対象を作っている人のことを知ろう • ｢なんか小難しいこと言ってんなぁ｣で避けちゃいけない • エンジニアも人、人である以上、特徴、癖、性格はある • 人の観点から、エラー推測、欠陥の偏在を探ることだってできる • まずはエンジニアと気軽に話をしてみよう エンジニアも人なので十人十色
35. 35 プレッシャーに打ち勝つ 51.
36. 36 51. プレッシャーに打ち勝つ • QA組織は常にプレッシャーと戦っている ◦ 一つのミスが致命傷になることへの恐怖、納期の遅れ、本番不具合の責任問題 • プレッシャーからの焦りでテストしてはいけない • プレッシャーがかかる立場であると認識した上でそれを力に変えられるようになろう • でも過度な期待や責任以上のプレッシャーには振り回されないように プレッシャーは、正直ある！仕方ない！
37. 37 QAは専門性の高い職種である 66.
38. 38 66. QAは専門性の高い職種である • QAとしてのテクニカルスキルはもちろん必要 • プラス、他にも持ち合わせないといけないスキルはたくさんある ◦ コミュニケーションスキル、プログラミングスキル、ドメイン知識、マネジメントスキル • QAを学ぶということは、想像よりも遥かに大変なこと • その分、周りを理解して歩み寄れるポジション、他のキャリアを切り拓くチャンス • QAを極める難易度も高いので、そこにやりがいもある QAを学ぶということは、周りも理解することである
39. 39 静と動を使いこなす 93.
40. 40 93. 静と動を使いこなす • 静的テストできていますか？ものができあがってからテストしていませんか？ • どちらか片方だけではテストの真の効果を発揮することができない • 静的テストでは、欠陥そのものを早期発見できる • 動的テストでは、よきせぬ故障を振る舞いの中から見つけることができる • 両方の違いを理解した上で、適用しよう 静的テストと動的テスト、使い分けよう
41. 41 まとめ 0.2.0
42. 42 まとめ 2. Noといえることの大事さ Noといえないのか、 Noといいたくないのか、 は全然違う 19. デビュー作に注意 ｢前例のないもの｣である ことを検知する 46. ｢エンジニア｣を知る エンジニアも人なので 十人十色 51. プレッシャーに打ち勝つ プレッシャーは、 正直ある！仕方ない！ 66. QAは専門性の高い職種である QAを学ぶということは、 周りも理解することである 93. 静と動を使いこなす 静的テストと動的テスト、 使い分けよう
43. 43 97 Things Every Quality Assurance Should Know QAが 知るべき97のこと 1. 最後の砦にならない 2. Noといえることの大事さ 3. ドメイン知識無くして品質は上がらない 4. 第三者機関がテストしたほうが良いとは限らない 5. テストで品質は上がらない 6. テスト技法は組み合わせよう 7. テストの7原則 8. 外部失敗コストは 最小に 9. 良いレビューが最高のプロダクトを生む 10. 品質は誰が考えるのか？ 11. テスト対象ではなく｢人｣を見る 12. 論理的テストケースと具体的テストケース 13. テストケースを削る勇気 14. テストしないことを決める 15. テストケースは秘伝 のタレにしない 16. 境界値を疑え 17. プログラムの変更を見逃さない 18. 故障の原因はQAも考えよう 19. デビュー作に注意 20. 欠陥は人の誤りである 21. バグという言葉の罠 22. 仕様書に書かれていることが全てではない 23. 当たり前品質と魅力 的品質のバランス 24. 魅力的品質は限りなし 25. 守れない品質を言葉にする 26. デバッグではなくテストである 27. 全てのテストに目的あり 28. テストは依頼されるものではない 29. テストは何をどのようにどの順番で行うかが重要である 30. 業務 には常に変化を与える 31. 仕様変更を見逃さない 32. テストスケジュールがずれないわけがない 33. 遅れを取り戻すために安易に人を増やさない 34. テスト自動化で品質は上がらない 35. なんでもかんでも自動化するな 36. テスト自動化は片手間では できない 37. 開発初期から自動化を検討せよ 38. テスト自動化に夢を見るな 39. リファクタリングには最大限の理解と細心の注意を 40. コードの影響範囲を正しく知る 41. エンジニアのテスト範囲は知っておこう 42. プログラミング言語の基本構造を 理解する 43. 条件分岐、繰り返しを予想する 44. リリース直前の修正は不具合を生む 45. システムの構造の大枠を理解する 46. ｢エンジニア｣を知る 47. 大事なことはPull Requestに書いてある 48. エンジニアの思考をテストする 49. テストチームの価値とモチベーション 50. 不可能な納期に一生懸命になってはいけない 51. プレッシャーに打ち勝つ 52. 不合理な高い期待には応えない 53. 開発メンバーの一人である自覚を持つ 54. テストは誰でもできるものではない 55. 確証バ イアス 56. エンジニアを恐れないで 57. クリエイターの想いを理解する 58. QAは注目の的 59. クロスファンクショナルチームはデバッグが早い 60. HRT 61. テストチームもアジャイルする 62. 運用フェーズのテストプロセスを整備せよ 63. 開発 ライフサイクルモデルを理解する 64. シフトレフトとシフトライト 65. 休日を当てにしない 66. QAは専門性の高い職種である 67. 自らの領域の外に出る 68. 人の目はそんなに優秀ではない 69. 人にしかできないテストをせよ 70. アウトプットは重 要 71. 経験ではなく原理原則を理解する 72. テスト技法は練習あるのみ 73. QAの世界標準を知る 74. コミュニティに飛び込め 75. テストの奥深さは三角形で語れ 76. テストプロセスは改善し続けろ 77. モニタリングとコントロール 78. 振り返る までがテストである 79. メトリクスで人を測ってはいけない 80. 抜け漏れを見つけるために図を書こう 81. 組み合わせの多さに爆発しない 82. 探索的テストはマネジメントしよう 83. 最善の技法を適用しよう 84. コードカバレッジ 85. 欠陥報告は分 かりやすくシンプルに 86. 欠陥レポートは被ってもいい 87. リスクは排除ではなく全て洗い出す 88. テストツールを便利に使う 89. ツール導入は小さく始める 90. テストの終了定義を怠らない 91. テストプロセスの守破離 92. 欠陥はフェーズ内で阻 止せよ 93. 静と動を使いこなす 94. 機能テストと非機能テスト 95. 品質特性はトレードオフ 96. パフォーマンステストはさっさとやる 97. 根本原因を追求しよう
44. まだまだQA業界入りたてですし、 ソフトウェアのゲーム開発者の目線感が強いので 間違ってたり、ずれてたりするかもしれません。 日々学び続ける過程でもちろんアップデートもすると思います。 組織に浸透もさせていきたいですし、 ひとつひとつ丁寧に掘り下げていきたいとも思っています。 今日の発表で、なにかひとつでもみなさんの心に刻まれていれば嬉しいです。 44
45. 45 • ISTQBテスト技術者資格制度 Foundation Level シラバス • ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストマネージャ • ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト • ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テクニカルテストアナリスト • ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応 • 知識ゼロから学ぶソフトウェアテスト【改訂版】 • プログラマが知るべき97のこと 参考文献