テストを育てる。テストを支える（ultimate agilist tokyo）

テストを育てる。テストを支える。

Ul#mate Agilist Tokyo -‐ 集え、日本の活動家たちよ 2012/11/17 @オラクル

井芹　洋輝

自己紹介

•  井芹　洋輝 –  組み込みソフトウェアの開発とテストに従事 –  アジャイルやっていません。アジャイルのプラクティスが好き –  活動

•  WACATE実行委員/TDD研究会/TDDBC　等 •  TDDやテスト設計、バグ管理などのコーチングを行う

–  講演 •  「実践！組み合わせテスト設計」（WACATE2012夏） •  「ユニットテストの保守性を作りこむ」（XP祭り関西） •  「テストで支える開発効率化」（Androidテスト祭り）等

–  執筆 •  ソフトウェアテストPRESS総集編等

Ul#mate Agile Storyでは

•  組み込みTDDの記事を執筆させて頂きました – 組み込みがマイナーなため講演テー

マとして断念..

•  書いたこと –  TDDは組み込み開発を大きく効率化さ

せます！ – 組み込みプログラマはTDDをしよう！

別の人により翻訳進行中

このセッションについて

•  変化を許容しつつ、開発ライフサイクル全体でテストを積極活用する開発においてテストの力を引き出す考え方や知見を紹介します。

ソフトウェアテストの課題

Vモデル開発

要求定義

基本設計

詳細設計

実装

単体テスト

結合テスト

システムテスト

Vモデル開発

要求定義

基本設計

詳細設計

実装

単体テスト

結合テスト


●インプット資料をきちんと作ること

●インプットに対しきちんとテスト分析・設計を行うこと ●早期からテストを考慮すること

Vモデル開発

要求定義

基本設計

詳細設計

実装

単体テスト

結合テスト


●インプット資料をきちんと作ること

●インプットに対しきちんとテスト分析・設計を行うこと ●早期からテストを考慮すること

これだけではうまくいかない

アジャイル開発などでのソフトウェアテストへの要求

•  変更や曖昧さに対応する •  反復開発、中間リリース

仕様変更プロトタイピング

仕様追加

終リリース

プロトタイプ

中間リリース

中間リリース

中間リリース

アジャイル開発などでのソフトウェアテストへの要求

•  色々な目的で色々なテストが実施される

仕様変更プロトタイピング

仕様追加

終リリース

プロトタイプ

中間リリース

中間リリース

品質証保のためのテスト

TDDでのプログラミング

CIでのデグレード監視

網羅的なバグ出し

中間リリースのための品質保証

取り組まなければならない課題

課題：変更による生産性低下

•  変更の度に・・ – テスト設計のやりなおし – インターフェースの変更への対応 – 既存テストの再評価 – 回帰テストの追加

•  テストの変更性が劣悪だと、「Cut & Run」や非効率化を促す

課題：テストへの要求の見逃し

•  テストの要求を見逃したり阻害したりする

品質保証のためのテスト

TDDのテスト

中間リリースのテスト

CIのテスト

これでテストは大丈夫だ

課題：テストへの要求の見逃し

•  テストの要求を見逃したり阻害したりする

リリース判定のためのテスト

TDDのテスト

中間リリースのテスト

CIのテスト

バグを見逃さない網羅的なテストを作るように

課題：全体整合のないテスト

•  バラバラにテスト設計やテスト実装を行う •  設計や保守で無駄なコストが発生する •  全体としてテストの穴や冗長性が見えにくくなる

品質証保のためのテスト

テストファーストでの設計

CIでのデグレード監視網羅的なバグ出し

中間リリースのための品質保証

ソフトウェアテストを効果的に運用するには

どうすればよいか？

ソフトウェアテストを効果的に運用するにはどうすればよいか？

• テストを育てる。テストを支える。

•  テストを育てる視点 – 全体の方針を立てた上で、変化に対応しつつ全

体適が得られるようにテストを作っていく

•  テストを支える視点 – テストの課題やリスクに対応する

テストを育てる


開発開始終了


テストの活動

テストを育てる基本フロー

1.  テストへの要求を分析する 2.  全体の方針や構造を明らかにする

3.  段取りを明らかにする

4.  テストを育てていく

テストを育てる基本フロー

1.  テストへの要求を分析する 2.  全体の方針や構造を明らかにする


4.  テストを育てていく

開発ライフサイクル

開発プロセスと並行開発ライフサクルを通して要求を監視する

1. テストへの要求を分析する

テストへの要求を分析する

•  開発ライフサイクルでどのようなテストが要求されているのか明らかにする

•  テストへの要求 – テスト対象 – テストの計画 – テストの運用 – テスト目的



“何に対してテストするか” “いつどのような流れでテストするか” “どのような形でテストするか” “どこまでテストするか”


•  テストへの要求 – テスト対象

•  対象の構造 •  開発のフローやスケジュール

– テストの計画 – テストの運用 – テスト目的

●機能構成・再生機能・通話機能 … ●ユニット構成・コンポーネント１・コンポーネント２ …

第一イテレーション

第二イテレーション

第三イテレーション

…

フィーチャ1 ○ ○ ○

フィーチャ2 ○ ○

…. ○

リリース状況

テスト対象の分析

•  システムテスト設計のための機能分析

カテゴリ中項目小項目

ビープメインビープエラービープ

通常ビープ

… …

日時通知時刻表示日時表示

…

外部仕様レベル

コンポーネントレベル

機能のレイヤ設計

アーキテクチャレベル

階層一覧で整理

機能

機能

機能

テスト対象の分析

•  システムテスト設計のための機能分析

カテゴリ中項目小項目

ビープメインビープエラービープ

通常ビープ

… …

日時通知時刻表示日時表示

…

外部仕様レベル

コンポーネントレベル

機能のレイヤ設計

アーキテクチャレベル

階層一覧で整理

インターフェース

機能

状態やトリガ

機能

状態やインターフェースとの関連付けで整理

機能

機能

機能


•  テストへの要求 – テスト対象 – テストの計画

•  テストのフローやスケジュール

– テストの運用 •  環境 •  実行や管理上の要求

– テスト目的「1秒以内での軽快な実行を行う」「夜間に自動実行する」「納入先と同等の環境でテストする」

テストどの段階で実行するか



•  着目する品質特性 •  品質基準

どのような品質を見るのかどのような品質を保証するのか

テスト目的の分析

● ISO 9126 機能性　合目的性　正確性　相互運用性　…. 信頼性使用性効率性 …

●テストタイプ

●対象の形態　ユニット　アーキテクチャ　システム

単機能テスト

✕✕機能組み合わせテスト

状態遷移テスト

マニュアルテスト

構造テスト

静的解析による構文チェック

品質モデルや品質指標

品質特性

対象の形態 ●テストタイプ

品質のテスト手段


ボタン

プッシュボタン

タッチパネルボタン

判定基準値に対するテスト

押下時間に対するテスト

有効領域に対するテスト

操作方法に対するテスト

テストカテゴリモニタ表示

文字の視認性に対するテスト

ちらつき、ノイズのテストテストカテ

ゴリテスト条件テスト設計

方針

モニタ表示文字視認性

同値クラス網羅

境界値テスト

同値分割


ボタン

プッシュボタン

タッチパネルボタン

判定基準値に対するテスト

押下時間に対するテスト

有効領域に対するテスト

操作方法に対するテスト

テストカテゴリモニタ表示

文字の視認性に対するテスト

ちらつき、ノイズのテストテストカテ

ゴリテスト条件テスト設計

方針

モニタ表示文字視認性

同値クラス網羅

境界値テスト

同値分割参考にしますが、テスト対象とは切り離して考えます。抽象的に考えることで、テスト対象から独立して分析できるようになるほか、テスト設計漏れを防止します

参考文献

Vol.10　「今こそ聞きたいテストの上流設計」

2. 全体の方針や構造を明らかにする

全体の方針や構造を明らかにする

•  要求に基づいてテスト活動を誘導する全体の方針や構造を明らかにする


•  テスト対象とテスト目的の関連付け

テスト対象機能性テストユーザビリティテスト …

中項目小項目単機能

状態遷移

組み合わせ

異常系

仮想ユーザ

ユーザ

… …

日時表示時間表示 A C 年月日表示 A B C

ストップウォッチ

再生・停止 A B C

リセット A C

… …

必要なテストを見つけ出す「●ユーザビリティテストC プロダクオーナにより時間関連処理のユーザビリティを評価する」

テスト対象

テストタイプやテストカテゴリ

テスト分析マトリクス


•  テストの運用や計画の方針を決める

●ユーザビリティテストC 対象：時間関連処理テスト目的：主要ユーザが滞りなく操作できること運用、計画：プロダクトオーナが実機を使って評価　中間リリースでアドホックに評価



状態遷移

組み合わせ

異常系

仮想ユーザ

ユーザ

… …




リセット A C

… …


– 各フェーズでのテストの「対象」「目的」「運用」を明らかにする

テストの種類フェーズ

開発中内部リリースプロトタイプリリース

βリリースA

ユニットテスト開発者テスト

内部リリース向けユニットテスト

自動構成テスト ….

システム試験

…

●開発したソースコードを対象 ●事情がない限りコードカバレッジ100%推奨 ●デイリーでフル実行

●システム全体が対象 ●コードレビューを行い、テストが基準以上の網羅性を持っていることを確認

段取りを明らかにする

段取りを明らかにする

•  どう育てていくかを考える •  開発全体での整合性を確保する •  全体適を意識する

単機能テスト

単機能テスト

結合テストリリース前のシステム試験

単機能テスト

単機能テスト

組み合わせテスト

単機能テスト

開発初期中間リリース終リリース

段取りの例： VOTDD（検証指向TDD）

•  高品質なプログラミングを行うTDD •  「バグを網羅的に検出するユニットテストの構

築」＋「TDD」を効率的に進める

段取りの例： VOTDD （検証指向TDD）

•  １　パッケージや上位コンポーネントレベルでテストの方針や構造を明らかにする

●構造の方針 Testcase Class per Class Testcase Class per Fixture Testcase Class per Feature ●テスト設計の方針カバレッジC2網羅率同値クラス網羅率コードレビュールール

フィーチャ1

テスト設計の方針

下位機能

下位機能

下位機能

フィーチャ2

対応テスト

対応テスト

対応テスト

対応テスト

対応テスト


•  2 ユニットレベルで、テストリストをテスト設計技法にて整理する

0 6 12

ありえない

無料

半額

定額

0

-‐1

5

6 12

13

同値分割・境界値分析

4で割り切れる N Y Y Y

100で割り切れる N N Y Y

400で割り切れる N N N Y

うるうどし N Y N Y

デシジョンテーブル仕様

●テストリスト 400で割り切れるならば… 100で割り切れるならば… ….


•  3 テスト設計、テスト実装を作りこみながらTDDを進める

テストファーストによる追加・変更（RED→GREEN）

リファクタリング（REFACTOR）

Green

通常のTDD


•  3 テスト設計、テスト実装を作りこみながらTDDを進める

リファクタリング (REFATCOR [PRODUCT])

テスト設計の洗練 (VERIFY&DEBUG)

Green

テストファーストによる追加・変更（RED→GREEN）

テストコードの設計改善

（REFACTOR[TEST]）


•  4 テストを綺麗にする – 安定したテストコードから巡回的にレビューし、テ

スト設計の補強や再構築を行う –  終的に適切なテスト設計に基づいた網羅的な

ユニットテストを得る

開発工程(TDD) テスト作成

開発工程(VOTDD) テスト作成

工数

工数

VOTDDで・総工数7%削減・テスト設計経験者なら20%削減

TDD+網羅的なテスト作成

VOTDD+網羅的なテスト作成

※単体テスト工程：網羅的なユニットテスト構築

段取りを考える：テストプロセスの活用

•  ゆもつよメソッド

Vol.10　「今こそ聞きたいテストの上流設計」

段取りを考える：変更対応に優れたテスト方法論（ゆもつよメソッド）

上流工程

イテレーション

イテレーション … テスト

開発プロセス

テスト対象

の分析

テスト目的

の分析

テスト分析マトリクスなどによる

テストの上流設計

テスト設計

テストケース

スケーラビリティに優れた方法論


上流工程

イテレーション

イテレーション … テスト

開発プロセス

テスト対象

の分析

テスト目的

の分析

テスト分析マトリクスなどによる

テストの上流設計

テスト設計

テストケース

スケーラビリティに優れた方法論

変更対応に優れたプロセスやフレームワークを採用することで、変化や問題に対し、整合性を崩さず規律を持って対応できる




状態遷移

組み合わせ

異常系

仮想ユーザ

ユーザ

… …




リセット A C

… …

変更が発生した際、変更がテスト全体に対しどこに波及しているか検討しやすい

テスト対象から離れてテスト設計を行うことができる


•  変更対応に優れたテストの方法論にもとづいてテストを育てる 1.  テストへの要求を分析する 2.  全体の方針や構造を明らかにする


4.  それぞれでテストを育てる

•  キーワード – 「４つの要求の分析」「VOTDD」「ゆもつよメソッド」

テストを支える


•  育てる方針はわかってもうまくいかない – ソフトウェアテストは宿命として様々な問題に直

面する。それらはルールやプロセスを吹き飛ばす

テストが抱えがちな問題

要求分析設計実装テスト

テストエンジニアは後工程を主担当

リリースふつうのWF

（とちぎテストの会議2レシピ発表より）




テストエンジニアは後工程を主担当


バグは出すなリリースは遅らせるな

BOSS





遅延バグは出すな

リリースは遅らせるな

BOSS





遅延

要求定義のミス

仕様バグ

バグ混入

粉飾

見積りミス

テスタビリティの悪さ

隠れた仕様変更

バグは出すなリリースは遅らせるな

BOSS





対策が遅れるほど問題対応の選択肢が少なくなる

契約やプロセス、計画で対策

仕様やプロトタイピングで対

策

設計や先行テストで

対策

残業や増員で対策

遅延やスピリチュアル系で

対策

問題対応の選択肢


•  テストを支える – テストプロジェクトのリスクや問題を識別し、対策

を打つ – テストの活動をより効率的にする

テストを支えるプロセス

1.  テストプロセス

– トップダウンで必要な支援策を抽出する。

2.  プロジェクトリスクのリスクマネジメント

– 問題や課題を抽出し、ダメージの予防・軽減・回避・移行を行う

•  後に説明

テストを支える道具

•  ２つのプロセスに基づいて対策をうつ – 良い方に誘導する – 選択肢を広げる – 堅牢な構造を確保する – テストを維持する – 自動化する – 粒度を調整する

誘導する：ウォーキングスケルトンによるダブルループ

•  初にアーキテクチャのスケルトンを開発 •  End To Endの自動テスト環境を構築 End To Endの自動テストを肉付けしながら細部の自動テストを記述していく

•  アーキテクチャの瓦解を防ぎ、自動テストの保守コストを削減する


Fake

コンポーネント


Mock

外部システム

仮実装

ウォーキング・スケルトン（動くアーキテクチャのスライス）


DB




外部システム


アーキテクチャ

Fake



Mock

外部システム

仮実装

ウォーキング・スケルトン（動くアーキテクチャのスライス）

開発の進展に応じてアーキテクチャに肉付けしていく

誘導する：ウォーキングスケルトンによるテストのダブルループ

TDD

End To Endの自動テストのテストファースト

ユニットテストを書く

製品コードを書くウォーキングスケルトンに対して自動テストを書く

CIや担当者

ユニット

ウォーキングスケルトン

EndToEndテスト

ユニットテスト

コミット

選択肢を広げる：デュアルターゲット・テスト

•  クロス開発（特に組み込み開発）において、自動テストをホスト環境、ターゲット環境両方で同時実行する

•  ホスト側の柔軟なテスト環境を活用しつつ、ホスト環境とターゲット環境の差違に起因する問題を軽減できる


ユニットテスト

ホスト環境（テストフレームワーク）ターゲット環境

ターゲット環境に対しビルド・実行

ホスト環境に対しビルド・実行

共通ロジック

ターゲット依存コード

ホスト依存コード

ビルド設定で切り替える


ホスト環境（テストフレームワーク）

ターゲット環境【メリット】本番環境でビルド・実行【デメリット】時間がかかる環境に制約

CI

サーバ

ユニットテスト実行

ユニットテスト実行

【メリット】軽快に実行柔軟な環境やツール【デメリット】ターゲット向けでない環境でビルド・実行

コミット

選択肢を広げる：マルチコンフィグレーションテスト

•  複数の構成設定を自動テストで同時検証 •  ありふれたテクニックとなっている

自動テスト

構成設定１構成設定2 構成設定3

CI サーバ

開発者環境

任意の構成設定

堅牢な構造を得る：データ駆動テスト

•  テストのデータとロジックを分離 •  ロジックを共通化し、データを柔軟に変更・拡

張できるようにする •  インターフェースが堅牢ならテストの堅牢性が

向上する

堅牢な構造を得る：データ駆動テスト

… TEST_F(Hoge, Fuga) { … ActualValue = Fuga(InputValue); EXPECT_EQ(expectedValue, ActualValue); … }

入力値期待値

AAA BBB

CCC DDD

… …

テストスクリプト

テストデータ

DB

ファイル

ソースコード

ロジックとデータを分離し、データの変更・管理を容易にする

堅牢な構造を得る：テストユーティリティメソッド

•  重複するテストコードを共通化する – フィクスチャのセット – オブジェクトの生成 – Asser#on – 等々

テストを維持する： CI

•  テストの保守や自動テストの基盤 – テストをCIで実行することが、テストのCIとなる

“（中略）Jenkinsを使用した継続的インテグレーション(中略)などをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。”

自動化する：実行の自動化

•  すでに色々なツールや手法が出ている

自動化する：テスト設計の自動化

•  モデルベースドテスト – 設計モデルからテストを自動生成する – テスト分析・設計の手間を削減する – テスト実行まで自動化できる場合もある


•  モデルベースドテスト

テストケース生成（astah、EA、ZIPC等）

状態遷移モデル

… ソースコード …

実装


•  モデルベースドテスト

原因結果グラフ … ソースコード …

テストケース

テスケース自動生成 (CEGTest)

実装


•  テスト設計ツール。すでに色々存在する •  テスト設計の手間を削減する

【因子】麺：やわめ、ふつう、かため、バリカタスープ：味噌、とんこつ、しょうゆ具：コーン、チャーシュー、ネギ、ノリ【禁則】・具：コーンはスープ：味噌のみと組み合わせ可

因子と水準

All-‐Pair法ツール（PICT、PICTMaster等）

麺スープ具

テストケース1 やわめ味噌コーン

テストケース2 やわめとんこつコーン

… … … …

テストケース


•  参考書籍

堅牢な構造を得る：インターフェースの抽象化

•  インターフェースを抽象化し、インターフェースの変更からテストを保護する

•  テストの変更・追加を容易にする

システム


•  UIとAPIの分離 •  UIの抽象化

システム GUI

API

自動テスト

システム

ボタン ID1

テキストボックス ID2


•  キーワード駆動テスト。ドメイン駆動のテスト •  非開発者でもテストの保守が可能

システム

KDTやDDDの

フレームワーク

自動テスト

キーワード「ボタン」「押す」「異常系エラー」 DDTL「異常系エラーを発生させてボタンをおす」

堅牢な構造を得る：テストインフラの確保

•  観察点の確保 – 有用な内部エラーや内部リスクに対して設置

•  制御点の確保 – 実現の難しい異常や特殊処理に設置 – 入力を柔軟に操作可能にする

•  接合部の確保 – テストの障害となるコンポーネントの

インターフェースに設置

堅牢な構造を得る：モジュラリティの確保

•  一般的な設計原則に従う •  SOLID

– 単一責任の原則 – オープン・クローズドの原則 – リスコフの置換原則 – インターフェース分離の原則 – 依存関係逆転の原則

•  コンポーネントの結合度は低く、凝集度は高く •  時間的、構造的に影響範囲を限定する

堅牢なテストを得る：テストインフラの確保

•  FIRST – Fast：軽快に実行可能 –  Independent：テストは個別に独立している – Repeatable：テストは再現可能 – Self-‐Valida#on：実行から判定まですべてこなす – Timely：すぐに書ける

機能テストを育てる：探索的テストの活用

テスト設計

テスト実装

探索的テスト

… N Y Y Y

… N N Y Y

… N N N Y

…. N Y N Y

テスト設計

テスト実装

探索的

テスト

… N Y Y Y

… N N Y Y

… N N N Y

…. N Y N Y

テスト設計

テスト実装

探索的テスト

… N Y Y Y

… N N Y Y

… N N N Y

…. N Y N Y

開発の進展

ベースとなるプロセス

•  テストプロセス

– トップダウンで必要な支援策を抽出する。

•  プロジェクトリスクのマネジメント

– 問題や課題を抽出し、ダメージの予防・軽減・回避・移行を行う

テストプロセス

•  テストの構造や段取りを適切な手法で明らかにすることで、必要な対策や補助を明らかにする

•  施策に適したインプットを確保する

プロジェクトリスクのリスクマネジメント

– リスクや問題を補足し、対策する

リスクの識別

リスクの分析

対応検討

対策実施

フォローアップ

リスクマネジメントプロセス

計画要求分析 … … テスト

開発プロセス


– リスクや問題を補足し、対策する

リスク対応手段

リスク要因リスク内容移行基準リスク重大度

対応手段軽減後の重大度

開発工程でのバグ見逃しが常態化

手戻り工数が増大し、リリース遅延を発生させる

2回以上の手戻り発生

A ・スモークテストを作成。それに合格してからテスト工程に移行する・実装工程中、前倒しで単機能テストを実施する

B

ご清聴ありがとうございました

•  テストを育てる。テストを支える。 – 育てる

•  変更対応に優れた方法論に基づく 1.  テストへの要求を分析する 2.  全体の方針や構造を明らかにする


4.  それぞれでテストを育てる

– 支える •  テストプロセスやリスクマネジメントで課題を抽出し、問

題対策や効率化対策をサポートする

テストを育てる。テストを支える（ultimate agilist tokyo）

Documents