Recommended
More Related Content
What's hot
What's hot (20)
Similar to 会社レベルの「テスト自動化普及」ミッションに立ち向かう話
Similar to 会社レベルの「テスト自動化普及」ミッションに立ち向かう話 (20)
会社レベルの「テスト自動化普及」ミッションに立ち向かう話
- 4. 前半
- 6. もうちょっと具体的な私のミッション 弊社のSEが アプリケーション開発において 主に単体、結合、システムテストフェーズで 自動テストに取り組んで 開発作業を改善できるようにすること 具体的にやってること • プロモーション（認知、啓蒙活動） • 教育、技術支援 • ツール提供、サポート • 情報収集、情報共有 5
- 9. どんな状態なのか 8
- 11. もう少しちゃんと調査しました 2017 ５００人アンケート ＆ 技術会議開催 「これからのテストを考える」 ほとんど 変化なし 38% 一部変化 47% 大きく変化 15% 5年前に 比べて ほとんど 変化なし 56% 一部変化 38% 大きく変化 6% 5年前に 比べて Q1. テストを取り巻く環境変化 Q2. テスト手法・技術変化 盛り上がった いろいろわかった Q3. 自動テストの実施 手動 77% 自動 19% 自動(高) 4% 10
- 13. わかったこと ＆ チャレンジ ① 自動テストできない理由 できるように改善する • 人がいない • 難しい • コストに見込めない • 製造は外注体制 • 力が及ばないことも多い （人、金、時間） • 文化やマインドを変えられる？ • 最終的にやるのは現場 できない こともある 12
- 14. わかったこと ＆ チャレンジ ② ちゃんと知らない 互いによく知る • 何が変わってきたのか （自動化だけではない） • 自動テストもけっこうやってる • ただし、レベルの幅は広そう • 情報は自然には集まらない • 意志(アンテナ)と手段(コネクション)必要 • そもそもテストの情報少ない • 知らせる相手側に興味がない 状況に 立ち向かう 13
- 15. わかったこと ＆ チャレンジ ③ 普及ってなんだろう？ ゴールを決めて計測する • どんなテストを？ • どれくらいすれば普及？ • 我々がどうなればいいのか 明確に宣言できなかった • 普及の定義をどうするか • 計測の方法や数字が難しい • KPI決めても数字だしても 腹落ちしない予感（多くても少なくても） ロジックの 組み上げ 14
- 16. 計測は大事 自動テストの実施率 ・ テストタイプや手段ごと(UT、E2E、性能、など) ・ テストツールの利用率 教育受講率、理解度 ・ 受講者のプロファイルや目的 状況の変化 ・ 事例の増加 ・ テスト組織や取り組みの立ち上がり 常時収集できるもの [ライセンス数、DL数、View数など] 収集しにいくもの [アンケート、ヒアリング] • イベントのついでに（教育終了後、ツールお試し期間終了後、など） • 回答率が最優先（30%目標） 何を計測 するか どう計測 するか 15
- 17. 静的解析 60 機能動作テスト 45 性能テスト 40 要求管理 3 ユニットテスト 23 Visualテスト 0 セキュリティテスト 83 テスト管理 6 APIテスト 12 クロスブラウザテスト 31 受入テスト 48 CI 18 自動化率の整理例 コーディング 単体テスト 結合テスト システムテスト 管理 テストタイプ、手段別の自動化率 ヒートマップ表現 16
- 18. 計測は大事 忘れてはいけないこと① 大切なのは普及率の計測の先の "効果の計測" • 自動テストを普及させる目的があるはず（コスト、品質改善など） • 実際は、効果＝適用数×効果係数 のようになるが・・・ • 現場に普及率を報告しても ・・・ 「へー」で終わるかも • 普及率は活動の状況表示。効果は活動の価値表示 • どういう言葉で報告するのかは、とても重要 17
- 19. 計測は大事 忘れてはいけないこと② 普及活動の存続がかかっている • ひらきなおってはいけない • 説明責任がある ・活動の価値が 評価しづらい ・売上ない ・「やめたら？」と 言われがち ・コスト削減対象 やめたら 絶対マイナス • "僕たちの存続が会社にとっての価値" というモチベーションと信念（驕ってはいけない） 18
- 20. 後半
- 21. やってること（おすすめ） 20
- 23. 活動 ①ツールを定める、いっそ作る INTARFRM テスト機能 JaSST'18 '19 Tokyo 参照 数字はきっとよくない DL数あっても使ってない 話が難しくなるので 報告たいへん • テストツールを作る • または、得意なツールを定める • そのツールの布教、サポート、教育などをやっていく KPI • ツールの利用率 • DL数、購入数 • 実際に使ってるのか調べる方法（アクティベーション、通知機能など） • ツールの自動化対応率 • 自動化対象とするテスト作業のどれくらいをカバーしているか 22
- 24. FUJITSU Software INTARFRM 自動テスト機能 ・ キャプチャ＆リプレイ ・ キーワード駆動 ・ データ駆動 ・ 画像比較 ・ レポート ・ CI 23
- 25. おすすめポイント ①ツールを定める、いっそ作る 特に移行性 ツールなくなった時に なんとかなるか 他ツールの利用状況も 調べて整理 住み分け、ツールマップ等の 整理はしょっちゅうやります 気をつけること • 数字がとりやすい ＆ わかりやすい • ツールに関係した施策をとりやすい • 社内向ツールの要求は高い（価格、テスト資産移行性） • ツールの開発、保守コスト • テストツール統一の話にならないようにする • ただし、社内の他ツールには目を光らせる（重複投資） • 社内チャージできるか？ 無償配布だと本当に使われてるかわからないかも 24
- 26. 活動 ②教育は早めに着手 全社e-Learning出来たら すごいけど、やりすぎ感も KPI • 入門編「テスト自動化ってなに？」 「ツール選定の方法」 • ライブ配信で500～1000人規模 • 実践編「テスト設計技法」 「テストツールハンズオン」 • 集合＆ワークショップ形式、30~40人規模、1,2か月に1回 • 教育開催、受講者数 • 教育アンケートによるテスト自動化の実態調査 • 理解度テスト 受講者数よりも アンケートによる実態調査 が重要 質の高い教育を 現場から需要があって 継続していること、を言う 25
- 27. 26
- 28. おすすめポイント ②教育は早めに着手 トップダウンで指示出やすい 技術会議でも一番反響 「まずは教育から」 油断するとコストかかる 特に教材づくり＆メンテ 気をつけること • 人材育成の施策として賛同されやすい • 現場にとって教育参加はハードル低い • アンケートを継続的にとりやすい、だから早めに • 直接的な効果が見えない • 継続施策なのでコストがかかっていないように見せる工夫 • メインの施策にしないほうがよい • 費用対効果とかそういう議論にならないようにしたい • なるべく無償。集客第一 教育部門の仕事だろ ってツッコまれる 27
- 29. 活動 ③事例は作ってからが本番 対象はアンケート、ツールの DLリストから抽出 KPI 事例はある程度の数あれば 量よりも質が大事 • 自動テストをしてるプロジェクトにヒアリング • 事例資料の作成 & 社内Webサイトでの公開 • 事例発表会、イベントなどを開催 • 事例化の数 • 事例資料のView数 経営層報告などに入れたり 活動報告に入れたり View数はわりと大事 みんなが知ってる事例は 価値がある 28
- 30. おすすめポイント ③事例は作ってからが本番 手始め、具体性、 他はやってるのか？ トップ層 ・・・1ページ ・規模/効果 未検討PJ ・・・3ページ ・自動化の内容(簡単に) 実施PJ ・・・10ページ↑ ・詳細/ノウハウ/課題 気をつけること • 現場からの要求は高い • 普及活動の価値を数字以外で表現できる • 現場とつながるチャンス、キーマンを見つけろ インパクト、増えてきた感 意見をくれそうな人 いっしょにやってくれそうな人 • 事例資料の数だけ増やしてもダメ • 相手によって必要な事例の書き方、ボリュームは違う • 事例対象のプロジェクト探しはアンテナはりつづける • 現場の負担にならないように • でも発表会での発表はしてほしい（費用も考える） 29
- 31. 【参考】テスト自動化の事例資料構成の例 プロジェクトのプロファイル テストで解決したい課題や期待 自動テストに至る背景や目的 活動、施策の内容 効果（課題が解決したか、期待に応えたか） 現場の声、今後の話 【補足】自動テストの評価 効果に出てこない（直接的な課題ではない）が評価すること （時間の短縮、コスト削減など） ページ構成 書く内容の例 備考 プロジェクトのプロファイル 簡単版ならば まとめて１,2ページ テストの課題 環境別テストが十分にできず、トラブル化 自動化の目的、期待 全ブラウザでのテスト 一部の有識者にテスト負荷が集中 活動、施策の内容 Seleniumでクロスブラウザテストの自動化 テストケースの作成規約作成 具体的に （ツール名、テクニック） 効果 期間内で全環境組合せテストを実施（網羅性） テストケースが可視化され、誰でもメンテ可能に 課題、期待にどう応えて いるのか 現場の声、今後など 「メンテは大変」「顧客説明がしやすくなった」 今後は他サブシステムにも展開予定 生の声っぽい感想 いいことも悪いことも 補 足 自動テストの評価 テスト工数の改善効果、ツールの習得性 効果とは別 ※後述 技術詳細 30
- 32. おまけの戦略 ２つ 31
- 34. 自動テストの効果を「コスト改善」と言わない工夫 効果はコスト改善だけじゃない • 逆にコストをかけて 網羅性、スピード、信頼性を上げる • テストの属人性を解消する 実際、コスト改善しないことも多い • テスト実装、メンテ等の過少見込み • ４回繰り返すと益転する？ 大抵、その前に見込みで言う 弊害 • コスト改善しない自動化はダメ • 自動テストがコスト削減施策化する 期待と事実のギャップ • やっぱり期待はコスト改善 • テストは工数のボリュームゾーン • "自動化" という言葉の魔力 • 「実際、コスト改善しないことも多い」は 理解が難しい 33
- 35. 自動テストの効果を「コスト改善」と言わない工夫 事例 • 章立ての工夫 • 見込みは効果に書かない 今後の展開あたりに書く • 複数の事例でバランス コストを言う事例、言わない事例 • 「自動化の目的」部分をしっかり書く 同じ期間でテストケースを増やし、網羅性が上がる • 内容聞くと、一番多い。PJ側も気づいてない • 注意点① 今まで不足してたの？ • 注意点② 手動テストの文化だと「テストケースは絞るもの」 活動報告 • 言わないわけにはいかない 期待値に対する説明責任がある • コスト改善だけにしない KPIを複数持つ • 言うとしてもコストが何かを明確に 人数？費用？単価？期間？ コスト改善と 言わないならば 34
- 37. 活動スケールを広げすぎない 広げすぎると 嘘っぽい 対象がぼやけて 数字もぼやける 狭いと「足らない」 って言うじゃん 「まぁ、数字はわかったけど」 とか言うし 細かく見ないと 結局、対策うてない できる範囲のスケールで • 継続的アンケートが可能な範囲 • 状況の推移（Q毎など）が大事 • 個々のプロファイルがつかめる範囲 • 状況の考察し甲斐がある ＆ 状態管理が可能 • 数よりセグメントを広げる • ビジネス形態別：SI、PKG、社内、保守 • 業種別：金融、公共、行政、文教、医療etc 36 広げすぎると・・・ • 施策や活動が大味、中途半端になる • 検討、悩みばかりが増える • 言い訳も増える
- 38. 【参考】調査対象・ターゲット設定 • ツールDL、資料DL、教育参加者を対象（メールアドレス入手済） • 全部で1000名越えるかどうか 施策に アクセスがあった 施策に アクセスがなかった 調査対象 調査対象 調査対象外 自動化した ⇒ OK 自動化した ⇒ OK 僕らの成果じゃないだけ 自動化せず ⇒ 原因調査＆対策 不明 ⇒ たぶん自動化せず ※アンケート無回答 自動化せず ⇒ ここが多いけど 調査は諦める 改善対策 調査の継続・お願い こちらからアクセス アクセスしてもらえるように 認知、宣伝の継続 37
- 39. 【参考】アクセスなし・自動化せず の分解 38 施策に アクセスがなかった 自動化せず 施策を知らない 施策を門前払い（聴く、試すまでもない） まだ、その時じゃない かたくなに変わらない、鎖国 本当にいらない 疲弊していて余裕がない • 現場は困ったらアクセスしてくる。その時にアクセス先として知っておいてもらうことが大事 • なのでアクセスしてきた層の調査と対策が大事。ここが弊社の自動化状況の縮図のはず
- 40. おわり 「うちの会社はけっこう自動化してる」 と言わせたい 重要案件の事例に食い込む 基盤再構築、Agile、DXなどのキーワードと共に 品質保証部門で重視される テスト不足、その対策としての自動テスト 会社の外堀からうめていく カンファレンスやプレス、他社協 定量的じゃない感覚から出る言葉が変わるのが超重要 39