Tabok 自己流自動化ふりかえり展開版

1 2/17 TABOK関西勉強会

2/17(日) TABOK関西勉強会

テスト自動化ふりかえり

みずのり＠WARAI

自己流！


関連コミュニティ

■ソフトウェアテスト系 JaSST関西実行委員 WARAI（関西ソフトウェアテスト勉強会）運営出没：TABOK関西（運営？）/東京、 WACATE、各地区のJaSST

■ETロボコン ETロボコン関西地区実行委員

■その他出没：アジャイルとかTOCfEとか適当に興味のある勉強会


持ちネタ（発表、ワークショップ）

■ロジカルシンキングエンジニアのためのロジカルシンキング（考え方編、伝え方編）

■キャリア論＆スキルを考えるネタ “自分”を研究する～自己のスキル・動機を見つめなおす

■仕事術、タスク管理タスクを分解して、タスク設計を考えるお話

■ソフトウェアテストテスト設計コンテスト＠2012（2位）、＠2013、テストの段階的詳細化手法（JaSST’13東京論文）

■ETロボコンモデル分析ネタ

■プロセス PFD（プロセスフローダイアグラム）ワークショップ

■プロジェクトキックオフ（目標を考える）ワークショップ、ふりかえりワークショップ

■ソフトウェアテストテスト技法、テストネタのワークショップ＠WARAI


持ちネタ（デザイン）

■Ultimate Agile Stories

■いろいろアイコン


あれ？

エンジニアですか？⇒ orz… たまにはエンジニアっぽいネタを紹介したいです。


コンテンツ

以下の流れで説明。・業務での自動化展開のふりかえり。・今まで実施してきた考え方のふりかえり。


システム自動化の一例を紹介

デモなし。

「システムテスト」のお話。

単体テストな話は全くありません。

コンポーネント

テスト

統合

テスト

システム

テスト


業務紹介

Systems of System

組込みインフラっぽいもの。

個産なのに24時間365日

海外からの買い物装置、

A社製品、B社製品の組合せ。

他社製

プロセスA プロセスC 装置①

装置②

アプリ②-1

装置②

アプリ②-2

装置②

アプリ②-3

プロセスB


業務紹介

他社製


装置②

アプリ②-1

装置②

アプリ②-2

装置②

アプリ②-3

プロセスB

システムの妥当性確認試験が必要。

複数設定対応。200設定とか。

1設定で運用をするのに複数の

制御が必要。1制御が3分くらい。

合計で1設定10分程度。

⇒マニュアルで付きっきり？

© あずまきよひこ


業務紹介

他社製


装置②

アプリ②-1

装置②

アプリ②-2

装置②

アプリ②-3

プロセスB

システムの妥当性確認試験が必要。

複数設定対応。200設定とか。

1設定で運用をするのに複数の

制御が必要。1制御が3分くらい。

合計で1設定10分程度。

⇒マニュアルで付きっきり？

やってられないので自動化！


変わり行く状況

Windows自動化ソフト「UWSC」を軸に自動化環境を構築。

http://www.uwsc.info/ ※キャプチャ＆リプレイツールです。

※本日はツール自体の「使い方」は省略します。

http://www.uwsc.info/




■フェーズ①

人が入力していたトリガを決め打ち。

同じ処理を繰返し再生し続ける。

システム




■フェーズ①



システム UWSC




■フェーズ①



■フェーズ②

CSVから設定パターンを変更可能に。システム UWSC

設定ファイル

CSV




■フェーズ①



■フェーズ②

CSVから設定パターンを変更可能に。

■フェーズ③

個別の制御の選択が出来るように。

システム UWSC

設定ファイル

CSVA B C

C’

バイパス

選択




■フェーズ①



■フェーズ②


■フェーズ③


■フェーズ④

周りの環境も出来る限り制御可能に。

システム UWSC

設定ファイル

CSVA B C

C’

バイパス

選択

アプリ

PICNIC




■フェーズ①



■フェーズ②


■フェーズ③


■フェーズ④


■フェーズ⑤

結果判定がメンドイので、自動判定機能追加。

システム自動

判定 UWSC

設定ファイル

CSVA B C

C’

バイパス

選択

アプリ

PICNIC




■フェーズ①



■フェーズ②


■フェーズ③


■フェーズ④


■フェーズ⑤


システム自動

判定 UWSC

設定ファイル

CSVA B C

C’

バイパス

選択

アプリ

PICNIC

Test OK 2013/2/17 10:00:00

Config2 2013/2/17 10:12:00 Test OK

Config1

7Error NG 2013/2/17 10:25:00

Config4 2013/2/17 10:35:00 Test OK

Config3

自動判定表示方法のイメージ




■フェーズ①： Level1（Linear）人が入力していたトリガを決め打ち。


■フェーズ②： Level2（Data Driven） CSVから設定パターンを変更可能に。

■フェーズ③： Level2（Functional Decomposition）個別の制御の選択が出来るように。

■フェーズ④


■フェーズ⑤


システム自動

判定 UWSC

設定ファイル

CSVA B C

C’

バイパス

選択

アプリ

PICNIC

TABOK：4章でいうとLevel2まで＋使いやすさ優先？

Test OK 2013/2/17 10:00:00

Config2 2013/2/17 10:12:00 Test OK

Config1

7Error NG 2013/2/17 10:25:00

Config4 2013/2/17 10:35:00 Test OK

Config3

自動判定表示方法のイメージ


成果的なもの

リリース後に発生していた不具合が1/5くらいに。

※同時に勉強していたテストプロセス系の効果も有ります。

海外購入品へのイチャモンに自動試験環境を持っていったら従った。

⇒そのメーカがいつの間にかウチのツールで試験しやがっていた。

再現しない不具合を指摘されてから、（連続可能な）再現環境構築、

すぐに再現するか？という判断、対応までが圧倒的に早くなった。

時間は感覚的ですが、リードタイム1/5くらいかな？


最近は…？

システム試験に自動化環境前提のテストケースが入るようになっている。

＜効果＞

・信頼性の確認＋安心感

・テスタビリティ、客先出荷後の保守性向上

・システムを考える、システムとして動かす

＜その他＞

・（再現しない）不具合再現に活用。

・改修後の妥当性を示す。

本当に

大丈夫？

10万回

試験したよ


考え方のふりかえりと整理

自動化環境つくりの考え方を整理してみます。 ※多分、（無意識に）出来ている人が多いはず。

今回は自己流で「組込みシステム」における

自動化環境の作り方の考え方を

中心に紹介してみます。


自動化といえば？

いったん、「自動化といえば？」というお題で考えてみました。

やたら発散する感じです。

xUnit使わないなんてありえないよね

Sikuliサイコー（≧▽≦）

今から全部自動化なんて出来ないっすよ

費用対効果を考えないと！

上司が全部自動化とか言うんですよ

自動化って単体テストのことじゃないの？

データ作成も自動化だぜ！

組込みじゃ現実的じゃなさそう

シミュレータとか無いと試験できないよ！

ユーザビリティとかも自動に見るのかな…


自動化といえば？

いったん、「自動化といえば？」というお題で考えてみました。

やたら発散する感じです。

xUnit使わないなんてありえないよね

Sikuliサイコー（≧▽≦）

今から全部自動化なんて出来ないっすよ

費用対効果を考えないと！

上司が全部自動化とか言うんですよ

自動化って単体テストのことじゃないの？

データ作成も自動化だぜ！

組込みじゃ現実的じゃなさそう

シミュレータとか無いと試験できないよ！

ユーザビリティとかも自動に見るのかな…

ツール

ROI

プロセス

テストの考え方

構築アプローチ


自動化といえば？（アプローチ）

自動化を構築する際のアプローチを紹介。

ボトムアップアプローチ：マニュアル作業を自動化に落とし込む（いろいろ工夫しつつ）最も使う手順、運用パターンから考える。

繰返し出来るようになった上で、パターン変更可能、使用性を高める

個別に作成した自動化を統合的に動かす

トップダウンアプローチ：全体のフェーズを考えて、必要な環境を見込む

「何を見るか？」という大まかな確認する性質（品質特性等）を見込む

必要な（ツール及び開発対象アプリ）要求を特定し、開発計画へ展開


自動化といえば？（プロセス）

テスト分析：テスト対象を理解してテストすべきことを明確にする要件管理ツール

テスト設計：テスト条件を確認する具体的なパターンを見込む原因結果グラフツール、組合せテスト支援ツール（直交表、オールペア）、

状態遷移テストツール、動的解析ツール、カバレッジ計測ツール、その他

テスト実装：テストを実行できるための一連の作業シミュレータ（スタブツール）、ラボイメージ、データジェネレータ、ケース管理ツール

テスト実行：通常「テスト」と呼ばれる作業ユニットテストツール、キャプチャ/リプレイツール、性能テストツール

セキュリティテストツール、テスト自動実行支援ツール

その他：コード解析、テストウェア管理、テスト結果管理、インシデント管理

自動化？テスト？に関わるプロセスを紹介 ※「テストツール丸わかりガイド」より http://aster.or.jp/business/testtool_wg/pdf/Testtool_beginningGuide_Version1.0.0.pdf


自動化といえば？（プロセス）

テスト分析：テスト対象を理解してテストすべきことを明確にする要件管理ツール

テスト設計：テスト条件を確認する具体的なパターンを見込む原因結果グラフツール、組合せテスト支援ツール（直交表、オールペア）、

状態遷移テストツール、動的解析ツール、カバレッジ計測ツール、その他

テスト実装：テストを実行できるための一連の作業シミュレータ（スタブツール）、ラボイメージ、データジェネレータ、ケース管理ツール

テスト実行：通常「テスト」と呼ばれる作業ユニットテストツール、キャプチャ/リプレイツール、性能テストツール

セキュリティテストツール、テスト自動実行支援ツール

その他：コード解析、テストウェア管理、テスト結果管理、インシデント管理

自動化？テスト？に関わるプロセスを紹介 ※「テストツール丸わかりガイド」より http://aster.or.jp/business/testtool_wg/pdf/Testtool_beginningGuide_Version1.0.0.pdf

まず「自動化といえば…」で

考えるべき範囲は

この辺になるかと思います。


自動化といえば？（テストの考え）

テストの考え方。いろいろ有りますが、今回紹介するのは

「何を見る？」と「どうやって見る？」の考え方。

何を見る？

どうやって見る？


何を見る？

ぶっちゃけ、皆さんなら勘でOK。

…ですが、一応テストな人の考え方で紹介してみます。

ここは「自動化を対象」した考えではなく、

「テストを対象」した考えで紹介です。ここからは

ポットの

具体例を多数

© SESSAME

http://www.sessame.jp/


何を見る？（テスト対象）

例えば、「テスト対象」≒バグをもつもの、テストで保証する対象。

ターゲットを考えるにはどうしましょう？とあるシステムでは？

他社製


装置②

アプリ②-1

装置②

アプリ②-2

装置②

アプリ②-3

プロセスB





他社製

データ

機能

振舞い

コンポーネント、

クラス

ソースコード、

メソッド


装置②

アプリ②-1

装置②

アプリ②-2

装置②

アプリ②-3

プロセスB

シナリオ

ユース

ケース

ミスユース

ケース





他社製

広さ

深さ

データ

機能

振舞い

「広さ」と「深さ」双方が

あるというイメージが

分かりやすいかも。


装置②

アプリ②-1

装置②

アプリ②-2

装置②

アプリ②-3

シナリオ

ユース

ケース

ミスユース

ケース

プロセスB


クラス


メソッド




「ポット」を考えてみると…？

HW領域

SW

領域

プロダクト

ユーザ

危険性

操作

サービスお湯、ミルク等を介しての

ユーザへの価値提供




「ポット」を考えてみると…？対象を表現する方法は…？

ユースケース

ミスユースケース/FTA等

シナリオ H

W領域

SW

設計/クラス・コンポーネント

ソースコード

関数単位

HW

I/F

機能

ふるまい

プロダクト

ユーザ

危険性

操作

サービスお湯、ミルク等を介しての

ユーザへの価値提供


何を見る？（性質）

あとは、「品質特性」やら「テストタイプ（特定のテストの集合体）」…

対象に対して、「何の性質を見る？」を考えるためのモノです。

※Myライブラリからの抜粋

品質特性（ISO9126）

機能性

信頼性

使用性

効率性

保守性

移植性

適切さ

正確性

相互運用性

セキュリティ

成熟度

フォールトレランス

復元力

理解のしやすさ

学習のしやすさ

操作のしやすさ

魅力

時間挙動

資源の活用度

分析のしやすさ

変更のしやすさ

安定性

テストのしやすさ

順応性

インストールのしやすさ

共存力

置換製


何を見る？（性質）

あとは、「品質特性」やら「テストタイプ（特定のテストの集合体）」…

対象に対して、「何の性質を見る？」を考えるためのモノです。

※Myライブラリからの抜粋引き出しを持っていると便利です。

Mayersの

システムテストカテゴリ

Facility Testing

Volume Testing

Stress Testing

Usability Testing

Security Testing

Performance Testing

Storage Testing

Configuration Testing

Compatibility/conversion Testing

Installability Testing

Reliability Testing

Recovery Testing

Serviceability Testing

Documentation Testing

Procedure Testing

機能テスト

ボリュームテスト

ストレステスト

ユーザビリティテスト

セキュリティテスト

性能/パフォーマンステスト

ストレージテスト

設定/コンフィグテスト

互換性/コンパチテスト

インストーラビリティテスト

信頼性テスト

リカバリーテスト

サービスアビリティテスト

ドキュメンテーションテスト

手続きテスト

Myersのシステムテストカテゴリ


何を見る？（対象×性質）

それぞれの対象に対して、何を見るかを考える。

これはテストの狙いどころですが、自動化を考える時も同じでしょう。

他社製

データ

機能

振舞い


装置②

アプリ②-1

装置②

アプリ②-2

装置②

アプリ②-3

シナリオ

ユース

ケース

ミスユース

ケース

プロセスB


クラス


メソッド

装置間I/F 機能性。

装置間データのボリューム。

瞬間的、平均的な負荷。

データのサイズ（1ファイル、最大蓄積）、ログローテート

状態遷移

競合確認

単体テスト

境界値

パスカバレッジ

処理レスポンス、ユーザビリティ確認

手順ミス時の復旧

繰り返しの信頼性

※続きは「WARAI」で＾＾

機能テスト

パラメータ組合せによる論理確認



※ツールとは関連しますが、ツール直接の話はありません。

システムテストの方法を考えてみるというものです。

某SNSK流の自動化の考え方は、以下という話です。

Drive（駆動）、Judge（判断）、Report（報告）

対象

対象







ツール

（Drive）

対象

対象

対象







ツール

（Drive）

対象

対象

対象

対象

ツール

（Judge）







ツール

（Drive）

対象

対象

対象

対象

ツール

（Judge） Mail

orz…

ツール

（Report）







ツール

（Drive）

対象

対象

対象

対象

ツール

（Judge） Mail

orz…

ツール

（Report）

対象を計算機 or

シミュレータ上から

直接操作

操作に対して

応答、反応がある





組込みではどうしましょ？





組込みではどうしましょ？

おいくら

万円？


ツール

（Drive）




組込みではどうしましょ？ ⇒ 適度な仕組みが必要

ツール

（Judge）

【センサ状態】温度、水位

【制御状態】ヒータ、ポンプ、温度制御

【その他】CPU、メモリ、タスク切替

話題沸騰モニタ

85 ℃

沸騰中

ON ヒータ


試験のための

機能、テストが必要

⇒ROIを考えよう！ツール

（Drive）




Drive、Control、Monitor、Judge、Reportという感じかなと。

ツール

（Judge）

【センサ状態】温度、水位

【制御状態】ヒータ、ポンプ、温度制御

【その他】CPU、メモリ、タスク切替

話題沸騰モニタ

85 ℃

沸騰中

ON ヒータ

Control

Monitor


ばらして考えてみよう

Drive どうやってシステムを駆動させるべきか？

結構ツールがあるので、省略（UWSC、WSH、bat、sh、Sikuli…）

Control シミュレータの開発準備や、特別なI/Fを別途用意する必要があるか？

別途H/Wや環境の制御まで考える必要があるか？

Monitor 対象に対して状態通知の仕組みを用意すべきか？外部の環境は？

制御の応答、イベント、ポーリング、画面での判定…

パフォーマンステストなら、時間を測定する仕組みも必要。

Judge 作りこみ、判断が正しいかの妥当性が大事、何を見る？どうやって見る？

Monitorとの連携で、必要な確認項目を抽出して確実に検出

Report 繰返し確認が必要な部分は簡単にしておく

※個産なので？、個人的にはそれほど重要視してません…

ツール

（Drive）

ツール

（Judge）

ツール

（Control）

ツール

（Monitor）テスト対象

Control

Monitor


ツール

（Drive）

ツール

（Judge）

ツール

（Control）

ツール


Control

Monitor












※個産なので？、個人的にはそれほど重要視してません…

テストを詳細設計するフェーズ、

実施のフェーズでは間に合わない。

開発段階、初期段階から

仕組みを考える必要がある。


ツール

（Drive）

ツール

（Judge）

ツール

（Control）

ツール


Control

Monitor












※個産なので？、個人的にはそれほど重要視してません… テスト詳細設計～実施の段階で

細かい保守性を含めての

改善を行うことが可能。

現場での施行錯誤が生きる場所


仕組みづくり

他社製


装置②

アプリ②-1

装置②

アプリ②-2

装置②

アプリ②-3

プロセスB

何を対象に、何を見るか？を考えながら仕組みづくり。


仕組みづくり

シミュレータ


装置②

アプリ②-1

装置②

アプリ②-2

装置②

アプリ②-3

プロセスB


実現のために必要な仕組みを考える。※スケジュール、ROIが絡む

データ

機能

振舞い

シミュレータ

Drive用PC

Driveツール

Controlツール

シナリオベース

制御実施

Controlツール


仕組みづくり

シミュレータ


装置②

アプリ②-1

装置②

アプリ②-2

装置②

アプリ②-3

プロセスB


システム的な仕組みを考えながら構築する必要があるなど。

データ

機能

振舞い

シミュレータ

Drive用PC

Driveツール

Controlツール

Monitor機能

シナリオベース

制御実施

Monitor

データ

データ収集

Judge判定

Monitor機能


仕組みづくり：マネジメント

実施内容

　システムテスト②

　操作パネル妥当性

妥当性確認、検証

統合/システムテスト

　統合テスト①、②

2013年2月

　システムテスト①

2012年11月 2012年12月 2013年1月

　温度制御、ヒータ　サーミスタ検証

　スモークテスト

統合テスト①、②テスト計画、

分析システムテスト②

妥当性検証

温度制御系検証

ｽﾓｰｸ

システムテスト①

準備

準備

販売開始：

2/15(金)

操作パネルシミュレータ

①操作パネル

妥当性検証 ②温度制御検証

シミュレータを用意して、操作感、ユーザビリティと状態遷移の妥当性を確認

温度制御検証環境

ヒータ

ﾌﾟﾛﾄﾀｲﾌﾟ

シミュレータを用いたテスト環境

サーミスタ

ﾌﾟﾛﾄﾀｲﾌﾟ開発したHWと

温度制御試験用SWを用意、

温度制御の妥当性を確認

温度制御

試験用S/W

③操作パネル

完成前テスト

操作パネルI/F以外の論理確認、

試験を実施。シミュレータを活用して試験を実施。

④操作パネル完成後

量産/出荷前確認テスト

（システムテスト）操作パネルを含めた全体確認

（出荷前確認テスト）シミュレータを活用して自動化環境を構築して効率化を狙う

自動

制御

ﾂｰﾙ

ヒータユニットプロトタイプ完成

新規サーミスタ評価版購入

操作パネルの完成！


スペシャルサンクス

自動化構築の枠組み

(Drive/Judge/Report)は

@SNSKの検討がベースです。

Special Thanks!

Tabok 自己流自動化ふりかえり展開版

Documents

Transcript of Tabok 自己流自動化ふりかえり展開版

Tabok 自己流自動化ふりかえり 展開版

Documents

Transcript of Tabok 自己流自動化ふりかえり 展開版

Tabok 自己流自動化ふりかえり展開版

Transcript of Tabok 自己流自動化ふりかえり展開版