自動テストの変遷_分断からコラボレーションの時代へ_.pdf

株式会社ヒューマンクレスト
⾃動テストの変遷
分断からコラボレーションの時代へ
浅⻩友隆

View Slide

© 2023 Human Crest Co., Ltd.
会社紹介
● ソフトウェアのテストを専業にしている
2

View Slide

会社紹介
3

View Slide

会社紹介
● 機能テスト、リグレッションテスト、APIテストなどを⾃動化
70
4

View Slide

⾃⼰紹介
Tomotaka Asagi
技術推進本部本部⻑
5
● 現在地︓マレーシア
● 趣味︓カメラ、ドライブ
● 職歴︓営業→開発→テスト→経営

View Slide

本⽇の事例に関して
● 決してだれかを⾮難しているわけではありません。
● ⾃動テストは、UI/Serviceのテストに限った話です。Unitテストは含まれて
おりません。
UI
Service
Unit
6

View Slide

AGENDA
本日のアジェンダ
7
1. ⾃動テストの変化
2. 4つの視点
3. 事例(成功/失敗)
4. Test Automation Circles
5. コラボレーション
6. コンテキスト
7. まとめ

View Slide

⾃動テストの変化
1.
8

View Slide

10年ほど前までの⾃動テストに対する考え⽅
9
テスト手動テスト自動テスト

View Slide

10年ほど前までの⾃動テストに対する考え⽅
10
テスト手動テスト自動テスト
⼿動テストを「⾃動化」

View Slide

現在のテスト
11
テスト
自動テスト
手動テスト

View Slide

現在のテスト
12
テスト
自動テスト
手動テスト
⾃動テストできない
＝⼈が⾏うべきテスト

View Slide

個⼈的に感じている変化
13

View Slide

テストに対する変遷
● 20年前
○ QCD コストをかければ品質があがる。しかしデリバリーが遅くなる
○ つまりテストが増える。⼿動テストを⾃動化することが主たる⽬的
○ ⼿動テストの実施コストを抑える為の⾃動テスト
○ レコード＆リプレイツール。⾃作のテストツール（WindowsAPIを駆使）
● 10年前
○ Web業界というか、Webアプリケーションが増える
○ Seleniumに出会う CI/CD 、DevOps
● 現在
○ QCD 品質を上げるとコストが下がり、デリバリーは早くなる
○ デプロイメントパイプラインの中で、⾃動テストが⼀般的になる
○ SaaS / AI を利⽤した⾃動テスト
14

View Slide

テストの変遷に対する雑感
● 20年前（2000年ごろ）
○ 開発とテストは分断されていた
○ そもそも開発プロセスにおいて、V字モデルの右側と左側は、完全に分離された
フェーズ
○ テスターはテストのプロフェッショナルとしての動きが期待され、テストに注⼒
していれば、問題はなかった
○ ⾃動テストは開発と別次元で定義されており、V字モデルの左側（上り）にある
テストケースを如何に⾃動化し、テスト実施速度を早くできるか︖（＝テスト⼯
程を早く終わらせるか︖）に重きが置かれた
○ 開発とテストは、対⽴関係にあることが多く、フェーズのゲート（⾨番）として
テストが重要視されるかどうかに関わっていた
15

View Slide

テストの変遷に対する雑感
● 10年前（2010年ごろ）
○ 開発とテストが歩み寄る。同時に⾏なわなければならないことが増えた
○ W字モデルなど、V字の前⼯程におけるテスト活動の明確化により、テスト活動
が先んじて⾏われるプロジェクトが増える
○ ⾃動テストは、相変わらず⼿動テストを⾃動化すること
○ しかし、⾃動テストにするためには、⾃動テスト⽤のテスト設計（⼿順や、期待
値の明確化、環境の準備）などが必要であると認識されはじめる
● 現在
○ 開発プロセスにAgileが採⽤され、⾃動テストは当たり前の時代
○ 組織構造、役割の変化（テスター、SET 、SRE、Developer、テストエンジニア
、QA）
16

View Slide

４つの視点
2.
17

View Slide

⾃動テストが変化した、４つの視点
18
⾃動テスト期待
開発プロセス
技術
組織

View Slide

が変わった
プロセス
19

View Slide

Waterfall → Agile
20

View Slide

開発プロセスの変化
21
要件定義
基本設計
プログラム設計
総合テスト
運⽤テスト
詳細設計結合テスト
単体テスト
コーディング
品質の埋め込みプロセス品質の確認・検証プロセス
Ｖ字モデル
2017年 Katrina Clokie, A Practical Guide to Testing in DevOps
Agile / DevOps

View Slide

が変わった
期待されること
22

View Slide

Bug → Feedback
23

View Slide

期待されていることの変化（JSTQB FLシラバス「テストとは何か︖」から）
24
● Version2011.J02
○ ⽋陥を摘出する。
○ 対象ソフトウェアの品質レベルが⼗
分であることを確認する。
○ 意志決定のための情報を⽰す。
○ ⽋陥の作りこみを防ぐ。
(原⽂ママ）
● Version2018V31.J03
○ 要件、ユーザーストーリー、設計、およびコードな
どの作業成果物を評価することによって⽋陥を防ぐ
。
○ 明確にしたすべての要件を満たしていることを検証
する。
○ テスト対象が完成したことを確認し、ユーザーやそ
の他ステークホルダーの期待通りの動作内容である
ことの妥当性確認をする。
○ テスト対象の品質に対する信頼を積み重ねて、所定
のレベルにあることを確証する。
○ ⽋陥や故障を発⾒し、ソフトウェアの品質が不適切
になるリスクレベルを軽減する。
○ ステークホルダーが意志決定できる、特にテスト対
象の品質レベルについての⼗分な情報を提供する。
○ 契約上、法律上、または規制上の要件や標準を遵守
する、そして/またはテスト対象がそのような要件
や標準に準拠していることを検証する。
バグを⾒つける︕
バグを⾒つけた後
〇〇する

View Slide

が変わった
技術
25

View Slide

Scope & Speed
26

View Slide

スコープとスピードを変えた、様々な技術的要因
27
Before After
テスト対象
モノリス
UI
マイクロサービス
マイクロフロントエンド
API
テスト環境
オンプレ
ローカル
クラウド
仮想化
コンテナ化
テスト実⾏ローカルツール
OSS
テストフレームワーク
SaaS
スコープ
⼤→⼩
広い→狭く
スピード
より早く
より短く

View Slide

変化した結果
● テストだけでは、成り⽴たない
○ 開発の中、運⽤の中、デプロイメントパイプラインに統合する
○ 開発・テストエンジニアが担う領域の拡⼤
● 必要技術領域の拡⼤
○ 環境構築（OSS、仮想化、コンテナ化）
○ テスト技術（技法、設計）
○ プログラミング技術（フレームワーク、⾔語）
● テスト設計
○ UIの⾃動テストケースでも
■ 独⽴性の確保
■ 冪等性の確保
28

View Slide

が変わった
組織
29

View Slide

開発エンジニアとテストエンジニア
30
開発開発
（兼テスト）
開発
テスト
開発テストテスト
開発テスト
開発
テスト

View Slide

皆さん、どのあたりですか︖
31

View Slide

⾃動テストやってますか︖
32

View Slide

「⾃動テストは続かない」
33

View Slide

「⼀回チャレンジしたんだけどね。」
34

View Slide

なぜ、⾃動テストという
取り組みが失敗するのか︖
35

View Slide

成功事例
3.
36

View Slide

成功している事例
● 事例1
○ テスト対象︓BtoB Webシステム（グループウェア）
○ テストタイプ︓シナリオテスト（40シナリオ）
○ 実⾏トリガー︓定期実⾏毎⽇0時
○ IF︓PCブラウザ（Chrome, Firefox, Edge）
● 事例2
○ テスト対象︓BtoC Web、スマホ向けシステム（HR系）
○ テストタイプ︓シナリオテスト（30シナリオ）
○ 実⾏トリガー︓定期実⾏毎⽇8時、14時
○ IF︓PCブラウザ（Chrome）スマホブラウザ（Chrome, Safari）スマホアプリ
37

View Slide

● 事例3
○ テスト対象︓BtoC スマホアプリ
○ テストタイプ︓機能テスト（26ケース）
→チェックポイント数百箇所
○ 実⾏トリガー︓定期実⾏毎⽇0時,12時
○ IF︓スマホアプリ（Android, iPhone）
● 事例4
○ テスト対象︓BtoB Webシステム（リアルエステート）
○ テストタイプ︓機能テスト（260ケース）
○ 実⾏トリガー︓Push時
○ IF︓Webブラウザ（docker-selenium）
38

View Slide

Test Automation Circles
39

View Slide

層項⽬事例1 事例2 事例3 事例4
コア⽬的
機能が正常に動いている
こと
ユーザに価値が届いてい
ることを確かめる
機能が動作していること
バグが流出しないこと
リグレッションが発⽣し
てないこと
開発者がすぐに修正でき
ること
コンセプト戦略
範囲
設計
メイン機能
シナリオテスト
正常系のみ
メイン機能のみ
シナリオテスト
正常系のみ
全機能
機能テスト
境界値含む
主要機能
データパターン網羅
アーキテクチャ CI/CD
ツール
フレームワーク
環境
⾃動テスト専⽤環境
クラウド
Selenium, Java
開発環境、本番環境
スマホ実機アプリ
スマホ実機ブラウザ
Selenium, Java
開発環境、ステージング
スマホ実機アプリ
Jenkins,bitrise
Cucumber, Appium
ステージング環境
Jenkins
Junit, Selenide
モニタリングとコン
トロール
⾃動化システム
実⾏
分析
可視化
定期実⾏、分析
Dashboard
Mail
Dashboard
Mail
Dashboard
Slack
Push時実⾏
Slack→レポート
ベースリソース
チーム
スキルセット
⽂化
開発チーム
テストチーム
ステークホルダー
DEVチーム
ステークホルダー
開発チーム
QAチーム
QAチーム
インフラチーム
40

View Slide

層項⽬事例1 事例2 事例3 事例4
コア⽬的
◯ ◯ ◯ ◯
範囲
設計
△
⼿動→⾃動
◯ △
設計が✗
◯
ツール
環境
✗
CI/CDなし
✗
CI/CDなし
◯ ◯
モニタリングとコン
トロール
実⾏
分析
可視化
◯ ◯ ◯ ◯
チーム
スキルセット
⽂化
◯ ◯ ◯ ◯
41

View Slide

なぜ成功しているのか︖
● デベロッパーが⾃動テストの結果を欲している。
● バグが発⽣した際の、⼿順が明確になっている。
42

View Slide

失敗事例
3.
43

View Slide

定着しなかった事例
● 事例5
○ テスト対象︓BtoB Webシステム（IoT）
○ テストタイプ︓機能テスト
○ テストケース数︓60
○ 実⾏トリガー︓デベロッパーが必要な時
○ IF︓Webブラウザ（Chrome）
● 事例6
○ テスト対象︓BtoC Webシステム（管理系）
○ テストタイプ︓機能テスト
○ テストケース数︓45
○ 実⾏トリガー︓Merge時選択
○ IF︓Webブラウザ（docker-selenium,chrome）
This Photo by Unknown Author is licensed under CC BY-NC
44

View Slide

層項⽬事例5 事例6
コア⽬的
機能が正常に動いていること
リグレッションが発⽣してないこと
開発者がすぐに修正できること
範囲
設計
メイン機能
機能テスト
メイン機能テスト
画⾯の正常系、および画⾯遷移
ツール
環境
開発環境
ローカル
Selenium,Java
ステージング環境
クラウド
Selenide,Java
モニタリングとコ
ントロール
実⾏
分析
可視化
開発者が都度実⾏
（テストスクリプトの作成、メンテはテストチーム
が⾏う。）
merge時実⾏（実⾏時間が20分超え）
Slack→レポート
チーム
スキルセット
⽂化
開発チーム
↕ 分断
テストチーム
設計チーム
開発チーム
インフラチーム
テストチーム（蚊帳の外）
45

View Slide

層項⽬事例5 事例6
コア⽬的
◯ ◯
範囲
設計
◯ ◯
ツール
環境
◯ ◯
モニタリングとコ
ントロール
実⾏
分析
可視化
◯ △
チーム
スキルセット
⽂化
✗ △
46

View Slide

なぜ、⾃動テストという
取り組みが失敗するのか︖
47

View Slide

4.
48

View Slide

49

View Slide

© 2023 Human Crest Co., Ltd. 50
⽬的
実⾏
レポーティング
結果分析
ツ
ー
ル
フ
レ
ー
ム
ワ
ー
ク
環
境
CI/CD
ス
コ
ー
プ
戦略
設
計
リソースチーム
⽂化
スキルセット
テスト⾃動化
ソリューション

View Slide

⽬的
実⾏
結果分析
ツ
ー
ル
フ
レ
ー
ム
ワ
ー
ク
環
境
CI/CD
ス
コ
ー
プ
戦略
設
計
⽂化
スキルセット
テスト⾃動化

View Slide

⽬的
実⾏
結果分析
ツ
ー
ル
フ
レ
ー
ム
ワ
ー
ク
環
境
CI/CD
ス
コ
ー
プ
戦略
設
計
⽂化
スキルセット
テスト⾃動化
Why︖

View Slide

⽬的
実⾏
結果分析
ツ
ー
ル
フ
レ
ー
ム
ワ
ー
ク
環
境
CI/CD
ス
コ
ー
プ
戦略
設
計
⽂化
スキルセット
テスト⾃動化
Why︖
How︖

View Slide

⽬的
実⾏
結果分析
ツ
ー
ル
フ
レ
ー
ム
ワ
ー
ク
環
境
CI/CD
ス
コ
ー
プ
戦略
設
計
⽂化
スキルセット
テスト⾃動化
Why︖
How︖
What︖

View Slide

⽬的
実⾏
結果分析
ツ
ー
ル
フ
レ
ー
ム
ワ
ー
ク
環
境
CI/CD
ス
コ
ー
プ
戦略
設
計
⽂化
スキルセット
テスト⾃動化
Why︖
How︖
What︖
Real

View Slide

⽬的
実⾏
結果分析
ツ
ー
ル
フ
レ
ー
ム
ワ
ー
ク
環
境
CI/CD
ス
コ
ー
プ
戦略
設
計
⽂化
スキルセット
テスト⾃動化
Why︖
How︖
What︖
Real
Base

View Slide

⽬的
ツ
ー
ル
フ
レ
ー
ム
ワ
ー
ク
環
境
CI/CD
ス
コ
ー
プ
戦略
設
計
Why︖
How︖
What︖
実現にむけて、利害関係者で話し合い、
合意を得ることが重要な部分

View Slide

実⾏
結果分析
テスト⾃動化
Real
テスト⾃動化を実現し、
運⽤していく部分
↓
⾃動テストにオーナーシップを持って取り組む⼈の存在が必要

View Slide

それでも失敗する
59

View Slide

深い溝がある
ときがある
責任範囲の違いから、無関⼼
誰かがやってくれるだろう
ちょっと⾯倒なことになりそうだから、、

View Slide

⽂化
スキルセット
深い溝がある
ときがある
Base

View Slide

リソース（⼈）チーム
⽂化
関係者、チーム内・外のコラボレーションができてない
⽂化が育たない
スキルセット
Base
様々なコンテキスト（環境や、社会、規則など）への理解

View Slide

層項⽬ 1 2 3 4 5 6
コア⽬的
◯ ◯ ◯ ◯ ◯ ◯
範囲
設計
△ ◯ ◯ ◯ ◯ ◯
ツール
環境
✗ ✗ ◯ ◯ ◯ ◯
モニタリングとコントロー
ル
実⾏
分析
可視化
◯ ◯ ◯ ◯ ◯ △
チーム
スキルセット
⽂化
◯ ◯ ◯ ◯ ✗ △
何が違うのか︖
63

View Slide

コラボレーション
5.
64

View Slide

コラボレーションとは
● Wikipedia
○ コラボレーション（英: collaboration）は、「共に働く」「協⼒する」の意味で
、「共演」・「合作」・「共同作業」・「利的協⼒」を指す語である。⽇本語で
はコラボと略されることが多い。
● IT⽤語辞典
○ コラボレーションとは、協⼒、協調、協業、共同作業、共同制作、合作などの意
味を持つ英単語。複数の⼈や集団の間で協⼒して⼀つの作業を⾏うことや、その
結果⽣み出された作品などのことを指す。俗に「コラボ」と略されることもある
。
65

View Slide

とある休⽇、妻との会話で、、
私「コラボレーションって⼤事だよね」（つぶやいただけ、、）
妻「そうだよね、信頼関係がないとできないよね︕」
私「えっ︖ どういうこと︖」
妻「お互いが対等な⽴場で、お互いが信頼してないとコラボレーションできないって
こと。」
私「何︕ その即答は︖ どこからの引⽤︖」
妻「作業療法の話」
66

View Slide

● 協働（Collaboration）には、相互理解を基盤とした⽬標の共有が必要です。
● 協働関係は、⽬標達成のために分担された業務を遂⾏するのではなく、相⼿
を尊重し合い、それぞれの考えや意⾒を対等に表現し合い、共に取り組んで
いく関係です。
67
吉川ひろみ・鈴木洋介.『プロセスモデルで読み解く作業療法』.CBR.2019,120P
クライアントとその家族、ケアマネージャー、医師、
地域介護関連職の⽅々、それぞれが、対等な⽴場でサ
ポート、介⼊していくことが重要になる。

View Slide

共通の⽬的を持ち
お互いに信頼し
共に取り組んでいる
68

View Slide

誰とコラボレーション
69
開発 QA

View Slide

70
開発 QA 運⽤

View Slide

71
開発
QA
運⽤

View Slide

72
開発
SET
SRE

View Slide

成功する要因
● 共通の⽬的であること
● 成果がみえるようにすること
● 関係者全員で⽬的と成果を共有していること
● ⼩さな成功を積む
● ⼈、チームの関係性を良好にする橋渡し、担当者を置く
✗ だめなこと
⾃動テストを⽬的にする（開発側が興味をなくす）
73

View Slide

コンテキスト
6.
74

View Slide

コンテキスト
● どんな対象物なのか︖
○ プロダクト要素︓採⽤しているアーキテクチャ︖
○ 環境要素︓開発環境、テスト環境、本番環境は、オンプレ・クラウド︖
● どのような進め⽅をしているのか︖
○ プロセス要素︓WF・Agile、ビルド、デプロイ、リリースタイミング
● どんな⼈が集まっているのか︖
○ スキル要素︓利⽤スキル、習得しているスキル、習得したいスキル
○ チーム要素︓同僚、他部署、ステークホルダーなど関連する⼈々、関連性
75

View Slide

コンテキスト
● どのような考え⽅があるのか︖
○ ⽂化的要素︓社内の⾵⼟・新しもの好き、保守的
○ 組織的要素︓組織、会社の規則、価値観
● 周囲の状況はどうなのか︖
○ 場所的要素︓住んでいる場所、経済、歴史的背景
● 現在、過去に何を⾏ったか︖
○ 時間的要素︓取り組んだ内容︖
● どのような課題を持っているか︖
○ 課題要素︓何を問題と思っていて、どうやって解決したいと考えているのか︖
■ やりたいと思っていること
■ やらなければならないこと
■ やることが期待されていること
76

View Slide

コンテキストの変化に気を配る
● 世の中の変化に応じてやりたいことが変わっていく場合がある
○ WF→Agile
○ バグの発⾒→⽣産性向上
○ バックエンド→フロントエンド
77

View Slide

まとめ
7.
78

View Slide

まとめ
● エンジニアは、様々な⼈々（職種、役割、チームを越えて）とコラボレーシ
ョンしなければならない。
● コラボレーションとは、共通の⽬標を持ち、お互いに信頼し、取り組んでい
くことである。
● コンテキストを知ることが近道になる
○ 時代いま
○ 会社の⽂化、規則、⽅針
○ チームのルールや価値観に沿っているか
○ 個⼈のスキル、習慣、価値観
○ 課題
79
⾒えるところだけでなく、⾒えないところが⼤事

View Slide

あるがままでなく、あるべき世界をみろ
See the world not as it is,
but as it should be.
80

View Slide

ご清聴ありがとうございました
81

View Slide

自動テストの変遷_分断からコラボレーションの時代へ_.pdf

自動テストの変遷_分断からコラボレーションの時代へ_.pdf

atom

More Decks by atom

Other Decks in Business

Featured

Transcript