開発ビギナーだけじゃない！インフラエンジニア & マネージャー...
TRANSCRIPT
1
開発ビギナーだけじゃない！
インフラエンジニア & マネージャー にも知ってほしい
テスト自動化と品質管理
アバナード株式会社 マネージャー（ Microsoft MVP ）古賀 慎一
2017 年 2 月 17 日（金）
Copyright© 2017 Shin-ichi Koga All Rights Reserved.
2
このセッションのゴール
テストによってどのように品質を保証するか？イメージする
Visual Studio を使った開発工程と品質管理をイメージする
自社案件に採用できるか？検討できるようになる
自分のチームも DevOps で低コスト・高品質な開発を行える！
インフラエンジニアでもマネージャーでも！
3
自己紹介古賀 慎一
Microsoft MVP for Visual Studio and Development Technologies
アバナード株式会社 マネージャー
Visual Studio を使用した開発標準の策定・ EVM による進捗管理・教育
前職ではクラウドサービス開発のリリース管理で TFS 導入事例
http://tech.surviveplus.net/archives/1114
「仕組み」作りで 如何に高品質・低コストで早い開発を実現できるか？
書籍執筆 日経 BP 社より発売中
4
アジェンダ
品質管理と開発工程の全体像
トレーサビリティ（追跡可能性）
テストの効率化の重要性
テスト自動化（コスト０で何度でも再テスト）
レポート効率化（コスト０で報告書）
自動ビルド・自動テスト・自動リリース（ DevOps ）
このスライドは SlideShare で共有します ( http://www.slideshare.net/shinichikoga355/ )
5
品質管理と開発工程の全体像
開発工程
成果物WBS
（作業内容・日付）設計・設定値・
プログラムコードテスト
計画・結果リリース計画・結果
誰が？何を？いつ？どうする？
作るもの・作ったもの 品質管理 使ってもらえる状態（いわゆる本番）
全て VSTS/TFS へVisual Studio Team Services / Team Foundation Server
全体を Visual Studio (VS/VSTS/TFS ）で管理できる
6
全体を VS で管理できると
何が嬉しいの？
7
トレーサビリティ（追跡可能性）
全てがリンクしているので、問題をトレースできる
スケジュール
Iteration
設定・プログラムCode (Change
Set)テスト
TestリリースRelease
タスク・設計Backlog / Task
8
テストで問題が発見されたとき
これ・ここが数秒でわかることが大切 （全て VS で管理すると容易）
スケジュール
Iteration
設定・プログラムCode (Change
Set)テスト
TestリリースRelease
タスク・設計Backlog / Task
スケジュール
Iteration
設定・プログラムCode (Change
Set)テスト
TestリリースRelease
タスク・設計Backlog / Task
問題ここで問題がおきた
これが問題だった
これが問題だった
いつやりなおす？
どう設計変える？ 直す
新 新 新 再
9
テストの効率化の重要性
テストで問題があると必ずテストをもう一度やりなおす
テストは かかる時間 を "0“ で繰り返したい
リリース実装・修正
設定変更テスト
問題
10
全てのテストをやり直すのがベストだが… なかなか難
しかし、機能を変更したら必ず関係するテストが全てやり直しになる
これは省略できない
機能設計・設定・プログラムコード etc..
単体テスト機能の動作のパターンを網羅
F1 ○○ する機能 1F2 △△ する機能 2F3 □□ する機能 3
UT1-1 機能 1 が○○
UT1-2 機能 1 が ××UT1-3 機能 1 が☆☆
IT1 画面 1 で○○
IT2 画面 2 で○○
IT3 画面 2 で○○
機能 : 単体テスト 1 : N
機能 : 結合テスト N : 1
結合テスト複数の機能を使う画面操作など
11
全てのテストをやり直すのがベストだが… なかなか難
しかし、機能を変更したら必ず関係するテストが全てやり直しになる
これは省略できない 複雑に影響しあっているのであまり減らない
機能設計・設定・プログラムコード etc..
結合テスト複数の機能を使う画面操作など
F1 ○○ する機能 1F2 △△ する機能 2F3 □□ する機能 3
UT1-1 機能 1 が○○
UT1-2 機能 1 が ××UT1-3 機能 1 が☆☆
IT1 画面 1 で○○
IT2 画面 2 で○○
IT3 画面 2 で○○
機能 : 単体テスト 1 : N
機能 : 結合テスト N : 1
問題修正
影響
単体テスト機能の動作のパターンを網羅
12
テストを省略できなければ
テストを自動化すればいいじゃない？
13
テスト自動化（コスト０で何度でも再テスト）
出来るだけプログラムでプログラムをテストする
機能設計・設定・プログラムコード etc..
単体テスト機能の動作のパターンを網羅
結合テスト複数の機能を使う画面操作など
C#, VB, HTML, JavaScript, PowerShell ..
C#, VB
Unit TestCode
C#, VB
Coded UI Test
テストケース
操作手順・期待結果
Test Plan
プログラムでプログラムをテスト
プログラムでプログラムをテスト
手動操作でプログラムをテスト
自動自動
手動
14
単体テストでパターンを網羅する
テスト数はコード行数ではなく機能の入力値のバリエーションに注目
機能設計・設定・プログラムコード etc..
単体テスト機能の動作のパターンを網羅
Unit Test
Code
result = Function1( args )結果 機能 1 入力値
10 = Function1( 100 ) ですか？
1 = Function1( 10 ) ですか？
0 = Function1( 0 ) ですか？
Function1( -1 ) はエラーですか？
×10 ～ 100 ～数千～数万 単体テスト機能 1 つにつき
自動
15
結合テストで複数の機能の連携を確認
単体テストで網羅が保証されている前提で結合されていることを試験
機能設計・設定・プログラムコード etc..
Code
複数の機能を使用する画面など
結合テスト複数の機能を使う画面操作など
Coded UI Test
操作の手順と期待される動作1. 機能を使用している画面を開く ⇒ 画面が表示
2. テキストを入力する ⇒ ボタンが押せるようにな
る
3. ボタンをクリックする ⇒ “送信中” と表示される
：
Test Plan
テストケース
1 テストケース複数の機能につき
×10 ～ 100～テストケース（例えば）画面１つにつき
自動手動
16
どれだけテストがコード化されているか？
自動化するには、出来るだけプログラムでプログラムをテストする
※説明のわかりやすさのために「単体テスト」と「結合テスト」と表現していますが、 Test Plan の手動テストで「単体テスト」を扱う場合もあります
※ Visual Studio 用語の 「 Unit Test 」 と日本の「単体テスト」が必ずしも一致しない点に注意
Unit Test自動
Coded UI Test
Test Plan
自動
手動
全自動 = コスト “ 0” （ほぼ）
再テストのたびにコストがかかる
単体テスト
結合テスト
×2, ×3, ×4 …
テスト作るコスト 大
テスト作るコスト 小
テスト作るコスト 中
17
プログラムコードの 何％ がテストされているか？
UnitTest を実行すると、
テスト時に実行されたコード・実行されなかったコードが塗り分けられる
VS2017 （現在 RC ）ではコード書きながらわかる（ Live Unit Test ）
コードカバレッジ 80% を目指す
100％でもバグがないことを保証できるわけじゃないが、
100% でなければテストされていないコードがあることがわかる
VS によって自動生成される「絶対実行されない部分」もあるので参考：コード カバレッジを使用した、テストされるプロジェクトのコード割合の確認 https://msdn.microsoft.com/ja-jp/library/dd537628.aspx
18
レポート効率化（コスト０で報告書）
VSTS/TFS ダッシュボードに表示
単体テストが全て成功しているか？
手動テストが何件中何件成功？実施済みか？
問題があれば、クリックしてトレース・修正・再テストへ
どうしても必要なら VSTS/TFS からエクスポートして Excel で報告書
を
VS拡張機能「 TeamReportPlus 」https://marketplace.visualstudio.com/items?itemName=SHIN-ICHIKOGA.TeamReportPlus
19
自動ビルド・自動テスト・自動リリース（ DevOps ）
プログラムコードを変更したら自動的にテスト、 OK なら自動的にリリース
世界の最先端の開発チームでは DevOps 2.0プログラムを 1 日に何度もリリース
機能を作成した日に、すぐユーザーに使ってもらえる（ A ・ B テストも可能）
あるいは検証環境ですぐ動作確認ができる
VS ・ VSTS ・ TFS で開発の全行程を管理していれば可能
もちろん他社製品・ OSS もあります。考え方は同じ
20
プログラム開発だけじゃない
設定もサーバー構築もPowerShell で行えばインフラエンジニアでも
DevOps できます！
21
DevOps できるかどうか？は
マネージャーが「そうする」チームを作れるかどうか？です
経営者の役割でもあります
22
まとめ
Visual Studio で開発の全行程を管理してトレーサビリティを
テストを自動化してコスト 0 で何度でも再テストを
レポートもコスト 0 で（できればお客様に VSTS/TFS 画面を見てもらおう！）
プログラム開発だけじゃない！インフラエンジニアでも DevOps自動テスト・自動リリースをできるチームを作るのはマネージャーの仕事
23
書籍とスライド資料の CM
チーム開発の教科書
http://amzn.to/2euUzrW
はじめての ASP.NET SPA 開発入門
http://amzn.to/2eQKaUa
ちゃんとした C# プログラムを書けるようになる実践的な方法
～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
http://www.slideshare.net/shinichikoga355/starting-c-sharp
テスト・リリースを自動化できる開発はトレーニングが必要な技術です！
Copyright© 2016 Shin-ichi Koga All Rights Reserved. 24