More Related Content
Similar to デブサミ2014【13-B-L】テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする(安竹由起夫〔コベリティジャパン〕) (20)
More from Developers Summit (20)
デブサミ2014【13-B-L】テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする(安竹由起夫〔コベリティジャパン〕)
- 7. コベリティの製品リリースプロセス
⼀一般的なリリースプロセス:
• 6 ヶ⽉月のリリースサイクル
• 3 ヶ⽉月の次期リリース計画
• リリース直前の 6 週間の
“ハードニング” サイクル
• 2 週間の “フィーチャーフリーズ”
• 2 週間の “インテグレーションフリーズ”
• 2 週間の “リリースフリーズ” と GA のた
めのアップロード
• リリースのコードネームは
カリフォルニア州の都市名
• Alameda, Berkeley, Davis, Eureka, Fresno,
リリースを実⾏行行するプロセス:
• アジャイルプロセス
• 部⾨門横断的なスクラムチーム
• 2 週間のスプリント
• メールまたは対⾯面での⽇日次スタン
ド・アップ
• Jira と PivotalTracker を介した進捗
管理理
• Bugzilla によるバグ管理理
• Jenkins-CI による継続的統合
• 週1回のステータスミーティング
• リリースハードニングでは、週に3回
1つのリリースの詳細
Next Release Planning
Next Release Execution
Release Execution
Release Planning
Prev. Release Execution
October
December
November
7
February
January
April
March
June
May
August
July
6 Weeks
Hardening
September
- 8. 明確な必要性
• 6ヶ⽉月のメジャーリリースサイクル
• サポートプラットフォームが⾮非常に多い
• プラットフォームの違いのみのテストケースが多い
• Jenkins 上のビルドは各プラットフォームに分散
Hardware'for'STS'Test'Farm'
250#
200#
183#
150#
215#
156#
125#
100#
50#
201#
65# 66#
69# 74#
70#
81#
71#
84#
100#
77#
88#
128#
88#
96#
108#
126#
127#
0#
Pre/2011# Q1#2011# Q2#2011# Q3#2011# Q4#2011# Q1#2012# Q2#2012# Q3#2012# Q4#2012# Q1#2013#
Number#of#Physical#Machines#
8
Total#Number#of#Machines#incl.#Virtual#Machines#
Today#
- 10. Coverity -‐‑‒ 2年年前の状況
• QA プロセスは東ヨーロッパで
アウトソースし実施していた
• 伝統的な QA スキル、開発スキルは
わずかかもしくは皆無
• 10時間の時差
• ⾔言語的な壁
• 6 週間のハードニングサイクルは “ロシアン・ルーレット”のようなものだった
• “フィーチャー実装完” と “フィーチャーテスト” の時間的解離離
• 開発者は品質に対して、即座の直接的な責任を感じていなかった
• 何に出くわすかわからない – “簡単なバグ” なのか “致命的バグ” なのか
• とるに⾜足らないバグに QA サイクルの多くが費やされていた
• ⼿手動のプロセスでは、テストを 2-‐‑‒3 回しか回せない
• 製品品質による苦しみ
• よい品質でリリースするために、チームは多くのストレスを抱えていた
10
- 11. 矯正への最初の試み
• QAと開発の間の境界を取り除く
• 組織的 + 時間的 (開発とテストを織り込んでいく)
• 2011 初頭に組織を再編
• 2/3 の QA リソースを開発組織に移管
• ⽬目的を、テストの⾃自動化を名⽬目に、
“開発しながらテストする” ように設定
• しかし、結果は期待はずれだった
• QA チームはプログラミングに関してトレーニングされておらず、
⾃自動テストを開発するのが困難であった
• テストの⾃自動化に関しては、実際ごくわずかしか進歩しなかった
• 時差と⾔言語の壁が存続していた
11
- 12. 抜本的な改⾰革 – ⼈人
• リソースを東ヨーロッパから
カナダ、カルガリーに移動
• 1 時間の時差
• サンフランシスコから 2.5 時間のフライト
• ⾔言語の壁がない
• 2011 年年の夏に移⾏行行を開始
• 移⾏行行は12ヶ⽉月以上かかった
• 多くは予算に影響を与えなかった
Personnel(Transi,on(from((
Eastern(Europe(to(Calgary(
14"
12"
• スキルセットの変更更
• テスト⾃自動化に焦点をあてたプログラミング
スキル
• テストの⾃自動化に対する⾼高いモチベーション
12
10"
8"
6"
4"
2"
0"
Q3"2011"
Q4"2011"
Q1"2012"
Eastern"Europe"
Q2"2012"
Calgary""
Q3"2012"
- 15. テストされたコード(%)
% Code Tested
コードカバレッジに対するチャレンジ
100%
1
Diminishing return for
テスト⼯工数の増加
increased test effort
に対し効果は減少
- ...
3
Effort to develop tests
テスト作成の⼯工数
15
2
テストできないコードも存在
Not all code is testable
- unreachable statements
- 到達できないステートメント
- デッドコード
- dead code, ...
テストを⾏行行う価値がないコード
Not all tested code adds
- 重要でないコード
equal value to the test
- デバッグコード、既存コード
- non-critical code
- 決まりきった例例外処理理
- …
- debug code, legacy code
- exception handling, ...
- 18. 実験(⾃自社製品)
“チェンジセット”にフォーカスしたテストポリシーを評価する単純な試み
• 解析コード数:1,372,376 ⾏行行
• 1,149,036 ⾏行行がテストでカバー (83.7% カバレッジ), 223,340 ⾏行行が未テスト
• 直前の変更更にフォーカスすると、145 ファイル内の 851 ⾏行行をカバーする必要
がある
Untested
LOC
250,000
2500
223,340
1979
200,000
2000
1743
150,000
1500
100,000
1000
404
50,000
-‐
9,636
7,934
145
851
Total
Since
5.3
Since
5.4
Since
5.4.1
Untested
LOC
223,340
9,636
7,934
851
Untested
LOC
(%)
100.0%
2.0%
1.6%
0.2%
1979
1743
404
145
#
Incomplete
Tested
Files
500
0
#
Incomplete
Tested
Files
Focus
tes6ng
on
latest
changes
#
Incomplete
Tested
Files
明らかに対処しやすい:
•
•
18
Untested
LOC
未テストコードの 0.2%
未テストファイルの 7%
- 19. 社内での経験 – ケーススタディ
• ⼗十分テストされている製品のコンポーネントにこの社内ツールを適⽤用
• 3ヶ⽉月間、1テストエンジニアが1週間のうち4時間、テストすべきと判断された箇
所にテストを追加した
• テストポリシー: テスト可能なコードは 100% テストする (除外: デバッグコード,
実⾏行行されないコード, その他)
Test'Advisor'Applica:on'in'Frontend'Project'
20"
18"
30"
16"
25"
14"
12"
20"
10"
15"
8"
6"
10"
4"
5"
2"
0"
28
*A
pr
*1
2"
5*
M
ay
*1
2"
12
*M
ay
*1
2"
19
*M
ay
*1
2"
26
*M
ay
*1
2"
2*
Ju
n*
12
"
9*
Ju
n*
12
"
16
*Ju
n*
12
"
23
*Ju
n*
12
"
30
*Ju
n*
12
"
7*
Ju
l*1
2"
14
*Ju
l*1
2"
21
*Ju
l*1
2"
0"
Date'
1
9
Tests"added"through"TA"
Bugs"found"by"TA"tests"
Number'of'Bugs'Found'
Number'of'Tests'from'TA'
35"
• 1⼈人週間換算で29件のテストを追加
• 製品から19件のバグを発⾒見見 – いくつ
かは重⼤大なもの
• 例例: Keil コンパイラの正しい機
能を阻害するバグなど
- 22. コードレビューの改善
• ⾃自社製品(Quality Advisor, Security Advisor)を開発に
も使⽤用
Defects'Addressed'by'Coverity'Quality/Security'Advisor''
Number'of'Defects'
400"
350"
300"
250"
200"
150"
100"
50"
0"
Alameda"
Berkeley"
High"Impact"
Carmel"
Medium"Impact"
Davis"
Low"Impact"
Eureka*"
22
- 29. 2013 に⼀一気に拡⼤大
#
of
Projects
1200
1000
800
600
#
of
Projects
400
200
0
Jan.
30
Feb.
March
April
May
June
July
Aug.
Sept.
Oct.
Nov.
Dec.
- 31. Coverity Development Testing Platform
解析 | 修正 | 統制
解析パッケージ
SDLC
統合
Policy
Manager
サードパーティ
メトリクス
Dynamic
Analysis
IDE
Coverity
Connect
コード
カバレッジ
Architecture
Analysis
解析結果統合
Quality
Advisor
Security
Advisor
Test
Advisor
FindBugs™
|
FxCop
テスト
実⾏行行
ビルド/
継続的統合
バグ
トラッキング
SCM
解析結果統合
ツールキット
Coverity
SAVE™
Static
Analysis
Verification
Engine
商⽤用コード | オープンソースコード
32
ALM
連携
HP
|
IBM
- 32. OWASP Top 10 サポート
OWASP
Top
10
Coverity
7.0
1:
インジェクション
✔
2:
認証とセッション管理理の不不備
✔
3:
クロスサイトスクリプティング (XSS)
✔
4:
安全でないオブジェクトの直接参照
✔
5:
セキュリティ設定のミス
✔
6:
機密データの露露出
✔
✔
7:
機能レベルアクセス制御の⽋欠落落
8:
クロスサイトリクエストフォージェリ (CSRF)
9:
既知の脆弱性を持つコンポーネントの使⽤用
10:
未検証のリダイレクトとフォワード
Coming
soon
NA
✔