「品質のつくりこみ」と「リリース後に行うとよいテスト活動」を体験する

Transcript

1. #ques25 Ques25 「品質の つくりこみ」と 「リリース後に 行うと よい テスト活動」を 体験する @nihonbuson @caori_t
2. 自己紹介 • 風間裕也（ブロッコリー） • 株式会社10X 品質管理チーム • 副業：B-Testing（個人事業主）として ◦ 株式会社MonotaRO （テストコンサルタント） ◦ 他数社でお手伝い • 社外活動 ◦ JaSST Review（ソフトウェアレビューシンポジウム） 実行委員長 ◦ WACATE（テストの合宿型ワークショップ形式勉強会） 実行委員長 ◦ SReEE（ソフトウェアレビューを エンジニアリングっぽく捉える会）リーダー SNS上の アイコン Whisk で作成
3. #ques25 自己紹介 • 常盤香央里（ゆるぱし・かおりっと ） • @caori_t • 所属 ◦ Graat（グロース・アーキテクチャ＆チームス株式会社） ◦ 執行役員、ワークショップデザイナー • 社外活動 ◦ WACATE実行委員 （ソフトウェアテストの合宿形式勉強会コミュニティ） ◦ SigSQAメンバー（これからの品質保証を考える） • ワークショップデザインが趣味
4. #ques25 Quesは3回目（2回目）の登壇
5. #ques25 本日のテーマ 講演テーマ：「品質の つくりこみ」と 「リリース後に 行うと よい テスト活動」を 体験する 「シフトレフト」と 「シフトライト」を 短時間で 体験する ワーク ショップを 行います。 従来の テスト活動や 品質保証活動の タイミングを 前倒し・ 先送りする だけではなく、 本質的に 「不具合の 予防」や 「品質の つくりこみ」を 行ったり、 リリース後まで 見通して 戦略的に テスト活動を 組み込んで いく 流れを 体験いただきます。 ワークショップでの 体験を、 普段の テスト活動や、 これから 学ぶテスト技術の ヒントに していただけたら 嬉しいです！
6. #ques25 タイムテーブル 時間 内容 18:30〜 受付開始 19:00〜19:05 オープニング 19:05〜19:50 ワークショップ（前半） 19:50〜20:00 休憩 20:00〜20:45 ワークショップ（後半） 20:45～20:55 Techouse様お知らせ 20:55～21:00 アンケート回答、クロージング 21:05～21:45 懇親会
7. #ques25 #ques25 チェックイン
8. #ques25 チェックインワーク Youは何しにQues25へ？ というテーマでグループで話してみましょう • 自己紹介を交えつつどうぞ！
9. #ques25 #ques25 Testing in DevOpsの図 の簡単な解説
10. #ques25 https://www.linkedin.com/pulse/continuous-testing-devops-dan-ashby/ より引用
11. #ques25
12. #ques25
13. #ques25 • 今回どのような価値を提供しようとするのか考える • お客様に提供するまでの計画を考える PLAN
14. #ques25
15. #ques25 • 価値を提供するために必要なタスクを分解する • タスク分解した内容に対する設計を行う BRANCH
16. #ques25
17. #ques25 • 機能開発のコードを実装する CODE
18. #ques25
19. #ques25 • 機能開発した複数のコードをマージする MERGE
20. #ques25
21. #ques25 • マージしたコードを用いてテスト環境にデプロイする BUILD
22. #ques25
23. #ques25 • 開発したコードを本番環境へリリースする RELEASE
24. #ques25
25. #ques25 • リリースした内容を環境に適用し、機能を反映させる DEPLOY
26. #ques25
27. #ques25 • 機能が反映された状態で、運用が回るか確認する OPERATE
28. #ques25
29. #ques25 • 機能が反映された状態で、 監視している測定値の変化を確認する MONITOR
30. #ques25 #ques25 ワーク
31. #ques25 お題 • パッキング画面で 特定の 操作を する ときに ダイアログ を 表示したい • 大幅なリアーキテクチャに よる ロジックの 入れ替えを 開発する ことになった • PBIに 「◦◦メソッドが 注文の 締切時間前に 呼ばれてい るので 対応する」と 書かれていた
32. #ques25 お題（配布用） • PBI① 「◦◦メソッドが 注文の 締切時間前に 呼ばれているので 対応する」と 書かれていた ◦ 「対応するって 何するの？」 「なんで 注文の 締切時間前に 呼ばれるのが よくないの？」と 質問した ら、今回満た すべき点 が 2つある ことが 分かったので、それぞれで対応策を考えた ◦ 満たすべき点の1つは設計の考慮漏れだったため設計に追記し、対応内容についてテスト駆動開発を用いて実装した ◦ 対応内容がアプリ上でも動作することを確認し、実際にリリースし、適切に動くことを確認した • PBI②パッキング画面で 特定の 操作を する ときに ダイアログを 表示したい ◦ ダイアログ表示が 頻発すると 業務の 妨げに なるのではないか？ と気になったので確認した ◦ 全ユーザーにデプロイすると問い合わせが沢山来る可能性があるので、一部ユーザーにデプロイした ◦ テスト駆動開発をして仕込むログの内容を実装し、リリースした ◦ ダイアログ表示の 頻度が 想定よりも 少ない ことが 確認できたので、ダイアログ表示の 修正を 入れる ことを 決断した ◦ テスト駆動開発をしてダイアログ表示の修正を実装し、リリースした ◦ ダイアログ表示が、どれぐらいの 頻度で 呼び出されているのか把握できていないことが分かったので、修正を 入れる 前に、 その 部分に ログを 仕込むことに した • PBI③大幅なリアーキテクチャに よる ロジックの 入れ替えを 開発する ◦ 既存の ロジックを 動かし続けながら 並行して 新しい ロジックを 動かし、既存と 新規の ロジックに 差異が ない ことを 確認した ◦ テスト駆動開発をして新しいロジックを書いたが、大規模リリースのため、リリースフラグを用いて少しずつリリースした ◦ ロジックを切り替える修正をテスト駆動開発で行い、ロジックを切り替えた後も動くことを確認した ◦ 以前までの修正コードにマージしても動くことを確認した ◦ 既存ロジックと新規ロジックを並行した状態でリリースし、既存と 新規の ロジックに 差異が ない ことを 確認した ◦ ロジックを 切り 替える 形で リリースした
33. #ques25 個人ワーク • ①「テスト活動」「品 質保証活動」か な？と思うものを付 箋にサインペンで抜 き書きする ②ループのこ の辺でやると 良さそうと思う 位置に貼る
34. #ques25 https://www.linkedin.com/pulse/continuous-testing-devops-dan-ashby/ より引用 どのような価値を提供するのか考える お客様に提供するまでの計画を考える 必要なタスク分解 設計を行う コード実装 コードの マージ テスト環境 へのデプロイ 本番環境へ リリース 機能の反映 運用が回るか 確認 測定値の変化 を確認
35. #ques25 グループワーク • グループ内で違いを味わいつつ共有してみましょう
36. #ques25 グループワーク • ワークをやってみて気づいたことを話し合いましょう • 感想でもOK
37. #ques25 #ques25 ブロッコリーが 適用した例
38. #ques25 お題 • PBIに 「◦◦メソッドが 注文の 締切時間前に 呼ばれてい るので 対応する」と 書かれていた • パッキング画面で 特定の 操作を する ときに ダイアログ を 表示したい • 大幅なリアーキテクチャに よる ロジックの 入れ替えを 開発する ことになった
39. #ques25 「対応するって 何す るの？」 「なんで 注 文の 締切時間前に 呼ばれるのが よくな いの？」と 質問した 質問の 回答から、 今回満た すべき点 が 2つある ことが 分 かった
40. #ques25 それぞれで 対応策 を 考えた 満たすべき点の1つ は設計の考慮漏れ だったため、設計に 追記した
41. #ques25 対応内容について テスト駆動開発を用 いて実装した
42. #ques25 対応内容がアプリ 上でも動作すること を確認した
43. #ques25 実際にリリースし、 適切に動くことを確 認した
44. #ques25 お題 • PBIに 「◦◦メソッドが 注文の 締切時間前に 呼ばれてい るので 対応する」と 書かれていた • パッキング画面で 特定の 操作を する ときに ダイアログ を 表示したい • 大幅なリアーキテクチャに よる ロジックの 入れ替えを 開発する ことになった
45. #ques25 ダイアログ表示が 頻発すると 業務の 妨げに なるのでは ないか？ どれぐらいの 頻度 で 呼び出されている のか把握できてい ない
46. #ques25 修正を 入れる 前 に、 その 部分に ログ を 仕込むことに した
47. #ques25 テスト駆動開発をし て仕込むログの内 容を実装した
48. #ques25 ログを 入れる形でリ リースした
49. #ques25 ログを 確認し、 頻度 が 想定よりも 少な い ことが 確認でき た
50. #ques25 ダイアログ表示の 修正を 入れる こと を 決断した
51. #ques25 テスト駆動開発をし てダイアログ表示の 修正を実装した
52. #ques25 ダイアログ表示の 修正を 入れる形でリ リースした
53. #ques25 全ユーザーにデプ ロイすると問い合わ せが沢山来る可能 性があるので、一部 ユーザーにデプロイ した
54. #ques25 実際に現場に行 き、業務が正常に 行われていることを 確認した
55. #ques25 お題 • PBIに 「◦◦メソッドが 注文の 締切時間前に 呼ばれてい るので 対応する」と 書かれていた • パッキング画面で 特定の 操作を する ときに ダイアログ を 表示したい • 大幅なリアーキテクチャに よる ロジックの 入れ替えを 開発する ことになった
56. #ques25 大幅なリアーキテク チャに よる ロジック の 入れ替えを 開発 する ことになった
57. #ques25 まずは 既存の ロジッ クを 動かし続けなが ら 並行して 新しい ロ ジックを 動かすこと に した
58. #ques25 テスト駆動開発をし て新しいロジックを 書いた
59. #ques25 大規模リリースのた め、リリースフラグ を用いて少しずつリ リースした
60. #ques25 既存ロジックと新規 ロジックを並行した 状態でリリースした
61. #ques25 既存と 新規の ロジッ クに 差異が ない こと を 確認した
62. #ques25 ロジックを切り替え る修正をテスト駆動 開発で行った
63. #ques25 以前までの修正 コードにマージして も動くことを確認し た
64. #ques25 切り替えた後も動く ことを確認した
65. #ques25 ロジックを 切り 替え る 形で リリースした
66. #ques25 #ques25 ワーク
67. #ques25 個人ワーク • もう1枚ワークシートを受け取りましょう ①この中で活用で きそうな「テスト技 術」や「品質保証活 動の知恵」を書き出 す ②ループのこ の辺で活用で きそうと思う位 置に貼る
68. #ques25 #ques25 休憩 19:50～20:00
69. #ques25 グループワーク • グループ内で違いを味わいつつ共有してみましょう
70. #ques25 #ques25 Testing in DevOps の中で行われる テスト活動と 品質保証活動
71. #ques25
72. #ques25 • 今回どのような価値を提供しようとするのか考える • お客様に提供するまでの計画を考える テスト活動・品質保証活動の側面 • テスト要求分析 • テスト計画 PLAN
73. #ques25
74. #ques25 • 価値を提供するために必要なタスクを分解する • タスク分解した内容に対する設計を行う テスト活動・品質保証活動の側面 • リリース計画 • テスト要求分析 • テスト計画 • 設計 • 設計レビュー • テスト設計 BRANCH
75. #ques25
76. #ques25 • 機能開発のコードを実装する テスト活動・品質保証活動の側面 • ユニットコード作成 • テスト駆動開発 • コードレビュー • ペアプログラミング・モブプログラミング CODE
77. #ques25
78. #ques25 • 機能開発した複数のコードをマージする テスト活動・品質保証活動の側面 • コンポーネントテスト • コードレビュー MERGE
79. #ques25
80. #ques25 • マージしたコードを用いてテスト環境にデプロイする テスト活動・品質保証活動の側面 • 統合テスト • システムテスト BUILD
81. #ques25
82. #ques25 • 開発したコードを本番環境へリリースする テスト活動・品質保証活動の側面 • 受け入れテスト • リリースフラグ RELEASE
83. #ques25
84. #ques25 • リリースした内容を環境に適用し、機能を反映させる テスト活動・品質保証活動の側面 • 運用フラグ DEPLOY
85. #ques25
86. #ques25 • 機能が反映された状態で、運用が回るか確認する テスト活動・品質保証活動の側面 • ユーザーインタビュー • 実験フラグ OPERATE
87. #ques25
88. #ques25 • 機能が反映された状態で、 監視している測定値の変化を確認する テスト活動・品質保証活動の側面 • 可観測 • 実験フラグ MONITOR
89. #ques25 グループワーク • ワークをやってみて気づいたことを話し合いましょう • 感想でもOK
90. #ques25 #ques25 ブロッコリーが 適用した例 で活用されている テスト／品質保証活動の 技術や知恵
91. #ques25 お題 • PBIに 「◦◦メソッドが 注文の 締切時間前に 呼ばれてい るので 対応する」と 書かれていた • パッキング画面で 特定の 操作を する ときに ダイアログ を 表示したい • 大幅なリアーキテクチャに よる ロジックの 入れ替えを 開発する ことになった
92. #ques25 「対応するって 何す るの？」 「なんで 注 文の 締切時間前に 呼ばれるのが よくな いの？」と 質問した 質問の 回答から、 今回満た すべき点 が 2つある ことが 分 かった
93. #ques25 質問の際にテスト設計の考え方をフル活用する • テスト要求分析の考え方を用いて、 「何が作れればできたと言えるのか」を考える • テスト設計技法を用いて、パターンの洗い出しを行う ◦ 質問しながら、頭の中でor手元で デシジョンテーブルや状態遷移図を書いたりする
94. #ques25 それぞれで 対応策 を 考えた 満たすべき点の1つ は設計の考慮漏れ だったため、設計に 追記した
95. #ques25 対応内容について テスト駆動開発を用 いて実装した
96. #ques25 対応内容がアプリ 上でも動作すること を確認した
97. #ques25 実際にリリースし、 適切に動くことを確 認した
98. #ques25 お題 • PBIに 「◦◦メソッドが 注文の 締切時間前に 呼ばれてい るので 対応する」と 書かれていた • パッキング画面で 特定の 操作を する ときに ダイアログ を 表示したい • 大幅なリアーキテクチャに よる ロジックの 入れ替えを 開発する ことになった
99. #ques25 ダイアログ表示が 頻発すると 業務の 妨げに なるのでは ないか？ どれぐらいの 頻度 で 呼び出されている のか把握できてい ない
100. #ques25 修正を 入れる 前 に、 その 部分に ログ を 仕込むことに した
101. #ques25 • ログを仕込んで値を確認するのはMONITOR • ただ闇雲にログを仕込めば良いわけではない ◦ ログで情報が溢れ、 何を確認すべきか分からなくなる • 仕込むログの種類、どのような値を計測すれば良いか などは、コード実装よりも前の段階で考えておく 「ログを仕込む」を考えるタイミング
102. #ques25 テスト駆動開発をし て仕込むログの内 容を実装した
103. #ques25 ログを 入れる形でリ リースした
104. #ques25 ログを 確認し、 頻度 が 想定よりも 少な い ことが 確認でき た
105. #ques25 ダイアログ表示の 修正を 入れる こと を 決断した
106. #ques25 テスト駆動開発をし てダイアログ表示の 修正を実装した
107. #ques25 ダイアログ表示の 修正を 入れる形でリ リースした
108. #ques25 全ユーザーにデプ ロイすると問い合わ せが沢山来る可能 性があるので、一部 ユーザーにデプロイ した
109. #ques25 一部ユーザーへのデプロイ • フィーチャーフラグの1つ、運用フラグを用いて デプロイするユーザーを一部にする フィーチャーフラグとは何か • Feature Flag、もしくはFeature Toggle • コードを変更せずに システムの振る舞いを変更できる手法
110. #ques25 4種類のフィーチャーフラグ 記事「Feature Toggles (aka Feature Flags)」の中で フィーチャーフラグを4種類に分類して説明している • アクセス許可フラグ（Permissioning Toggles） • 実験フラグ（Experiment Toggles） • 運用フラグ（Ops Toggles） • リリースフラグ（Release Toggles） 参考：https://martinfowler.com/articles/feature-toggles.html
111. #ques25 運用フラグ • 運用が劇的に変わった時に発生する 負荷を軽減するために利用するフラグ ◦ 問い合わせの急増 ◦ パフォーマンスの急増 • 具体的なプラクティス例 ◦ カナリアリリース ▪ 利用者の一部にリリースして、状況を見て 全体に対象を広げるかどうかを判断する方法
112. #ques25 カナリアリリース 昔、イギリスとアメリカの炭鉱員が地下に降りるとき、 行列の先頭がカナリアのカゴを持って炭鉱に入った。 カナリアの歌声が止まったり、力を失って死ぬなら、 炭鉱内にメタンガスのような有害ガスが多いと判断し、 炭鉱員をいち早く危険地域から 逃げさせる役割を持たせた。 炭鉱の中のカナリア - 山形大学環境保全センター　　　　 炭鉱のカナリア-毒ガスに反応するカナリア イラスト素材 [ 6512744 ] - フォトライブラリー photolibrary
113. #ques25 カナリアリリースの計画例 計画例 • リリース初日 → 全体の10％に適用 • リリース2日目 → 全体の30％に適用 • リリース3日目 → 全体の50％に適用 • リリース4日目 → 全体の80％に適用 • リリース5日目 → 全体（100％）に適用 少 多
114. #ques25 カナリアリリースの計画例 計画例 • リリース初日 → 全体の10％に適用 • リリース2日目 → 全体の30％に適用 • リリース3日目 → 全体の50％に適用 • リリース4日目 → 全体の80％に適用 • リリース5日目 → 全体（100％）に適用 少 多 不具合多発！ 切り戻し
115. #ques25 カナリアリリースの設定方法 • Androidアプリの場合 ◦ 段階的な公開（Staged rollout）機能を用いて 設定可能 ▪ 適用するユーザーの割合は自由に設定可能 • iOSアプリの場合 ◦ Phased Releases機能を用いて設定可能 ▪ 適用するユーザーの割合は固定
116. #ques25 実際に現場に行 き、業務が正常に 行われていることを 確認した
117. #ques25 現場リサーチ • 店舗スタッフが ピッキングやパッキングを 行っている様子を、 すぐそばから観察 • 気になった点をメモする ◦ 時には録画・録音もする • 使い方を教えない 参考：https://speakerdeck.com/nihonbuson/shift-right?slide=38
118. #ques25 お題 • PBIに 「◦◦メソッドが 注文の 締切時間前に 呼ばれてい るので 対応する」と 書かれていた • パッキング画面で 特定の 操作を する ときに ダイアログ を 表示したい • 大幅なリアーキテクチャに よる ロジックの 入れ替えを 開発する ことになった
119. #ques25 大幅なリアーキテク チャに よる ロジック の 入れ替えを 開発 する ことになった
120. #ques25 まずは 既存の ロジッ クを 動かし続けなが ら 並行して 新しい ロ ジックを 動かすこと に した
121. #ques25 テスト駆動開発をし て新しいロジックを 書いた
122. #ques25 大規模リリースのた め、リリースフラグ を用いて少しずつリ リースした
123. #ques25 大規模な修正を少しずつリリースする • フィーチャーフラグの1つ、リリースフラグを用いて 本番環境に影響を与えずに少しずつリリースする
124. #ques25 4種類のフィーチャーフラグ（再掲） 記事「Feature Toggles (aka Feature Flags)」の中で フィーチャーフラグを4種類に分類して説明している • アクセス許可フラグ（Permissioning Toggles） • 実験フラグ（Experiment Toggles） • 運用フラグ（Ops Toggles） • リリースフラグ（Release Toggles） 参考：https://martinfowler.com/articles/feature-toggles.html
125. #ques25 リリースフラグ • 大規模なソースコードの変更とならないように 制御するために利用するフラグ • 機能リリースとコードデプロイの分離が可能になる • 具体的なプラクティス例 ◦ リリース戦略への活用
126. #ques25 リリースフラグ活用なしの場合のリリース戦略例 今までの開発した コードをいっぺんに マージ 開発中にマージ しないため 差分が溜まり続ける feature main マージ ※mainブランチに入っているものを本番環境にデプロイ
127. #ques25 リリースフラグ活用なしの場合のリリース戦略例 今までの開発した コードをいっぺんに マージ 開発中にマージ しないため 差分が溜まり続ける feature main マージ 最後のマージ部分でテスト実施
128. #ques25 リリースフラグ活用ありの場合のリリース戦略例 本番環境での リリース フラグをOFF feature main マージ
129. #ques25 リリースフラグ活用ありの場合のリリース戦略例 本番環境での リリース フラグをOFF feature main マージ
130. #ques25 リリースフラグ活用ありの場合のリリース戦略例 本番環境での リリース フラグをOFF feature main マージ フラグがOFFの間 ユーザーには 見えていない
131. #ques25 リリースフラグ活用ありの場合のリリース戦略例 本番環境での リリース フラグをOFF feature main マージ フラグがOFFの間 ユーザーには 見えていない
132. #ques25 リリースフラグ活用ありの場合のリリース戦略例 本番環境での リリース フラグをOFF 本番環境での リリース フラグをON feature main マージ
133. #ques25 リリースフラグ活用ありの場合のリリース戦略例 本番環境での リリース フラグをOFF 本番環境での リリース フラグをON feature main マージ 検証環境でリリースフラグをONにすることで 細かい差分でテスト可能
134. #ques25 リリースフラグがシフトレフトなテスト活動である理由 • リリースフラグなしの場合 ◦ 必要な変更が全て入った時にテスト実施 ▪ リリース直前にテストすることになる ▪ 差分も大きくなる • リリースフラグありの場合 ◦ mainブランチに変更が入る時にテスト実施 ▪ リリースフラグなしの場合に比べて 早い段階でテスト可能 ◦ シフトレフトしていると言える ◦ 1回の差分が小さいため、テスト対象範囲も小さい
135. #ques25 既存ロジックと新規 ロジックを並行した 状態でリリースした
136. #ques25 既存と 新規の ロジッ クに 差異が ない こと を 確認した
137. #ques25 ロジックを切り替え る修正をテスト駆動 開発で行った
138. #ques25 以前までの修正 コードにマージして も動くことを確認し た
139. #ques25 切り替えた後も動く ことを確認した
140. #ques25 ロジックを 切り 替え る 形で リリースした
141. #ques25 #ques25 チェックアウト
142. #ques25 チェックアウトワーク 準備ワーク • 付箋を1枚準備 • 持ち帰って取り組むことを一つ、サインペンで書きま す • 書けた方は付箋を持って立ち上がりましょう 共有ワーク • 立ち上がっている人でペアをつくって、お互いに「こ れこれをやってみようと思います」と宣言します • 終わったら次の人を探して、どんどん共有しましょう
143. #ques25 #ques25 おわりに
144. #ques25 おわりに • 品質を作り込むためにシフトレフトなテストをする • 定量的・定性的にシフトライトなテストをする • 普段のテスト活動よりも前のタイミング、 後のタイミングでもテスト活動ができないか 考えてみてほしい
145. 宣伝：10Xでは採用募集しています！ 10Xでは、 • Shift-leftとShift-right • 定量と定性 など様々な角度から 品質管理をする仲間を 募集しています！ 詳しくはこちら　→
146. #ques25 宣伝：WACATE 2025 冬 • ソフトウェアテストをテーマにした グループワーク形式の合宿型勉強会 • 日時：12/20（土）10:00 ～ 12/21（日）17:30 • 参加費：30,000円 ◦ 宿泊費、4食の食事代含む ◦ 35歳以下は27,000円 • 場所：トーセイホテル＆セミナー幕張 ◦ JR京葉線　新習志野駅 徒歩約2分 • 締切：11月23日（日）まで • 申し込みは公式ページから
147. #ques25 WACATEの開催会場は幕張 トーセイホテル ＆セミナー幕張
148. #ques25 ワークも食事もみんなで！