Warai160109 テストアーキテクチャのおはなし

1 2016年1月 WARAI アーキテクチャのはなし

WARAI（関西SWテスト勉強会）160109

テストアーキテクチャのおはなし～見せて貰おうか！

今までのテストアーキテクチャとやらを～

みずのり（水野のりゆき）＠WARAI（関西SWテスト勉強会）


見せて貰おうか

テストアーキテクチャの性能とやらを！見せて貰おうか

テストアーキテクチャの性能とやらを！

注意事項：各チームへのコメントにつきましては、本スライド作成者の個人の意見でありまして実際の審査とは何の関連も有りません。また、実際はテストアーキテクチャ以外の評価も有りますが、その部分は記載除外しております。


テストアーキテクチャって？

よく分かりませんので、過去、テスト設計コンテストで

アーキテクチャを作った内容を見てみましょう！

取り上げるチームはこちら！ ※各年1位/2位チーム選定

2012：TETTAN、あまがさきてすとくらぶ

2013：TETTAN

2014：TFC Kariya、MKE98

2015：しなてす、TEVASAKI


順次コメント付きで見ていきます

※以下の記載はスライド作成者の個人的なコメントです。

2012：あまがさきてすとくらぶ⇒「表」での表現を実施

品質目標重要点対策H/W異常異常発生時のロジック対処センサ故障異常事態の検知ロジックヒータ故障：過熱継続 ……センサへのノイズ電圧/温度環境による確認H/W依存のタイミング変化タイミング変化に対して試験蹴飛ばす、落とすマニュアルに記載するふたを閉め忘れる蓋開け時のロジック確認…ふりまわす振動試験による確認ボタン同時押し、連打競合動作の確認H/W依存のタイミング変化タイミング変化に対して試験

わざと、意地悪

発生要因

安全性やけど怪我をしない

H/W 故障によるもの

故障以外

人的要因

無意識

抽出項目を「テストカテゴリ」と「テスト対象」に分類

安全性

競合

ロジック

仕様、要求

シナリオ

状態遷移

他にもあるよ

タイミング変化

他にもあるよ

意地悪

負荷時性能

環境テストカテゴリテスト対象

参考

http://jasst.jp/symposium/jasst12tokyo/report.html#plan9




2012-2013：TETTAN

@2012

現在主流の「テストアーキテクチャ」らしきものの原型登場？

テスト対象と確認項目の関連性を1枚図で表した内容

テスト要求/仕様が構造化されたようなもの

作り方、表記に関しては思いつきレベル？でよく分かんない

（その他）CFDの順番を考慮しない考え方を提案

参考





2012-2013：TETTAN

@2013

「アーキテクチャ」として明記、記述方法を明示

テスト要求とテスト仕様をUSDM表記にする方針

テスト要求/仕様の構造を示し、テスト要求と作りこむ

テスト要求があれば詳細設計にはいくことが出来る。

※テスト要求作成時の補助的資料という扱いになりそう。

参考

http://www.aster.or.jp/business/contest/contest2013.html




2014：MKE98

構造（テスト対象のCPU単位）を考慮した積み上げを行っている

※組込み屋的なHWとの組合せの意識と思われる

HW範囲に対して機能を割り当てている

テストアーキテクチャ⇒テスト要求一覧を作成という

プロセスが見える（本来提示されているプロセスの逆？）

参考





2014：TFC Kariya

提示された資料では正直わかんない

テストベースをモデル化（USDM/DFD/HW構成）主に機能ベースで関連整理

機能ベースの関連性をテスト側に割り当てたアーキテクチャ

1枚図で非機能面の狙い目なりを表現している

今まで分からなかったテストアーキテクチャの図を

作成するまでの手順を、よく見れば紹介している。

テスト要求との関連については資料からはわかんにゃい

参考




※個人的にポイント忘れるので、メモしておきます。

2015：TEVASAKIplus

アーキテクチャらしきものは存在しているようにみえない

フレームワーク/パターン的な検討ベースを用いた

テスト要求項目作成までの流れが作りこまれている

※パターンの表記は特に現場でも使えそうな感じ

2015：しなてす

テスト要求作成後、テストアーキテクチャを作成する段階で

トレードオフで方針を決めて構造化している

明示的にテスト要求⇒テストアーキテクチャ設計という

流れが提示されている参考



以上、所感！

テスト要求というテストを実施すべき項目を

洗い出すフェーズは必要とは感じられる。

その際、全体が見える補助ネタがあると便利。

現状コンテストで提示されている

アーキテクチャが役立つレベルか？は検討要。（テスト要求モデル⇒テスト詳細設計で十分かも？）


ディスカッション結果の紹介

テストアーキテクチャの印象

（直感的に）使えそう、使わない？

何のために役立つ？ ※ただみんなが使うから、だとイマイチ

疑問点

使えそう

作成するための知識や技術が必要に見えるので、簡単に出来ないと感じる

他のやり方の採用

お堅い組織の説明も出来る

他案件でも一部（パターン的に）流用で使うことが出来る

派生案件への流用、見直しの時にあると役立つ

新規案件で作ると継続的に使えそうなので良さそう

分析作業が出来ていないと使えるかどうかの判断が出来ない

アーキテクチャ図まで作る場合にはプロセス・作業が重い感じがする

巨大なプロジェクトで、全体を見る場合には使えそう

マインドマップでざっくりまとめて作る方法もある

★以下のコメントは、各個人の作業想定の意見込みです

テストケースを作る際は表でまとめる作業や、ゆもつよメソッドあたりの方が使いやすそう

逆にコストが確定済みであれば、品質範囲を議論できる

品質とコストのトレードオフ網羅基準を決めてテストケース数との関連を議論できる、かも

見積り情報

いつ終わるの？と聞かれる時もあるので、見積りもあると良い第三者への説明がやりやすい

いきなりテストケースを書くよりは、抜け漏れに気付きやすい

目的に応じて図の分け方（切り口）が変わる

テストパターンの考慮

自動化有無

各項目の規模

リスクレベルで整理

分け方 or 属性項目を以下に記載

テスト実施する、実施しない

整理の観点、ポイント

テスト要求モデル、その整理

整理・分類を行っている

変更による影響範囲もわかる関連も分かると良い

順番をを知るには関連が分かると良いテストは順番が大事

順番と関連がキーワード

なるほど、わからん

何のために役立つ？

（直感的に）使えそう、使わない？

テストアーキテクチャの印象

質問ベース

自由意見

テストアーキテクチャ

ディスカッション


WARAI（関西SWテスト勉強会）160109

テストアーキテクチャのおはなし～おまけの資料～

みずのり（水野のりゆき）＠WARAI（関西SWテスト勉強会）


作ったネタ紹介

分かりづらい「テストアーキテクチャ」に対していくつかネタを作ってみました。 ※一部「趣味」的な記載がありますので注意

1．アーキテクチャの意味・考え方

2．テストアーキテクチャの役立ちどころ

3．上下から辿る：下位テストケースから

4．上下から辿る：上位要求から

5．開発との対比を考える



「アーキテクチャ」の説明（SWアーキテクチャ）

もとは建築における建築様式や工法、構造などを表す言葉

ITの分野では、構成要素などにおける、

基本設計や共通仕様、設計思想などを指すことが多い。

抽象的、基本的な構造や設計、動作原理、実現方式などを表す

SWアーキテクチャ抽象化と問題の分割によって複雑性を減らすことを主に念頭に置いたもの

記述方法：初期のデザインパターン、ベストプラクティス、記述言語、形式論理

引用：Wiki ソフトウェアアーキテクチャ

https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2

%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3



「アーキテクチャ」の説明

アーキテクチャ記述言語（ADL）特徴

システム関係者全員がアーキテクチャのやり取りするのに適している

アーキテクチャ作成/修正/検証に必要な機能を備えていること。

その後の実装に必要な情報が提供できること。設計段階でADLの

記述に追記していき、最終的システム仕様が記述できる。

一般的なアーキテクチャのスタイルを表現できること。

分析的機能を備えるか、プロトタイプ実装を簡単に生成できること。

引用：Wiki アーキテクチャ記述言語

https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%8

1%E3%83%A3%E8%A8%98%E8%BF%B0%E8%A8%80%E8%AA%9E



「アーキテクチャ」の説明

アーキテクチャは組織構造にも影響する場合も。

部門A

- 通信機器設計課

- 回路設計課

- 熱機器観測課

- 電池設計課

・・・

部門B

- 地上通信機器設計課

- 構造設計課

- 高電力設計課

- ソフトウェア課

・・・



「アーキテクチャ」の要素をいくつか出すと…

建築的な「構造」に対して…

・抽象的な表現、問題分割で複雑性低減

・全員の共有

・追記型で最終形式にすることが出来る

・検証が出来ると良い

多くの人が使用して、組織構造までも影響することも。

テストアーキテクチャ設計は

テストスイートの全体像を把握しやすくしつつ

後工程や派生製品、後継プロジェクトが作業しやすくなるように

テスト要求モデルを整理する工程

引用：テスト観点に基づくテスト開発方法論VSTePの概要

http://qualab.jp/materials/VSTeP.130510.bw.pdf



アーキテクチャ自体/アーキテクチャ的な図があると… 引用：テスト設計コンテスト2014


テスト設計コンテスト2015


テスト観点に基づくテスト開発方法論VSTePの概要




アーキテクチャ自体/アーキテクチャ的な図があると… ・説明時に活用することが出来る（説明責任）・巨大なモノ、複雑なものであるほど理解しやすくなる

・作成段階での確認によるフィードバックがされやすくなる

・（表記により）指示・方針展開にもつながる

・変化点を判断しやすくなる（例：試験後半でのトレードオフ）・同じものを作りこまなくても良いようになる（抽象化の活用）・派生案件や他案件にも活用できる。

・分担が出来るようになる（問題分割）引用：テスト設計コンテスト2014








アーキテクチャ自体/アーキテクチャ的な図があると… ・説明時に活用することが出来る（説明責任）・巨大なモノ、複雑なものであるほど理解しやすくなる

・作成段階での確認によるフィードバックがされやすくなる

・（表記により）指示・方針展開にもつながる

・変化点を判断しやすくなる（例：試験後半でのトレードオフ）・同じものを作りこまなくても良いようになる（抽象化の活用）・派生案件や他案件にも活用できる。

・分担が出来るようになる（問題分割）

説明・理解＜参考：ロジカルシンキングの狙い＞

・理解

・フィードバック

・アクション

抽象化

の活用

問題

の分割



「役立ちどころ」を意識しながら、テストケースから

テストアーキテクチャの役割を辿ってみましょう

※注：説明はスクリプトテストのみをターゲットにしております

テストケース




技法

その他

分析

ターゲット

範囲

大人人数

子供人数

合計金額

人

人

円

製品画面

過去の

テスト

テストベース

同値分割境界値分析デシジョンテーブル CFD/CEG 直交表、All Pair法状態遷移図/表

テストケース

主に「テスト技法」はテストケースを作るための手法です。テスト技法を使う等でテストケースを作るためには、

製品画面など何らかのターゲット範囲を決める必要があります。



テストケース


技法

その他

分析

ターゲット

範囲

大人人数

子供人数

合計金額

人

人

円

製品画面

過去の

テスト

テストベース


テストケーステストケーステストケース

テストケース技法

その他

分析

ターゲット

範囲テストケーステストケーステストケース


その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット


１ターゲット範囲から生成されるテストケースは複数存在します。また、ターゲット範囲は多数存在しております。



テストケース


技法

その他

分析

ターゲット

範囲

大人人数

子供人数

合計金額

人

人

円

製品画面

過去の

テスト

テストベース




その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット


テスト設計担当

テストケースを作る時には

気にしたくない


集中しないと抜けも出るし効率も悪い…

テスト担当者はテストケース作成に集中する必要があります。その際、複数のターゲット範囲で抜けがあるコトは考えづらいです。



テストケース


技法

その他

分析

ターゲット

範囲

大人人数

子供人数

合計金額

人

人

円

製品画面

過去の

テスト

テストベース




その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット







何らかの図や表で全体としての抜けが分かり、議論できる内容があると便利。それが各テストとのリンクがあると使いやすいです。



テストケース


技法

その他

分析

ターゲット

範囲

大人人数

子供人数

合計金額

人

人

円

製品画面

過去の

テスト

テストベース




その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット







抽象化の活用

問題の分割

抽象化の活用

ドメイン単位で分析しやすい

パターンなりがあるはず

他プロジェクトの

検討方法を流用

そこで使われる図や表（アーキテクチャ？）は、抽象化や問題の分割により担当分担や流用が出来ると役立ちます。



テストケース


技法

その他

分析

ターゲット

範囲

大人人数

子供人数

合計金額

人

人

円

製品画面

過去の

テスト

テストベース




その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット



その他

分析

ターゲット







テスト実施

環境の準備（治具ツール検討）試験のやりやすさ自動化有無 …

抽象化の活用

問題の分割

実際のテスト作業としてはテスト実施までが有ります。この辺をテストアーキテクチャ図でリンクできると良いですね。



「役立ちどころ」を意識しながら、上位の要求から

テストアーキテクチャの役割を辿ってみましょう


上位

要求



開発プロダクトテストケーステストケース

テスト・品質担当

(BtoB)契約定義

(BtoC)企画書

要求仕様書

もしくは何か

契約で定義される内容や企画書から要求仕様書が作られて、開発によりプロダクトが作られ、テストケースで確認されます。



テストケース開発プロダクトテストケーステストケース


(BtoB)契約定義

(BtoC)企画書

要求仕様書

もしくは何か

問題発生

暗黙の前提

前商品のクセ

テストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケース

顧客監査担当

テストやプロセスで説明（おもにBtoB）

テストで説明（おもにBtoB）

社内での確認

社内他の確認

改善！

BtoBでの受け入れでは、テストケースで説明が行われる場合も。また、問題発生時の説明や改善時にもテストケースが活用されます。





(BtoB)契約定義

(BtoC)企画書

要求仕様書

もしくは何か

問題発生

暗黙の前提

前商品のクセ


顧客監査担当よく分かんない抜けないの？

テストやプロセスで説明（おもにBtoB）


安心？

納得？

テストケースでXXXのように確認してます…

社内での確認

社内他の確認

改善！

テストケースは大量にあり、テストケース単体で説明は大変です。安心したい顧客に理解して貰えない場合もあるでしょう。





(BtoB)契約定義

(BtoC)企画書

要求仕様書

もしくは何か

問題発生

暗黙の前提

前商品のクセ


顧客監査担当うーん、不具合はダメだがやり方は悪くなかったと

判断しましょうテストやプロセスで説明（おもにBtoB）

安心

テスト全体でXXXで見てます。今回の問題は…

社内での確認

社内他の確認


納得

改善！

説明・理解・理解

・フィードバック

・アクション

そこで、テスト全体を俯瞰できるような図を用いて説明、辿ることで理解を容易にして納得して貰うことも出来るかもしれません。



少しだけ開発側のアーキテクチャ設計との

対比を行ってみましょう。 ※かなりマニアックです。

注意事項：こちらの内容は作成者の個人的趣味が多数入ってます。言葉での説明で補足する部分も多くありますので、スライド内容だけで理解しようとするとテストアーキテクチャへの理解を逆に損ねてしまう可能性がありますのでご注意ください。



モノを作る、デザインするという考え方。

要求

ニーズ

1．形をコンテキスト

から作り出す

（or 自然に発生する）

2．分析段階で分解して

統合して形を作る＠デカルト的

コンテキスト

フォース（傾向など）

デザイン形分析

統合

（綜合）フォース/コンテキストが

形を作る例



みんな大好きV字に当てはめると…？

要求分析

要求分析

方式設計

詳細設計

SW適格性

確認ﾃｽﾄ

結合ﾃｽﾄ

単体ﾃｽﾄ

ｺｰﾄﾞ作成

綜合

方式設計？で

なんか形が

決まる

詳細設計の

分解は

それっぽいそういえば

組み立てる作業は？

要求

ワールド

形

ワールド

※SLCP：

Software Life Cycle Process

（共通フレーム参考）ベース


※SLCP：

Software Life Cycle Process

（共通フレーム参考）ベース


みんな大好きV字に当てはめると…？

要求分析

要求分析

方式設計

詳細設計

SW適格性

確認ﾃｽﾄ

結合ﾃｽﾄ

単体ﾃｽﾄ

ｺｰﾄﾞ作成

綜合

方式設計？で

なんか形が

決まる

詳細設計の

分解は

それっぽいそういえば

組み立てる作業は？

ひとまず、こっちに着目してみる



実際の開発でやっていること

要求方式設計案

要求形

実際の開発では要求を形に置き換える作業を行っているとします。要求から「形」として方式設計の案を作る作業をするとします。





要求形

要求から形の変換というのは大きく飛躍が発生することが多いです。大きな隔たりがあると考えます。

大きな

隔たり

なお、形の世界はデカルト的な分析作業が適用できると考えます。


詳細設計




小さい要求や

ユーザー

ストーリー

詳細設計

⇒方式設計の分解

詳細設計

詳細設計詳細設計


複雑でありアーキテクチャで解決する箇所

要求形

小さい要求

小さい要求

小さい要求

小さい要求

大きな

隔たり

実際は要求を小さく分割、方式設計も詳細設計へ細かくします。ここで、要求と形は隔たりが大きく、この部分がアーキテクチャで

解決が必要となる部分とも考えられます。


詳細設計




小さい要求や

ユーザー

ストーリー

小さい要求

小さい要求

小さい要求

小さい要求

詳細設計

⇒方式設計の分解

詳細設計



複雑でありアーキテクチャで解決する箇所

トレーサビリティマトリクス＠XDDP

要求形

この要求から形（方式設計～詳細設計）の難しい隔たりに対しては XDDPではTMを用いての分析・解決を行う等を行っています。



テストプロセスでは？

テスト要求

小さい要求

小さい要求

小さい要求

小さい要求

小さい要求

小さい要求



テスト要求モデル

要求形

アーキテクチャ？

※あくまで個人の意見です。大きな

隔たり？

さて、同様の流れをテストプロセスで考えてみましょう。テスト要求を分解し小さくします。この際、要求モデルも作ります。




テスト要求




要求形

アーキテクチャ？

※あくまで個人の意見です。

小さい要求

小さい要求

小さい要求

小さい要求

小さい要求

小さい要求

意外と

小さい

隔たり？

今までの（テスコン）事例を見ると、小さい要求からテストケースを作ることが出来そうです。要求⇔形の隔たりは意外と小さいかも？




テスト何とか

？？




≒テストアーキテクチャ要求形


テスト要求分析

テストアーキテクチャ分析

テスト

詳細設計

小さい要求

小さい要求

小さい要求

小さい要求

小さい要求

小さい要求

要求と形という対比では、テスト要求モデル≒テストアーキテクチャという考え方で「形」サイドへの割り当てが出来るかもしれません。




テスト何とか

⇒テスト要求B



要求形


テスト要求A

品質的な要求

企画や狙い

・・・

テスト要求分析

テストアーキテクチャ分析

テスト

詳細設計

小さい要求

小さい要求

小さい要求

小さい要求

小さい要求

小さい要求

現状の分割では「テスト要求」の役割が大きいのかもしれません。テスト要求の作業を下記A/Bのように別の区切りで分けて

名前付けを考えて整理が必要かもしれませんね。

テスト要求Bモデル

≒テストアーキテクチャ


つーことで

なげっぱでおわります！

何処かでブログるかも

複数のモノの見方を得て、

自分に役立つ理解や納得感から

「役立つ」モノを採用する、というように

して頂ければ良いと考えてますー。

（・ω<）てへぺろ


引用









Wiki ソフトウェアアーキテクチャ

https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%

A7%E3%82%A2%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%

83%81%E3%83%A3

Wiki アーキテクチャ記述言語

https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82

%AF%E3%83%81%E3%83%A3%E8%A8%98%E8%BF%B0%E8%A8%80%E8%AA%9E



Technology

Warai160109 テストアーキテクチャのおはなし