【mablers_JP - Online MeetsUp vol.4】Bitkeyでのmablを活用したテストエンジニアの思考プロセス機械化

© 2023 Bitkey Inc.
Bitkeyでのmablを活用したテストエンジニアの思考プロセス機械化
株式会社ビットキー　三上鹿　| 2023/09/26

View Slide

2
Copyright © 2023 Bitkey Inc. All right reserved.
はじめに

View Slide

3
はじめに
◾本セッションの対象者
- mabl導⼊を検討している企業または個⼈
- mablを導⼊したが、⾃⾝以外が担当していた範囲のテストケースの作成にお困りの⽅
- 他社でのmabl導⼊事例を知りたい⽅
◾本セッションのゴール
- mabl導⼊を検討している⽅は具体的な業務内容を知ることで、導⼊判断に活かすことができる
- mabl利⽤者は他メンバーが実施しているテストをmablで作成することができるようになる

View Slide

4
自己紹介

View Slide

5
株式会社ビットキー
自己紹介
・テスト自動化エンジニア
・Workspace事業を中心に活動中
資格
・mabl Skills Certiﬁcation
- Foundation
- Advanced
- Non-Functional
三上鹿
Mikami Roku
▶[Qiita] : @Roku_Mikami_bitkey
▶[Speaker Deck] : r0ku

View Slide

6
2018.08
2022.11
2023.01
株式会社ソニー・インタラクティブ・エンタテインメ
ントへ参画
テストエンジニアとして家庭用ゲーム機とその周辺機
器を対象としたシステムテストを行う
株式会社ビットキーへ参画
テストエンジニアとしてIoT製品を対象としたシステム
テストを行う
mablによる自動化推進の専任者としてアサインされる
2023.09 テスト自動化エンジニアとして自動テストの導入を推
進中
自己紹介
三上鹿
Mikami Roku
▶[Qiita] : @Roku_Mikami_bitkey
▶[Speaker Deck] : r0ku

View Slide

7
目次

View Slide

8
目次
【テーマ】
良質な自動テストを作成する鍵はテストエンジニアの思考プロセス！
優れたテストエンジニアならではの思考プロセスをFLOWで表現➡機械化することで良質なテストをいつでも・誰でも再現可能にしよう
【第二章】自動テストの品質を高めるための取り組み
①データの命名規則を決定する
②テストの読みやすさを意識する
③テストエンジニアの思考プロセスをFLOWで表現する
【第一章】mablにおける自動テスト作成方法
①基本構成
②作成フロー
③FLOWを活用した自動テストの作成
【第三章】ビットキーのmabl導入事例
①導入の背景
②リグレッションテストの自動化率
③自動テスト作成のライフサイクル
④実際の利用画面
【終章】mablと出会って

View Slide

9
目次
【テーマ】
①基本構成
②作成フロー
①導入の背景

View Slide

10
目次
【テーマ】
①基本構成
②作成フロー
①導入の背景

View Slide

11
目次
【テーマ】
①基本構成
②作成フロー
①導入の背景

View Slide

12
目次
【テーマ】
①基本構成
②作成フロー
①導入の背景

View Slide

13
目次
【テーマ】
①基本構成
②作成フロー
①導入の背景

View Slide

14
目次
【テーマ】
①基本構成
②作成フロー
①導入の背景
全四章でお送りします！

View Slide

15

View Slide

16
①基本構成
②作成フロー

View Slide

17
①基本構成
②作成フロー

View Slide

18
【第一章】mablにおける自動テスト作成方法 - ①基本構成
引用：https://help.mabl.com/docs/product-overview-ja
◾mablワークスペースの構成

View Slide

19
検証環境を構成する最上位の要素

View Slide

20
検証対象となるプロダクト

View Slide

21
検証を行う環境

View Slide

22
テストをまとめる箱

View Slide

23
テストをまとめる箱
操作を記録し保存

View Slide

24
①基本構成
②作成フロー

View Slide

25
【第一章】mablにおける自動テスト作成方法 - ②作成フロー
環境を指定
アプリケーションを指定
テストを作成
テストを実行
◾シンプルに作る場合・・・

View Slide

26
環境を指定
テストを作成
テストを実行

View Slide

27
環境を指定
テストを作成
テストを実行

View Slide

28
環境を指定
テストを作成
テストを実行

View Slide

29
環境を指定
テストを作成
テストを実行

View Slide

30
環境を指定
テストを作成
テストを実行
最短4工程で完了

View Slide

31
環境を指定
テストを作成
テストを実行
自動テストをしっかり運用していく
場合は工夫する必要がある

View Slide

32
環境を指定
テストを作成
テストを実行
そこでここではユーザーの多くが
行っている...と思われる工程を
追加して紹介します

View Slide

33
環境を指定
テストを作成
テストを実行
そこでここではユーザーの多くが
行っている...と思われる工程を
追加して紹介します
ビットキーでの実践例は第三章にて！

View Slide

34
環境を指定
テストを作成
テストを実行
一般的？な工程にすると・・・

View Slide

35
環境を指定
テストを作成(1~Nコ)
プランを作成
◾一般的？な工程
開発ブランチを作成
プランを実行
masterブランチにマージ

View Slide

36
環境を指定
プランを作成
プランを実行
順番に説明します！

View Slide

37
環境を指定
プランを作成
プランを実行

View Slide

38
◾ブランチ一覧画面
環境を指定
プランを作成
プランを実行

View Slide

39
ブランチ・・・小規模の作業スペース
環境を指定
プランを作成
プランを実行

View Slide

40
環境を指定
プランを作成
プランを実行
mablには下記2種類のブランチが存在
・masterブランチ
・・・完成したテストを動かす場所
・開発ブランチ
・・・テストを作成する場所

View Slide

41
環境を指定
プランを作成
プランを実行
mablには下記2種類のブランチが存在
・masterブランチ
・・・完成したテストを動かす場所
・開発ブランチ
・・・テストを作成する場所
完成したテストに影響しないように
独立した作業スペース=開発ブランチで
テストを作成する

View Slide

42
環境を指定
プランを作成
プランを実行

View Slide

43
環境を指定
プランを作成
プランを実行
◾テスト作成画面

View Slide

44
環境を指定
プランを作成
プランを実行
アプリケーション
・・・テスト対象となるものを設定

View Slide

45
環境を指定
プランを作成
プランを実行
アプリケーション
・・・テスト対象となるものを設定
環境
・・・テストを行う環境を設定

View Slide

46
環境を指定
プランを作成
プランを実行

View Slide

47
環境を指定
プランを作成
プランを実行
◾トレーナー画面

View Slide

48
環境を指定
プランを作成
プランを実行
[Rec]ボタン
・・・オンにすることでブラウザ上での
操作がテストステップとして記録される

View Slide

49
環境を指定
プランを作成
プランを実行
[Rec]ボタン
テストステップ
・・・記録された画面操作

View Slide

50
環境を指定
プランを作成
プランを実行
[Rec]ボタン
[Rec]ボタンの他にも様々な
方法で追加可能

View Slide

51
環境を指定
プランを作成
プランを実行
[Rec]ボタン
アサーション
・・・複数あるテストステップの種類
のうちの一つ。画面上にあるべき要素
が存在することを確認する

View Slide

52
環境を指定
プランを作成
プランを実行
[Rec]ボタン
アサーション
・・・複数あるテストステップの種類
のうちの一つ。画面上にあるべき要素
が存在することを確認する
テストの多くは「何かの操作を行った結果」が
「画面上に表示される」ことを確認する必要が
あるため、
アサーションをテストの締め括りにする

View Slide

53
環境を指定
プランを作成
プランを実行
◾Recによるテストステップの追加→アサーションまで

View Slide

54
環境を指定
プランを作成
プランを実行
テストのボリュームが大きい場合は下記のような
方針をもとにテストを複数作成する場合がある
・テストスイートごとに作成
・テストの実行時間が15分を超えないように作成

View Slide

55
環境を指定
プランを作成
プランを実行

View Slide

56
環境を指定
プランを作成
プランを実行
◾プラン作成画面

View Slide

57
環境を指定
プランを作成
プランを実行
プランに内包するテストは複数指定可能

View Slide

58
環境を指定
プランを作成
プランを実行
例：機能単位やシナリオ単位でまとめる

View Slide

59
環境を指定
プランを作成
プランを実行
同時実行数や実行順序の設定が可能

View Slide

60
環境を指定
プランを作成
プランを実行
特定の曜日や一定の時間感覚、または
ビルドのデプロイメントごとに実行など
様々なタイプのトリガーを設定可能
同時実行数や実行順序の設定が可能

View Slide

61
環境を指定
プランを作成
プランを実行

View Slide

62
環境を指定
プランを作成
プランを実行
◾プランの実行履歴

View Slide

63
環境を指定
プランを作成
プランを実行
実行する際にブランチを指定可能

View Slide

64
環境を指定
プランを作成
プランを実行
実行結果はプラン単位または
テスト単位で確認可能

View Slide

65
環境を指定
プランを作成
プランを実行
実行結果はプラン単位または
テスト単位で確認可能
過去の実行結果から
成功率・実行時間の統計データを表示

View Slide

66
環境を指定
プランを作成
プランを実行

View Slide

67
環境を指定
プランを作成
プランを実行
◾ブランチ詳細画面

View Slide

68
環境を指定
プランを作成
プランを実行
Merge branchを選択すると
マージ確認画面が開く。
マージ内容に問題がある場合は
警告が表示される

View Slide

69
環境を指定
プランを作成
プランを実行
masterブランチに存在するテストとの
テストステップの差分数を確認可能

View Slide

70
環境を指定
プランを作成
プランを実行
masterブランチに存在するテストとの
テストステップの差分数を確認可能
masterブランチへの影響を最小限にするため、
作成したテストの成功を開発ブランチで確認し
た後マージするのが好ましい

View Slide

71
環境を指定
プランを作成
プランを実行
マージできれば作成完了！

View Slide

72
環境を指定
プランを作成
プランを実行
以上が作成フローになります！

View Slide

73
①基本構成
②作成フロー

View Slide

74
【第一章】mablにおける自動テスト作成方法 - ③FLOWを活用した自動テストの作成
◾FLOWとは？
・単一または複数のテストステップを格納できる箱
・FLOWは作成されるとmablのデータベースに保存される
・データベースに保存されたFLOWは呼び出して実行することが可能
・FLOWは作成したテストの中だけでなく、異なるテストでも呼び出すことが可能

View Slide

75
◾FLOWとは？

View Slide

76
◾FLOWとは？
Googleでmablと検索して
mablのホームページにアクセスする
ために必要なテストステップ

View Slide

77
◾FLOWとは？
FLOWにすることで
複数のテストステップをひとまとめに！

View Slide

78
◾FLOWとは？
FLOWにすることで
複数のテストステップをひとまとめに！
まとめるとどうなるの？

View Slide

79
◾FLOWとは？

View Slide

80
◾FLOWとは？

View Slide

81
◾FLOWとは？

View Slide

82
◾FLOWとは？

View Slide

83
◾FLOWとは？

View Slide

84
◾FLOWとは？
つまりFLOWを活用すると・・・

View Slide

85
◾FLOWとは？
つまりFLOWを活用すると・・・
FLOWを呼び出すだけでテストを作れる！

View Slide

86
例えば・・・
Googleにログインできてることを
確認したいな〜

View Slide

87
ログインする
Googleに
アクセスする
テキスト検索する
ログアウトする
マイページに遷移する
名前とメールアドレスの
表示を確認する

View Slide

88
ログインする
Googleに
アクセスする
データベースに保存されたFLOW

View Slide

89
ログインする
Googleに
アクセスする
データベースに保存されたFLOW
テストに必要なものを呼び出す

View Slide

90
ログインする
Googleに
アクセスする
Googleに
アクセスする

View Slide

91
ログインする
Googleに
アクセスする
Googleに
アクセスする
ログインする

View Slide

92
ログインする
Googleに
アクセスする
Googleに
アクセスする
ログインする

View Slide

93
ログインする
Googleに
アクセスする
Googleに
アクセスする
ログインする

View Slide

94
ログインする
Googleに
アクセスする
Googleに
アクセスする
ログインする
FLOWを呼び出すだけでテストが作れる！

View Slide

95
ログインする
Googleに
アクセスする
Googleに
アクセスする
ログインする
作成時間の短縮

View Slide

96
ログインする
Googleに
アクセスする
Googleに
アクセスする
ログインする
作成時間の短縮
検証内容の標準化

View Slide

97
◾その他FLOWを使うメリット
・FLOWに変更を加えると該当のFLOWを利用したテストすべてに変更内容が適用される
→ メンテナンスの手間・時間を大幅に短縮
・FLOWにすることでパラメータの生成、ループ設定ができる
→ テストの幅を広げることが可能になる

View Slide

98

View Slide

99

View Slide

100
第一章をまとめると・・・

View Slide

101
・mablのテストの基本構成は下記の順
- ①ワークスペース
- ②アプリケーション
- ③環境
- ④プラン
- ⑤テスト
・mablの一般的？なテスト作成フローは下記の順
- ①開発ブランチを作成
- ②アプリケーションを指定
- ③環境を指定
- ④テストを作成
- ⑤プランを作成
- ⑥プランを実行
- ⑦masterブランチにマージ
◾第一章のまとめ
・FLOWを十分活用することができたならFLOWを呼び出すだけでテストを作成できる
- 作成時間の短縮
- 検証内容の標準化

View Slide

102
- ③環境
- ④プラン
- ⑤テスト

View Slide

103
- ③環境
- ④プラン
- ⑤テスト

View Slide

104
- ③環境
- ④プラン
- ⑤テスト

View Slide

105
第一章完

View Slide

106
目次
【テーマ】
①基本構成
②作成フロー
①導入の背景

View Slide

107

View Slide

108

View Slide

109

View Slide

110
【第二章】自動テストの品質を高めるための取り組み - ①データの命名規則を決定する
◾mablで命名可能なデータ *代表的なもののみ記載
・プラン
・テスト
・フロー

View Slide

111
・プラン
・テスト
・フロー

View Slide

112
・プラン
・テスト
・フロー

View Slide

113
・プラン
・テスト
・フロー

View Slide

114
・プラン
・テスト
・フロー
例えば
フローの命名規則がない場合...

View Slide

115
1.Googleのホームページにアクセス
2.「mabl」とテキスト入力
3.検索ボタンを押下
4.検索一覧画面が表示されるまで待機
5.mablのホームページが一覧画面に表示されることを確認
6.検索結果からmablのホームページのリンクを選択
7.mablのホームページが表示されることを確認
◾例：mablのホームページを表示するまでのテストステップ

View Slide

116

View Slide

117
これをフローにする時、
どう命名しよう？

View Slide

118
Aさん：
テスト動けばいいしこのままでいいかな

View Slide

119
Aさん：
テスト動けばいいしこのままでいいかな
mablのホームページを表示する

View Slide

120
Bさん：
検索する時に使うサイトを書かないとね

View Slide

121
Bさん：
検索する時に使うサイトを書かないとね
Googleでmablと検索し、mablのホームページまで遷移する

View Slide

122
Cさん：
プレフィックスつけると検索性上がるかな

View Slide

123
Cさん：
プレフィックスつけると検索性上がるかな
[Google]mablと検索 > mablのホームページに遷移

View Slide

124

View Slide

125
後からテスト作成する人：
なんで同じ処理のフローが3つもあるの...？

View Slide

126
後からテスト作成する人：
なんで同じ処理のフローが3つもあるの...？
いずれも間違った命名の仕方ではないし、
人によってしっくりくる命名方法は異なる

View Slide

127
◾命名規則が存在しないと・・・
・同じ内容のデータの重複作成
→同じ命名のものがないと思ってしまい新しく作ってしまう
・データの検索性の低下
→機能AのFLOWを使うにはどのように調べれば良いかわからない

View Slide

128

View Slide

129

View Slide

130
FLOWを使えば5分で終わる作業が
1時間以上かかってしまった・・・

View Slide

131
FLOWを使えば5分で終わる作業が
1時間以上かかってしまった・・・
これを防ぐためには命名規則を決定し、
認識合わせを行うことが大事！

View Slide

132
◾命名規則の例
・プレフィックスを使う
→[Google]ログインする
・機能名を記載する
→[Google][ログイン機能]ログインする
・画面名を記載する
→[Google][ログイン機能][詳細画面]ログインする

View Slide

133

View Slide

134

View Slide

135

View Slide

136
あくまで一例です

View Slide

137
あくまで一例です
複数人で会話をし、しっくりくる命名を
探すことをおすすめします！

View Slide

138
◾命名規則を決定することで・・・
・必要なデータを見つけやすくなる
→テストの作成時間が短くなる
・複数人で命名に関しての認識を合わせられる
→意思疎通が行いやすくなる
・規則性のある作業場所を構築できる
→属人化を防ぐことができる

View Slide

139

View Slide

140

View Slide

141

View Slide

142
良質な自動テストに必要な条件！

View Slide

143

View Slide

144
【第二章】自動テストの品質を高めるための取り組み - ②テストの読みやすさを意識する
機能Aのリグレッションテスト自動化したので
レビューお願いします！

View Slide

145

View Slide

146
頑張って読み解く必要がありそうだ・・・

View Slide

147

View Slide

148
Googleで検索してるんだな...

View Slide

149
なにやってるんだろう・・・

View Slide

150
このテストステップ
必要なのかな・・・

View Slide

151
このテストステップ
必要なのかな・・・
テスト内容が適切かどうか判断が難しい

View Slide

152
◾テストが読みにくいと・・・
・第三者が読んで理解するのに時間がかかる
→レビューコストの増加
・テスト内容の不備に気づきにくい
→期待値の見落とし
・何を目的とした処理か分からず手を加えにくい
→属人化しやすくなる

View Slide

153

View Slide

154

View Slide

155

View Slide

156
「この一瞬だけテストを動かしたい！」
という場合読みにくくても動けば問題ない

View Slide

157
「この一瞬だけテストを動かしたい！」
という場合読みにくくても動けば問題ない
ただしリグレッションテストのように
繰り返しテストを行いたい場合はこれらの
問題を避けるために読みやすくする工夫が必要

View Slide

158
mablでテストを読みやすくするためにできることは？

View Slide

159
◾テストの読みやすさを向上させるための取り組み
・ステップ名を変更する
→「何をしているか」を一目でわかるように
・Echoステップでテストステップをグループごとに分ける
→「何のための処理か」を判明しやすいように

View Slide

160

View Slide

161

View Slide

162

View Slide

163

View Slide

164

View Slide

165

View Slide

166
テストを読みやすくすることで
テストの品質の維持・改善をしやすい状態に！

View Slide

167

View Slide

168
・テストを自動化するのは？
【第二章】自動テストの品質を高めるための取り組み - ③テストエンジニアの思考プロセスをFLOWで表現する

View Slide

169
人

View Slide

170
人
・テストを実行するのは？

View Slide

171
人
機械

View Slide

172
人
機械
→　「人」が「機械」にテストの実行手順を教える必要がある

View Slide

173
人
機械
→　教える「人」の技量が自動テストの品質を左右する

View Slide

174
人
機械
→　教える「人」の技量が自動テストの品質を左右する
　　　具体的な技量って何？

View Slide

175
ポイント① ：「ヒトの曖昧さ」を文章で表現できるか
ポイント② ：「期待値がなぜ期待値となっているか」の説明をできるか
ポイント③ ：「テストとして必要な観点」をリストアップできるか

View Slide

176

View Slide

177

View Slide

178
順番に説明します！

View Slide

179

View Slide

180
たとえば下記のようなテストがあったとして・・・
【前提条件】
・Googleにログインしていないこと
【手順】
1.「https://www.google.com」にアクセスする
【期待値】
Googleにアクセスできること

View Slide

181
【前提条件】
【手順】
【期待値】

View Slide

182
【前提条件】
【手順】
【期待値】

View Slide

183
【前提条件】
【手順】
【期待値】
何を以ってGoogleにアクセスできたと
確信できる？

View Slide

184
【前提条件】
【手順】
【期待値】
何を以ってGoogleにアクセスできたと
確信できる？
ヒトがテストする場合は・・・

View Slide

185
【前提条件】
【手順】
【期待値】
全体を眺めて・・・

View Slide

186
【前提条件】
【手順】
【期待値】
・Googleのロゴがある
・検索窓がある
・検索ボタンもある
・ログインボタンが表示されている
・レイアウトも問題なさそう

View Slide

187
【前提条件】
【手順】
【期待値】
→　アクセスできてるね！

View Slide

188
【前提条件】
【手順】
【期待値】
記載を曖昧にすることで
ヒトの感性に委ねた柔軟性の高い
テストを実行できる

View Slide

189
【前提条件】
【手順】
【期待値】
機械が実行する場合・・・

View Slide

190
【前提条件】
【手順】
【期待値】
Q.アクセスできることってどうやって
　確認したらいいんですか？

View Slide

191
【前提条件】
【手順】
【期待値】
なんとなく全体を見て！

View Slide

192
【前提条件】
【手順】
【期待値】
Q.つまりどの要素を確認するべきでしょうか？

View Slide

193
【前提条件】
【手順】
【期待値】
ヒトが曖昧的に見ていた要素を明示する必要がある

View Slide

194
【前提条件】
【手順】
【期待値】
ヒトが曖昧的に見ていた要素を明示する必要がある
つまり・・・

View Slide

195
【前提条件】
【手順】
【期待値】

View Slide

196
【前提条件】
【手順】
【期待値】
この部分を機械に伝える必要がある

View Slide

197
【前提条件】
【手順】
【期待値】
この部分を機械に伝える必要がある
自動化する際はここを文章にできるかがポイント①

View Slide

198

View Slide

199
【前提条件】
【手順】
【期待値】

View Slide

200
【前提条件】
【手順】
【期待値】
これを機械に伝えることは
難しくないが・・・

View Slide

201
【前提条件】
【手順】
【期待値】
そもそも何でこれの確認をもって
良しとしていたのだろう？

View Slide

202
【前提条件】
【手順】
【期待値】
品質の良い・悪いの指標に
何を用いているかを知る

View Slide

203
【前提条件】
【手順】
【期待値】
品質の良い・悪いの指標に
何を用いているかを知る
自動テストに限った話ではないので、
そもそも期待値の表現がよくないかも
↓
テストの書き方を見直す機会にもなる

View Slide

204
【前提条件】
【手順】
【期待値】
→　何を以ってGoogleにアクセスできたと確信できる？
確認する理由を説明してみると・・・

View Slide

205
【前提条件】
【手順】
【期待値】
→ Googleの象徴なので確認する
→ ユーザーがGoogleに最も期待する機能なので見る
→同上
→前提条件に「ログインしていないこと」とあるのでそ
の確認としてみる
→見栄えの良し悪しはユーザー体験に直結するのでみる

View Slide

206
【前提条件】
【手順】
【期待値】
→同上
この説明ができるかどうかがポイント②

View Slide

207

View Slide

208
【前提条件】
【手順】
【期待値】
→同上

View Slide

209
【前提条件】
【手順】
【期待値】
→同上
確認するのはこれだけで本当に良い？

View Slide

210
【前提条件】
【手順】
【期待値】
→同上
これをテストする必要は本当にある？

View Slide

211
【前提条件】
【手順】
【期待値】
→同上
これをテストする必要は本当にある？
またプロダクトを取り巻く状況は変わる可能性があり...

View Slide

212
【前提条件】
【手順】
【期待値】
→同上
直近で重大な不具合が
あって・・・

View Slide

213
【前提条件】
【手順】
【期待値】
→同上
法律の観点で・・・
あって・・・

View Slide

214
【前提条件】
【手順】
【期待値】
→同上
バックエンドの処理に変更
を加えたので・・・
あって・・・

View Slide

215
【前提条件】
【手順】
【期待値】
→同上
直近で重篤な不具合が
あったから・・・
テストに必要な観点を過不足なくリストアッ
プできるか？

View Slide

216
【前提条件】
【手順】
【期待値】
→同上
プできるか？
テストの品質を高めるには
最新の情報にアンテナを張る必要がある

View Slide

217
【前提条件】
【手順】
【期待値】
→同上
プできるか？
テストの品質を高めるには
最新の情報にアンテナを張る必要がある
これがポイント③

View Slide

218
これができると自動テストの内容がより良くなる！

View Slide

219
ここで集めた情報、せっかくなら他の人にも共有したい

View Slide

220
説明したり資料にするのは手間がかかるかも・・・

View Slide

221
説明したり資料にするのは手間がかかるかも・・・
これ、mablなら簡単に共有・再利用できます

View Slide

222
◾テストエンジニアの思考プロセスをFLOWで表現する方法
①検証内容の妥当性を確認
②検証内容をテストステップで表現
③テストステップをFLOWに格納

View Slide

223

View Slide

224
最初に説明した以下のポイントを意識する

View Slide

225
最初に説明した以下のポイントを意識する
テスト対象のプロダクトに精通したテストエンジニアに
レビューを依頼し指摘を受けることで優秀なテストエンジニアの
思考プロセスをFLOWで表現しやすくなる

View Slide

226

View Slide

227
①で示した内容をテストステップにする

View Slide

228
①で示した内容をテストステップにする
第二章の①、②で紹介した下記内容を意識できるとより良い
・データの命名規則を決定する
・テストの読みやすさを意識する

View Slide

229

View Slide

230
繰り返しになりますが、
利用しやすいFLOWになるように命名を意識できると良い

View Slide

231
これを行うことで・・・

View Slide

232
[Google][検索画面]テキスト検索の動作検証
[Google][ログイン機能]ユーザー切り替えの検証
[Google][設定画面]各設定値の動作検証
・
・
・

View Slide

233
・
・
・
テストエンジニアの思考プロセスをFLOWで表現

View Slide

234
・
・
・
FLOW＝検証手順を機械化できた

View Slide

235
・
・
・
テストエンジニアの思考プロセスを
FLOWで表現することで検証手順を機械化できた
FLOW＝検証手順を機械化できた

View Slide

236
第二章をまとめると・・・

View Slide

237
◾第二章のまとめ
→データを見つけやすくなり、また作業者間での意思疎通が行いやすくなる
→テスト内容がわかりやすくなり、またテストの属人化を防ぐことができる
・テストエンジニアの思考プロセスをFLOWで表現する
→優れた検証手順を誰でも・いつでも実行可能になる

View Slide

238

View Slide

239

View Slide

240

View Slide

241
第二章完

View Slide

242
目次
【テーマ】
①基本構成
②作成フロー
①導入の背景

View Slide

243

View Slide

244
①導入の背景

View Slide

245
①導入の背景

View Slide

246
1週目
月火水木金
2週目
開発
検証
▪mabl導入対象となったプロダクトの開発スケジュール
【第三章】ビットキーのmabl導入事例 - ①導入の背景

View Slide

247
1週目
月火水木金
2週目
開発
検証
・開発チーム→開発作業
・QAチーム→検証準備
　- テスト分析
　- テスト設計
　- テスト実装

View Slide

248
1週目
月火水木金
2週目
開発
検証
・開発チーム→開発作業
・QAチーム→検証準備
　- テスト分析
　- テスト設計
　- テスト実装

View Slide

249
1週目
月火水木金
2週目
開発
検証
・QAチーム→検証開始
- ①新機能テスト
(追加した機能の振る舞いを確認)
- ②修正確認テスト
(欠陥が修正されていることを確認)
- ③リグレッションテスト
(意図しない振る舞いが起きてないか確認)
・開発チーム→QAが検知した不具合の修正
&次回リリースに向け準備

View Slide

250
1週目
月火水木金
2週目
開発
検証
・QAチーム→検証開始
- ①新機能テスト
(追加した機能の振る舞いを確認)
- ②修正確認テスト
(欠陥が修正されていることを確認)
- ③リグレッションテスト
(意図しない振る舞いが起きてないか確認)
・開発チーム→QAが検知した不具合の修正
&次回リリースに向け準備

View Slide

251
1週目
月火水木金
2週目
開発
検証
検証期間の内訳は・・・

View Slide

252
1週目
月火水木金
2週目
開発
検証
新機能テスト・修正確認テストリグレッションテスト

View Slide

253
1週目
月火水木金
2週目
開発
検証
リグレッションテスト
機能の拡充に伴い、検証期間内のうち
およそ半分をリグレッションテストに
割り当てる必要がある状態に
新機能テスト・修正確認テスト

View Slide

254
1週目
月火水木金
2週目
開発
検証
機能の拡充に伴い、検証期間内のうち
およそ半分をリグレッションテストに
割り当てる必要がある状態に
機能はまだまだ拡充する予定なので
リグレッションテストの負担を減らす
工夫を行う必要がある
新機能テスト・修正確認テスト

View Slide

255
・リグレッションテストの省力化をしたい
・意図せぬ影響によるリグレッションを防ぎたい
◾ビットキーとしては・・・

View Slide

256

View Slide

257

View Slide

258
これらの課題に対する対策として自動テストを導入しよう

View Slide

259
mablに決めたのはなぜ？

View Slide

260
・ノーコード・ローコードで自動テストを作成
・ブラウザテストの作成
◾mablを選んだ理由として・・・
・APIテスト、ファイルアップロードテスト、メール送信テストなどの実行
・スケジュールを設定して実行、などなど・・・

View Slide

261

View Slide

262

View Slide

263

View Slide

264

View Slide

265
柔軟にテストを作成できそう！

View Slide

266
柔軟にテストを作成できそう！
さらに加えて・・・

View Slide

267
★レスポンスが早く、動作が快適だった
★カスタマーサポートの対応が柔軟
★ほかもろもろ考慮して・・・

View Slide

268

View Slide

269

View Slide

270
キミに決めた！

View Slide

271
①導入の背景

View Slide

272
◾チーム構成
・SET x 1名 (チームのマネジメントが主業務）
・テストエンジニア x 2名 (三上もこの枠)
◾作業方針
1. SETが自動テストの運用ガイドラインや作成方針を決定
2. 上記に基づきテストエンジニア2名が作業
【第三章】ビットキーのmabl導入事例-②リグレッションテストの自動化率

View Slide

273
◾チーム構成
◾作業方針

View Slide

274
◾チーム構成
◾作業方針
一般的にマネジメントは主業務ではないですが、
自動化という文脈においてbitkeyの当時の状況を
踏まえた結果このかたちに

View Slide

275
◾チーム構成
◾作業方針

View Slide

276
◾チーム構成
◾作業方針

View Slide

277
◾作業方針
◾チーム構成

View Slide

278
◾作業方針
◾チーム構成

View Slide

279
◾チーム構成
◾作業方針
ちなみに

View Slide

280
◾作業方針
◾E2Eテストの自動化経験
・ビットキー（会社）：なし
・テストエンジニア2名 : なし
◾チーム構成

View Slide

281
◾作業方針
◾チーム構成

View Slide

282
◾作業方針
◾チーム構成

View Slide

283
◾作業方針
ゼロからはじめました
◾チーム構成

View Slide

284
◾作業方針
ゼロからはじめました
◾チーム構成
途中人員配置の変更がありましたが、
作業人数に大きく変わりはないため説明
は割愛します

View Slide

285
◾特定のプロダクトを対象に導入開始
のケース数
約1000
実施工数約45h
実施頻度月2回
月間合計約90h
【導入前】2023年1月

View Slide

286
のケース数
約1000
実施工数約45h
実施頻度月2回
月間合計約90h
【導入前】2023年1月
mablを導入して・・・

View Slide

287
のケース数
約1000
実施工数約45h
実施頻度月2回
月間合計約90h
のケース数
約1000
実施工数約25h
実施頻度月2回
月間合計約50h
【導入前】2023年1月【導入後】2023年8月

View Slide

288
のケース数
約1000
実施工数約45h
実施頻度月2回
月間合計約90h
のケース数
約1000
実施工数約25h
実施頻度月2回
月間合計約50h
【導入前】2023年1月【導入後】2023年8月
1回の実施工数が約20h削減！
月単位で見ると約40h/月削減！

View Slide

289
推移をグラフで見ると・・・

View Slide

290

View Slide

291
◾月ごとの平均
・シナリオ : 2.5個
・テストケース : 44個
・削減工数 : 5h

View Slide

292

View Slide

293
◾1~3月 : 【目標】10個のシナリオを自動化
・2人投入していたが1名は手動テストと兼任のため実質1.2人/日の稼働だった
・テスト対象の機能自体に対してテスト分析 > テスト設計 > テスト実装を行なっていた

View Slide

294

View Slide

295

View Slide

296
ふりかえると・・・
・より良質なテストを作成するためベテランの
　テストエンジニアに自動テストのレビューを依頼
・テスト分析から行うことで必要なテスト観点を
　隅々まで洗い出し、網羅的な自動テストを作成
・網羅的に作成できた反面、リグレッションテストでは
　不要としていた観点も含む形になったため
　「リグレッションテストの手動実行工数削減」として　
はあまり貢献できなかったかたちに

View Slide

297

View Slide

298

View Slide

299

View Slide

300
・リグレッションテストの手動実行工数削減を優先して進めるため、
　テスト分析・テスト設計は行わず既存のテストケースを参照して
　自動テストを作成する方針に変更
・他業務と兼任だったメンバーが自動化専任に

View Slide

301

View Slide

302

View Slide

303
・既存のリグレッションテストにはない網羅的な観点を
　見ることがなくなった代わりに既存のテストケースを
　自動化できる速度が上昇し、手動実行工数の削減に繋がった
・mablを触ってから3ヶ月ほど経過した段階で
　「読みやすい自動テスト」について気づくことができ、
　改善に取り組み始めた

View Slide

304

View Slide

305

View Slide

306
◾7~9月（進行中）
・自動テスト作成と並行し、
　社内利用ガイドライン・ベストプラクティス・命名規則などを作成中

View Slide

307

View Slide

308
進行中のためふりかえりは割愛

View Slide

309
◾もしやり直せるなら？
・自動テスト未経験の場合はテスト分析・テスト設計から入らず、テスト実装に注力する
- ツールの使用感を学習しながら無理のないペースで着実に成果をあげることができる
・早い段階でデータの命名規則を決定、またテストの読みやすさを意識して自動テストを作成する
- 第二章で説明した通り、自動テストの品質を維持・向上させやすくするため

View Slide

310

View Slide

311
リグレッションテストの手動実行工数削減ではなく、
網羅的にテストすることを目的としたい場合は
テスト分析・テスト設計が必要になるかも
*リグレッションテストの内容次第になると思います

View Slide

312

View Slide

313
①導入の背景

View Slide

314
【第三章】ビットキーのmabl導入事例 - ③自動テスト作成のライフサイクル
自動テスト作成
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目
◾実際のスケジュール

View Slide

315
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

316
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目
・自動テストを作成する対象を決定する
・決定する際は下記事項を考慮して目標を設定する
- 項目数 (経験に応じて0.2h~1h/1項目)
- 機能の複雑さ (操作の工程が多い場合は多めに見積もる）
- 物理デバイスの使用有無（使用する場合は優先度を下げる）

View Slide

317
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

318
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

319
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

320
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

321
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目
物理デバイスとは？

View Slide

322
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

323
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目
ビットキーはスマートロックを
製造・販売している会社です！

View Slide

324
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目
そのためスマートロックを実際に操作して
解施錠を行うテストが多くあります

View Slide

325
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目
そのためスマートロックを実際に操作して
解施錠を行うテストが多くあります
（さすがに）mablでは物理的にスマートロックを
操作することはできないため優先度を下げています

View Slide

326
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

327
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

328
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
・自動テストを作成する
・進捗はデイリーで確認し、実装に詰まった箇所があれば共有し　
解決する
・作成する際は第二章で説明した下記点を意識する
- あらかじめ決定・合意を得た命名規則に則る
- テストのよみやすさを意識する
5日目

View Slide

329
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
解決する
5日目

View Slide

330
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
解決する
5日目

View Slide

331
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
解決する
5日目

View Slide

332
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
解決する
5日目

View Slide

333
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

334
プランニング
レビュー
指摘修正
マージ
・作成した自動テストをレビュアーに対面で披露する(1h)
・テスト対象のプロダクトQAの経験が豊富なテストエンジニア　　
にレビューを依頼
・各テストケースの手順・期待値が妥当かを確認する
・自動化できない箇所があれば根拠を添えて説明する
・実行時間が長い箇所やレビュー対象が多いときは
　動作をキャプチャして動画で見せるよう工夫して時間内に見て　
もらえるように工夫
1日目
~4日目
5日目
5日目
5日目

View Slide

335
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

336
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

337
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

338
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

339
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目
命名規則やテストの読みやすさをこの場で言及すると
時間が足りなくなってしまう場合が多いため、
レビュアーに見せる前にあらかじめ確認しておく

View Slide

340
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

341
プランニング
レビュー
指摘修正
マージ
・レビュアーから指摘を受けた箇所を修正する
1日目
~4日目
5日目
5日目
5日目

View Slide

342
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

343
プランニング
レビュー
指摘修正
マージ
・指摘内容の完了後、開発ブランチをマージする
・開発ブランチに不要なフローやスニペットが存在する場合、
　マージ直前に削除する
・コンフリクトが起きた際は該当データの作成者に意思疎通を　
必ず取った上で対応
1日目
~4日目
5日目
5日目
5日目

View Slide

344
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

345
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目

View Slide

346
プランニング
レビュー
指摘修正
マージ
1日目
~4日目
5日目
5日目
5日目
これを繰り返す・・・

View Slide

347
①導入の背景

View Slide

348
機能単位でテストを作成
テスト種別に応じたラベルを付与し、
一括閲覧・実行を可能に
[プロダクト名][テスト種別]機能名
と命名
ラベルは「テスト種別」「テストを作成したチー
ム」「slack通知用のラベル」の3種類を付与
【第三章】ビットキーのmabl導入事例 - ④実際の利用画面

View Slide

349
と命名

View Slide

350
と命名

View Slide

351
と命名

View Slide

352
テストの条件が特になければ最速で
実行を完了できる並列実行を採用
メンテナンスのしやすさを考慮し実行時間
が15分前後になるようテストを分割
*シナリオテストの場合は別途考慮が必要
分割する際は採番して順序をわかりやすく

View Slide

353

View Slide

354

View Slide

355
[プロダクト名][機能名]処理内容
とフローを命名
テスト観点を簡潔に書くことで
何をテストするかを振り返りしやすく
処理内容に応じてテストステップを
グルーピング
各処理はアノテート機能を利用して
理解しやすいように文章化

View Slide

356
グルーピング

View Slide

357
グルーピング

View Slide

358
グルーピング

View Slide

359
FLOWの中も処理が複雑な場合はグ
ルーピングを行う
期待値はアサーションによって得
られるので各処理の最後にアサー
ションを必ず挿入する
FLOWの処理内容が複雑になった場
合は属人化を防ぐために説明書を
同梱する

View Slide

360
同梱する

View Slide

361
同梱する

View Slide

362

View Slide

363
◾その他mablを導入して良かったこと
・ローコード・ノーコードツールと謳い文句にしている通り、プログラミング経験のない
　テストエンジニアでもサクサク自動テストを作成できた
- 割合的には・・・[Recording : 要素の検索 : JavaScriptスニペット = 7 : 2.8 : 0.2]
・「要素の検索」機能や「JavaScriptスニペット」機能が使いやすく、テストの幅を広げたい時に
　役立った
- 余談ですが簡単な計算や要素の取得であれば今ならChatGPTをはじめとするGenerative AIを使
うことで知識が浅くてもサッと作れた

View Slide

364
　役立った

View Slide

365
　役立った

View Slide

366
◾ChatGPT利用例
・画面上から取得したテキストの半角スペースを削除しないとアサーションができなかったため、　
ChatGPTにJavaScriptスニペットの作成をお願いしてみた事例

View Slide

367
　役立った
mablを入り口としてプログラミングに
ついて学ぶ人も出てくるかも？

View Slide

368
第三章完
（導入事例の紹介のためまとめは割愛・・・）

View Slide

369
目次
【テーマ】
①基本構成
②作成フロー
①導入の背景

View Slide

370

View Slide

371
◾個人的なふりかえり
・自動テストの扱いは未経験だったためはじめる前はきちんと使いこなせるか不安の気持ちで
　いっぱいでしたが、実際は謳い文句通りプログラミングに関する知識が浅くてもサクサクと
　自動テストを作成していくことができました！
・（今回あまり触れられませんでしたが...)特に良かったのはmablの公式ドキュメントが扱いやすく、　
またカスタマーサポートの方のレスポンスが早かったおかげで壁を感じてもすぐに乗り越えられる　
環境が整っていた点です！
・今まで手動のテスト実行で得た知識をスムーズに自動テストに落とし込むことができる
　ツールだと実感しています！

View Slide

372

View Slide

373

View Slide

374

View Slide

375
◾最後に
・これまで自動テストの作成方針やレビューにご協力していただいたビットキーの面々のみなさま、　
おかげでこのような場に立つことができました。ありがとうございました！
・また弊社ビットキー所属の岸田さん（パウリさん）に率先して諸々動いていただいてなければこの
場はなかったと思います！ありがとうございました！
・そしてこの場を設けるためにご協力していただいたmablers_JPの運営チームの皆様
　（ほなみんさん、はまさん、おだしょーさん）、各種サポート誠にありがとうございました！

View Slide

376
◾最後に

View Slide

377
◾最後に

View Slide

378
◾最後に

View Slide

379
End of File

View Slide

【mablers_JP - Online MeetsUp vol.4】Bitkeyでのmablを活用したテストエンジニアの思考プロセス機械化

【mablers_JP - Online MeetsUp vol.4】Bitkeyでのmablを活用したテストエンジニアの思考プロセス機械化

Roku Mikami

Other Decks in Programming

Featured

Transcript