2月17日の（他の会社の方も含む）社内向けセッションの資料、15分～20分程度の内容です。 テストを自動化するには、マネージャーが「自動化できる」ということを知っていること、それができる人材をアサインし、予算と期間を「自動化を前提に」考えることが必要です。もちろん、自分たちのビジネスにそれが必要なのか？どう力を入れていくべきか？経営層や管理層が強くイメージする必要があります。 また、インフラエンジニアにも、開発者がどのように品質を管理しているか？イメージできるように、開発プロセスの全体像を解説しています。

1. 開発ビギナーだけじゃない！
インフラエンジニア & マネージャー にも知ってほしい
テスト自動化と品質管理
1
アバナード株式会社 マネージャー（ Microsoft MVP ）古賀 慎一
2017年2月17日（金）
Copyright© 2017 Shin-ichi Koga All Rights Reserved.

2. このセッションのゴール
テストによってどのように品質を保証するか？イメージする
Visual Studio を使った開発工程と品質管理をイメージする
 自社案件に採用できるか？検討できるようになる
自分のチームも DevOps で低コスト・高品質な開発を行える！
2
インフラエンジニアでも
マネージャーでも！

3. 自己紹介
3
古賀 慎一
Microsoft MVP for Visual Studio and Development Technologies
アバナード株式会社 マネージャー
 Visual Studio を使用した開発標準の策定・EVM による進捗管理・教育
 前職ではクラウドサービス開発のリリース管理で TFS 導入事例
http://tech.surviveplus.net/archives/1114
 「仕組み」作りで 如何に高品質・低コストで早い開発を実現できるか？
 書籍執筆 日経BP社より発売中

4. アジェンダ
 品質管理と開発工程の全体像
 トレーサビリティ（追跡可能性）
 テストの効率化の重要性
 テスト自動化（コスト０で何度でも再テスト）
 レポート効率化（コスト０で報告書）
 自動ビルド・自動テスト・自動リリース（DevOps）
4
このスライドは SlideShare で共有します ( http://www.slideshare.net/shinichikoga355/ )

5. 品質管理と開発工程の全体像
開発工程
成果物
5
WBS
（作業内容・日付）
設計・設定値・
プログラムコード
テスト
計画・結果
リリース
計画・結果
誰が？何を？
いつ？どうする？
作るもの・作ったもの 品質管理 使ってもらえる状態
（いわゆる本番）
全て VSTS/TFS へ
Visual Studio Team Services / Team Foundation Server
 全体を Visual Studio (VS/VSTS/TFS）で管理できる

6. 全体をVSで管理できると
何が
嬉しいの？ 6

7. トレーサビリティ（追跡可能性）
 全てがリンクしているので、問題をトレースできる
7
スケジュール
Iteration
設定・プログラム
Code (Change Set)
テスト
Test
リリース
Release
タスク・設計
Backlog / Task

8. テストで問題が発見されたとき
 これ・ここが数秒でわかることが大切 （全てVSで管理すると容易） 8
スケジュール
Iteration
設定・プログラム
Code (Change Set)
テスト
Test
リリース
Release
タスク・設計
Backlog / Task
スケジュール
Iteration
設定・プログラム
Code (Change Set)
テスト
Test
リリース
Release
タスク・設計
Backlog / Task
問題ここ
で問題がおきた
これ
が問題だった
これ
が問題だった
いつ
やりなおす？
どう
設計変える？ 直す
新 新 新 再

9. テストの効率化の重要性
 テストで問題があると必ずテストをもう一度やりなおす
 テストは かかる時間 を "0“ で繰り返したい 9
リリース
実装・修正
設定変更
テスト
問題

10. 全てのテストをやり直すのがベストだが… なかなか難
 しかし、機能を変更したら必ず関係するテストが全てやり直しになる
 これは省略できない
10
機能
設計・設定・プログラムコード etc..
単体テスト
機能の動作のパターンを網羅
F1 ○○する機能1
F2 △△する機能2
F3 □□する機能3
UT1-1 機能1が○○
UT1-2 機能1が××
UT1-3 機能1が☆☆
IT1 画面1で○○
IT2 画面2で○○
IT3 画面2で○○
機能 : 単体テスト
1 : N
機能 : 結合テスト
N : 1
結合テスト
複数の機能を使う画面操作など

11. 全てのテストをやり直すのがベストだが… なかなか難
 しかし、機能を変更したら必ず関係するテストが全てやり直しになる
 これは省略できない 複雑に影響しあっているのであまり減らない
11
機能
設計・設定・プログラムコード etc..
結合テスト
複数の機能を使う画面操作など
F1 ○○する機能1
F2 △△する機能2
F3 □□する機能3
UT1-1 機能1が○○
UT1-2 機能1が××
UT1-3 機能1が☆☆
IT1 画面1で○○
IT2 画面2で○○
IT3 画面2で○○
機能 : 単体テスト
1 : N
機能 : 結合テスト
N : 1
問題修正
影響
単体テスト
機能の動作のパターンを網羅

12. テストを省略できなければ
テストを自動化
すればいいじゃない？
12

13. テスト自動化（コスト０で何度でも再テスト）
 出来るだけプログラムでプログラムをテストする
13
機能
設計・設定・プログラムコード etc..
単体テスト
機能の動作のパターンを網羅
結合テスト
複数の機能を使う画面操作など
C#, VB,
HTML, JavaScript, PowerShell ..
C#, VB
Unit TestCode
C#, VB
Coded UI Test
テストケース
操作手順・期待結果
Test Plan
プログラムでプログラムをテスト プログラムでプログラムをテスト
手動操作でプログラムをテスト
自動自動
手動

14. 単体テストでパターンを網羅する
 テスト数はコード行数ではなく機能の入力値のバリエーションに注目 14
機能
設計・設定・プログラムコード etc..
単体テスト
機能の動作のパターンを網羅
Unit Test
Code
result = Function1( args )
結果 機能1 入力値
10 = Function1( 100 ) ですか？
1 = Function1( 10 ) ですか？
0 = Function1( 0 ) ですか？
Function1( -1 ) はエラーですか？
×10～100～数千～数万 単体テスト機能1つにつき
自動

15. 結合テストで複数の機能の連携を確認
 単体テストで網羅が保証されている前提で結合されていることを試験 15
機能
設計・設定・プログラムコード etc..
Code
複数の機能
を使用する画面など
結合テスト
複数の機能を使う画面操作など
Coded UI Test
操作の手順と期待される動作
1. 機能を使用している画面を開く ⇒ 画面が表示
2. テキストを入力する ⇒ ボタンが押せるようになる
3. ボタンをクリックする ⇒ “送信中” と表示される
：
Test Plan
テストケース
1 テストケース複数の機能につき
×10～100～テストケース（例えば）画面１つにつき
自動手動

16. どれだけテストがコード化されているか？
 自動化するには、出来るだけプログラムでプログラムをテストする
※説明のわかりやすさのために「単体テスト」と「結合テスト」と表現していますが、Test Plan の手動テストで「単体テスト」を扱う場合もあります
※ Visual Studio 用語の 「Unit Test」 と日本の「単体テスト」が必ずしも一致しない点に注意
16
Unit Test
自動
Coded UI Test
Test Plan
自動
手動
全自動 = コスト “0”（ほぼ）
再テストのたびにコストがかかる
単体テスト
結合テスト
×2, ×3, ×4 …
テスト作るコスト 大
テスト作るコスト 小
テスト作るコスト 中

17. プログラムコードの 何％ がテストされているか？
 UnitTest を実行すると、
テスト時に実行されたコード・実行されなかったコードが塗り分けられる
 VS2017（現在RC）ではコード書きながらわかる（Live Unit Test）
 コードカバレッジ80%を目指す
100％でもバグがないことを保証できるわけじゃないが、
100%でなければテストされていないコードがあることがわかる
 VS によって自動生成される「絶対実行されない部分」もあるので
17参考：コード カバレッジを使用した、テストされるプロジェクトのコード割合の確認
https://msdn.microsoft.com/ja-jp/library/dd537628.aspx

18. レポート効率化（コスト０で報告書）
 VSTS/TFSダッシュボードに表示
 単体テストが全て成功しているか？
 手動テストが何件中何件成功？実施済みか？
 問題があれば、クリックしてトレース・修正・再テストへ
 どうしても必要なら VSTS/TFS からエクスポートして Excelで報告書を
VS拡張機能「TeamReportPlus」
18
https://marketplace.visualstudio.com/items?itemName=SHIN-ICHIKOGA.TeamReportPlus

19. 自動ビルド・自動テスト・自動リリース（DevOps）
 プログラムコードを変更したら自動的にテスト、OKなら自動的にリリース
 世界の最先端の開発チームでは DevOps 2.0
 プログラムを1日に何度もリリース
 機能を作成した日に、すぐユーザーに使ってもらえる（A・Bテストも可能）
 あるいは検証環境ですぐ動作確認ができる
 VS・VSTS・TFSで開発の全行程を管理していれば可能
もちろん他社製品・OSSもあります。考え方は同じ 19

20. プログラム開発だけじゃない
設定もサーバー構築も
PowerShellで行えば
20
インフラエンジニアでも
DevOpsできます！

21. DevOpsできるかどうか？は
マネージャーが
「そうする」チームを
作れるかどうか？です
経営者の役割でもあります 21

22. まとめ
 Visual Studioで開発の全行程を管理してトレーサビリティを
 テストを自動化してコスト0で何度でも再テストを
 レポートもコスト0で（できればお客様にVSTS/TFS画面を見てもらおう！）
 プログラム開発だけじゃない！インフラエンジニアでもDevOps
 自動テスト・自動リリースをできるチームを作るのはマネージャーの仕事
22

23. 書籍とスライド資料のCM
 チーム開発の教科書
http://amzn.to/2euUzrW
 はじめてのASP.NET SPA開発入門
http://amzn.to/2eQKaUa
 ちゃんとした C# プログラムを書けるようになる実践的な方法
～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
http://www.slideshare.net/shinichikoga355/starting-c-sharp
テスト・リリースを自動化できる開発はトレーニングが必要な技術です！
23

24. 24Copyright© 2016 Shin-ichi Koga All Rights Reserved.