SQiP2014

QA 活動を加速する

テストギャップ解析

コベリティジャパン株式会社

安竹 由起夫

より良いソフトウェアを、より早く

テストの変革

Coverity のミッション

受け身ではなく積極的に

不具合を早期に発見

リスクと変更箇所にフォーカス

• 英国の保険会社 - 世界第6位の保険会社グループ

• Fortune Global 500 (109位, 2013)

• 4,300万人以上の顧客

• 20ヶ国以上で事業を展開

Change Business: 20% -> 60%

• 以前は、顧客の 20% のみがオンライン経由• 現在、60% の顧客がオンライン経由

品質自体も重要だが、それ以上に、

サービスを、早く低コストで提供する事が重要

•四半期に一度のリリース

•サービスのタイムリーな提供のための障害となっていた

•社内開発とオフショア、OEM

•オフショアや OEM の品質のばらつき

•品質の指標や、チェックプロセスが無い

•品質保証部門からの可視性がなく、「品質を保証する部門」ではなく、「バグを発見する部門」になっていた

• 50% の不具合がユーザーアクセプタンステストの段階で発見

•コスト増やリリースの遅延抜きで修正することができなかった

Change Business: 20% -> 60%

対策

• 企業レベルの品質向上イニシアティブを立ち上げ、顧客満足度を50%向上させることを目標とした

• このイニシアティブでは、アプリ開発・保守のリーダーと、テストのリーダーが、柔軟性に富み、高品質のアプリケーションを、より早く、より良く、より安価に、開発・展開するためのビジョンを共有した

• テスト自動化への旅

• 「品質は、全員の責任」

• より頻繁にリリースするアジャイルな継続デリバリーの導入

• プロセスすべての段階での品質の可視可

• テスト部門と開発部門が足並みを揃える

Change Business: 20% -> 60%

結果 – 14ヶ月の展開で

• アウトソース会社と品質に関する SLA を締結

• 品質の劣化なしに、より短い周期でのリリースが可能に

• QA チームは、統合テスト前に、品質に関する情報を入手

• 開発ライフサイクルの中で早期に品質状況を知る事ができ改善につながった

• 254 人週のリワークを削減

• £501,000 相当のサービス不可時間とコストの削減

• およそ、300万行のコードを解析

• 約3,000件の不具合を発見、1,000件を修正

Change Business: 20% -> 60%

Time-to-Market: ３倍速で

• 世界第５位の航空会社• €250億の売り上げ(2013)• 7700万人以上の乗客(2013)• 605機の航空機

“エールフランスKLMのB2Cオンライン予約サイトは最重要商品のひとつであり、エールフランスKLMの売上の大部分はここから生まれます。

その複雑さゆえに、それぞれの機能開発や法令準拠には、お客様が期待するサービスの品質を維持するために大量のリグレッションテストが必要となります。”

Philippe Bordas. Methods and Testing Manager with Air France-KLM.

Time-to-Market: ３倍速で

• 商品の改善に向けての取り組みとして、”Transform 2015” 計画に着手

• 競争力を取り戻して、自社の商品とカスタマーサービスを世界でも屈指のものとする

• ソフトウェア開発チームを反復開発型からアジャイル型に移行させる

• Webサイトの更新を実施する際には、休止時間が発生することは決して許されない

• リグレッションテストは、以前は3カ月の開発サイクルごとに3週間かかっていた

• 目標は開発サイクルを1カ月に短縮すること

• このために、QAチームは最も重要な試験に的を絞る必要がある

• Coverity Test Advisor – QA Edition を導入

• 継続的インテグレーション（CI）システムを導入、毎晩自動的にテストを実行

• コードの変更点を解析し、AirFrance.frのサイトに影響が起こる、リスクが高いテストを特定し優先的に実施

• 実施済みの全テストが集約されたビューを用いて、開発から導入までのテストをより効果的に行い、本稼働に入る前にリスクを解消

3 weeks

1 week 1 week 1 week

10

QA

3ヶ月毎のリリースサイクル

リリース期間の短縮 => 1ヶ月!

Time-to-Market：３倍速で

QA QA QA

Analysis / Design / Implement

開発スピードを高め、同時にリスクを低減

開発者 品質保証

セキュリティ マネージメント

コードインテリジェンス

“Swiss Cheese” Modelhttp://blog.feabhas.com/2011/12/effective-testing-the-swiss-cheese-model/

- Coverity Quality Advisor

- Coverity Security Advisor

Coverity Test Advisor- Development Edition- QA Edition

コードレベルのバグ・脆弱性を防げないか？

• 精度よく素早くバグを検出（穴を小

く！）

• 派生開発のサポート

Coverity Quality Advisor –品質

• OWASP Top10 カバレッジ

• 修正方法の提示

Coverity Security Advisor – 脆弱性

コードバグによる手戻りを削減セキュリティ脆弱性への対応を開発段階から実施

静的解析 – 手戻りを激減させるテクノロジー

SAT ソルバ

全パス &

プロシージャ間

解析

不具合が発生しないパスを排除し、誤検知を減らす

関数またはファイルに跨る不具合の検出

統計的な解析

プログラムの目的を推測し、予期しない

動作を報告

if x == 0

... ...

if x != 0

NULL の参照解除

x!=0 x=0

x!=0x=0

int *p = malloc(sizeof(int));if(p != 0) *p = 42;...int *p = malloc(sizeof(int));if(p != 0) *p = 42;

int *p = malloc(sizeof(int));

*p = 42;

多分正しい

多分間違い

Expanded Support For OWASP Top 10

OWASP Top 10 Coverity 7.5

A1: Injection ✔

A2: Broken Authentication and Session Management ✔

A3: Cross-site Scripting (XSS) ✔

A4: Insecure Direct Object References ✔

A5: Security Misconfiguration ✔

A6: Sensitive Data Exposure ✔ *

A7: Missing Function Level Access Control ✔

A8: Cross-Site Request Forgery (CSRF) ✔ *

A9: Using Components with Known Vulnerabilities N/A

A10: Unvalidated Redirects and Forwards ✔

* New in 7.5

Deeper Coverage of the OWASP Top 10

OWASP 10 - 2013 CWE-IDs

A1 77, 78, 88, 89, 90, 564, 917

A2 259, 321, 384, 425, 798

A3 79, 80, 81, 82, 83, 84, 86, 87

A4 22, 23 ,36

A5 4, 7, 86, 615, 650

A6 321, * 327, *328, *916

A7 425, 862, 863

A8 * 352

A9 N/A

A10 938

* New in 7.5

Expanded Coverage for Security Vulnerabilities

CWE-ID CWE Name

20 Improper Input Validation

94 Code Injection New

111 Direct Use of Unsafe JNI New

113 Improper Neutralization of CRLF Sequences in HTTP Headers

190 Integer Overflow or Wraparound

352 Cross-Site Request Forgery (CSRF) New

366 Race Condition within a Thread

403 Exposure of File Descriptor to Unintended Control Sphere

427 Uncontrolled Search Path Element New

470 Use of Externally-Controlled Input to Select Classes or Code

543 Use of Singleton Pattern Without Synchronization in a Multithreaded Context

610 Externally Controlled Reference to a Resource in Another Sphere New

643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')

662 Improper Synchronization

不具合修正担当者の自動アサイン

18

• Linux:バグ修正の姿勢に変化

バグ担当者の自動アサインロジック

以下のいずれかで、自動的にバグをアサイン：

• バグの発生イベントが存在するファイルを最後に修正したユーザ

• バグの発生イベントの行を最後に修正したユーザ

• バグの発生パスが存在する関数を最後に修正したユーザ

• バグの発生パスの開始行を最後に修正したユーザ

• バグの発生パスのいずれかの行を最後に修正したユーザ (default)

• バグの発生パスが存在する関数のいずれかを最後に修正したユーザ

• バグの発生パスが存在するファイルのいずれかを最後に修正したユーザ

テストの穴（漏れ）を小さくできないか？

テストの作成支援 テストの実行支援

• 開発チーム • 受入れ、QAチーム

• 優先的に実行すべきテスト

• 実行する意味の無いテスト

• 主に、E2Eレベルのマニュアルテスト、セレ

ニウムによるテスト支援

Coverity Test Advisor – QA Edition

• 優先的に開発すべきテスト

• 自動化すべきテスト

• 主に、ユニットテストコードの作成支援

Coverity Test Advisor – Dev. Edition

テストの作成支援

21

f25

f33 f77

f15 f90

Foo

...

f23f76 f32

f34

f54

...

f89 f67

f87f56

f34

......

... ...

... ...... ...

......

Functions that have

been changed

Functions that have

been impacted by change

テスト作成支援のポイント:

• 変更されたコードに注目（SCMより）

• 変更されたコードに影響を受ける箇所を特定（フロー解析）

• テストするには複雜すぎるコード、重要なロジックなどで優先度を設定

• 既存のテストコードのカバレッジ

コード変更が発生した関数

コード変更の影響を受ける関数

テストコードを優先的に作成すべき箇所をリストアップ

テストの穴（漏れ）を小さくできないか？

テストの作成支援 テストの実行支援

• 開発チーム • 受入れ、QAチーム

• 優先的に実行すべきテスト

• 実行する意味の無いテスト

• 主に、E2Eレベルのマニュアルテスト、セレ

ニウムによるテスト支援

Coverity Test Advisor – QA Edition

• 優先的に開発すべきテスト

• 自動化すべきテスト

• 主に、ユニットテストコードの作成支援

Coverity Test Advisor – Dev. Edition

テストサイクルにおける浪費

•リリースサイクルを短縮したい

•アジャイル手法の採用したい

•試験全体の有効性を向上したい

• 30％のテスト実行は無効

• 30％のテストがリグレッションの 65％をカバー

• 30％のテストが冗長的

テストサイクルにおける浪費

Kalistick 2012 Survey

24 のプロジェクトからのデータ（8万行〜450万行規模）ほとんどが手動のテスト

しかし…

30％のテスト実行は無効

OK リスクムダ？

開発チームが修正追加した部分

QAチームがテストした部分

•無効なテストとは？• 新規の問題を検出できる確立・能力がゼロか低いもの

• 変更内容の全体像を知る

• 変更内容に関連する機能が他に与えるインパクトを評価

• 有効なテストを特定するため、機能とテストシナリオ間のトレーサビリティを確保する

• 現実に実施できているか？

• 問題の解決が困難？

無効なテストを避ける方法

• テストフットプリントをとる！

• 自動で、各テストとアプリケーションの各インストラクションを関連づける

• 新バージョンのインストラクションに変更があれば、関連するテストがすぐわかる

• コベリティでは、バイナリコードレベル

もう一つのオプション

f25

f33 f77

f15 f90

Foo

...

f23f76 f32

f34

f54

...

f89 f67

f87f56

f34

......

... ...

... ...... ...

......

Functions that have

been changed

Functions that have

been impacted by change

High Priority Test

Low Priority Test

現在のテストケース

優先度が低いテスト

コード変更が発生した関数

コード変更の影響を受ける関数

テストフットプリント

28

• リグレッションを減らす方法

• 安全のため、大量のテストを実行する

• 受入れテストの自動化

• 作成コストと保守がすべてのQAチームに適するとは限らない

• しかし、30% のテストが 65% のリスクをカバーするので

はれば、そもそも大量にテストを実行する必要はないので

は？

30%のテストがリグレッションリスクの65%をカバー

• チェンジインパクトを見極める

• テストをスコアリングし、１つのテストでもっとも変更をカバーできるテストをリストアップ

• そのテストを優先的に実行する

もう一つのオプション

f25

f33 f77

f15 f90

Foo

...

f23f76 f32

f34

f54

...

f89 f67

f87f56

f34

......

... ...

... ...... ...

......

Functions that have

been changed

Functions that have

been impacted by change

High Priority Test

Low Priority Test

優先度が高いテスト

優先度が低いテスト

コード変更が発生した関数

コード変更の影響を受ける関数

テストのスコアリング

31

テスト実行を最適化:

• コードの変更に最も関連するテストを実行

• さらに、バグを発見する可能性のあるテストを優先的に実行

• 自動化されたテストであれば、コード変更のコミットに付随してテストを実行し、開発にテストを織り込んでいく

30%のテストが冗長

テスト過剰？

アプリケーション

テストされた部分• リリースサイクル全体を

とおして行われるテストは様々

• ユニットテスト

• インテグレーションテスト

• システムテスト、受入れテスト

• テスト実施者も様々

• 手動か自動かの違いも

• テスターと開発者の距離が近づいても、実行した全テストが集約されたビューはまれにしか存在しないのが現実

• 何がテストされ、テストされていないのかを正確に知ることができるか？

• すべてのテスト実行中にフットプリントを取得

• 過剰テスト領域が特定できる

• 変更箇所の情報と合わせることでテストホールを特定

もう一つのオプション

33

アプリケーション

テストされた部分

テスト過剰？

未テストの変更部分

変更部分

Confidential: For Coverity and Partner use only. Copyright Coverity, Inc., 201434

最新メジャーリリース

最新チェックイン

最新スプリント

最新メンテナンスリリース

コード変更タイミング

テスト効率を最適化:• 適切なテストにフォーカス• バグを早期に発見できるテストを優先

テスト実行を最適化＝無駄なテスト実行を省く＝開発期間の短縮を実現

コード変更にともない

実行すべき既存テスト数

全テスト

直近の変更に関係するテスト

テストの質を変えていく

35

Thank you