Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,153 views

Published on

関西ソフトウェアテスト勉強会で一部話してみたテストアーキテクチャのおはなしの資料です。口頭で説明すること前提で作っておりますので、資料だけで見てみると分かりづらい可能性があります。

Published in: Technology
  • Be the first to comment

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

  1. 1. 12016年1月 WARAI アーキテクチャのはなし WARAI(関西SWテスト勉強会)160109 テストアーキテクチャ のおはなし ~見せて貰おうか! 今までのテストアーキテクチャとやらを~ みずのり(水野のりゆき) @WARAI(関西SWテスト勉強会)
  2. 2. 22016年1月 WARAI アーキテクチャのはなし 見せて貰おうか テストアーキテクチャの性能とやらを! 見せて貰おうか テストアーキテクチャの性能とやらを! 注意事項: 各チームへのコメントにつきましては、 本スライド作成者の個人の意見でありまして 実際の審査とは何の関連も有りません。 また、実際はテストアーキテクチャ以外の評価も 有りますが、その部分は記載除外しております。
  3. 3. 32016年1月 WARAI アーキテクチャのはなし テストアーキテクチャって? よく分かりませんので、過去、テスト設計コンテストで アーキテクチャを作った内容を見てみましょう! 取り上げるチームはこちら! ※各年1位/2位チーム選定 2012:TETTAN、あまがさきてすとくらぶ 2013:TETTAN 2014:TFC Kariya、MKE98 2015:しなてす、TEVASAKI
  4. 4. 42016年1月 WARAI アーキテクチャのはなし 順次コメント付きで見ていきます ※以下の記載はスライド作成者の個人的なコメントです。 2012:あまがさきてすとくらぶ⇒「表」での表現を実施 品質目標 重要点 対策 H/W異常 異常発生時のロジック対処 センサ故障 異常事態の検知ロジック ヒータ故障:過熱継続 … … センサへのノイズ 電圧/温度環境による確認 H/W依存のタイミング変化 タイミング変化に対して試験 蹴飛ばす、落とす マニュアルに記載する ふたを閉め忘れる 蓋開け時のロジック確認 … ふりまわす 振動試験による確認 ボタン同時押し、連打 競合動作の確認 H/W依存のタイミング変化 タイミング変化に対して試験 わざと、 意地悪 発生要因 安全性 やけど 怪我を しない H/W 故障に よるもの 故障以外 人的 要因 無意識 抽出項目を「テストカテゴリ」と「テスト対象」に分類 安全性 競合 ロジック 仕様、要求 シナリオ 状態遷移 他にも あるよ タイミング変化 他にも あるよ 意地悪 負荷時性能 環境テストカテゴリテスト 対象 参考 http://jasst.jp/symposium/jasst12tokyo/report.html#plan9
  5. 5. 52016年1月 WARAI アーキテクチャのはなし 順次コメント付きで見ていきます ※以下の記載はスライド作成者の個人的なコメントです。 2012-2013:TETTAN @2012 現在主流の「テストアーキテクチャ」らしきものの原型登場? テスト対象と確認項目の関連性を1枚図で表した内容 テスト要求/仕様が構造化されたようなもの 作り方、表記に関しては思いつきレベル?でよく分かんない (その他)CFDの順番を考慮しない考え方を提案 参考 http://jasst.jp/symposium/jasst12tokyo/report.html#plan9
  6. 6. 62016年1月 WARAI アーキテクチャのはなし 順次コメント付きで見ていきます ※以下の記載はスライド作成者の個人的なコメントです。 2012-2013:TETTAN @2013 「アーキテクチャ」として明記、記述方法を明示 テスト要求とテスト仕様をUSDM表記にする方針 テスト要求/仕様の構造を示し、テスト要求と作りこむ テスト要求があれば詳細設計にはいくことが出来る。 ※テスト要求作成時の補助的資料という扱いになりそう。 参考 http://www.aster.or.jp/business/contest/contest2013.html
  7. 7. 72016年1月 WARAI アーキテクチャのはなし 順次コメント付きで見ていきます ※以下の記載はスライド作成者の個人的なコメントです。 2014:MKE98 構造(テスト対象のCPU単位)を考慮した積み上げを行っている ※組込み屋的なHWとの組合せの意識と思われる HW範囲に対して機能を割り当てている テストアーキテクチャ⇒テスト要求一覧を作成という プロセスが見える(本来提示されているプロセスの逆?) 参考 http://www.aster.or.jp/business/contest/contest2014.html
  8. 8. 82016年1月 WARAI アーキテクチャのはなし 順次コメント付きで見ていきます ※以下の記載はスライド作成者の個人的なコメントです。 2014:TFC Kariya 提示された資料では正直わかんない テストベースをモデル化(USDM/DFD/HW構成) 主に機能ベースで関連整理 機能ベースの関連性をテスト側に割り当てたアーキテクチャ 1枚図で非機能面の狙い目なりを表現している 今まで分からなかったテストアーキテクチャの図を 作成するまでの手順を、よく見れば紹介している。 テスト要求との関連については資料からはわかんにゃい 参考 http://www.aster.or.jp/business/contest/contest2014.html
  9. 9. 92016年1月 WARAI アーキテクチャのはなし 順次コメント付きで見ていきます ※個人的にポイント忘れるので、メモしておきます。 2015:TEVASAKIplus アーキテクチャらしきものは存在しているようにみえない フレームワーク/パターン的な検討ベースを用いた テスト要求項目作成までの流れが作りこまれている ※パターンの表記は特に現場でも使えそうな感じ 2015:しなてす テスト要求作成後、テストアーキテクチャを作成する段階で トレードオフで方針を決めて構造化している 明示的にテスト要求⇒テストアーキテクチャ設計という 流れが提示されている 参考 http://www.aster.or.jp/business/contest/contest2015.html
  10. 10. 102016年1月 WARAI アーキテクチャのはなし 以上、所感! テスト要求というテストを実施すべき項目を 洗い出すフェーズは必要とは感じられる。 その際、全体が見える補助ネタがあると便利。 現状コンテストで提示されている アーキテクチャが役立つレベルか?は検討要。 (テスト要求モデル⇒テスト詳細設計で十分かも?)
  11. 11. 112016年1月 WARAI アーキテクチャのはなし ディスカッション結果の紹介 テストアーキテクチャの印象 (直感的に)使えそう、使わない? 何のために役立つ? ※ただみんなが使うから、だとイマイチ 疑問点 使えそう 作成するための知識や技術が必要に見えるので、簡単に出来ないと感じる 他のやり方の採用 お堅い組織の説明も出来る 他案件でも一部(パターン的に)流用で使うことが出来る 派生案件への流用、見直しの時にあると役立つ 新規案件で作ると継続的に使えそうなので良さそう 分析作業が出来ていないと使えるかどうかの判断が出来ない アーキテクチャ図まで作る場合にはプロセス・作業が重い感じがする 巨大なプロジェクトで、全体を見る場合には使えそう マインドマップでざっくりまとめて作る方法もある ★以下のコメントは、各個人の作業想定の意見込みです テストケースを作る際は表でまとめる作業や、 ゆもつよメソッドあたりの方が使いやすそう 逆にコストが確定済みであれば、品質範囲を議論できる 品質とコストのトレードオフ 網羅基準を決めてテストケース数 との関連を議論できる、かも 見積り情報 いつ終わるの?と聞かれる時もあるので、見積りもあると良い 第三者への説明がやりやすい いきなりテストケースを書くよりは、抜け漏れに気付きやすい 目的に応じて図の分け方(切り口)が変わる テストパターンの考慮 自動化有無 各項目の規模 リスクレベルで整理 分け方 or 属性項目を以下に記載 テスト実施する、実施しない 整理の観点、 ポイント テスト要求モデル、その整理 整理・分類を行っている 変更による影響範囲もわかる関連も分かると良い 順番をを知るには関連が分かると良いテストは順番が大事 順番と関連がキーワード なるほど、わからん 何のために役立つ? (直感的に)使えそう、使わない? テストアーキテクチャ の印象 質問ベース 自由意見 テストアーキテクチャ ディスカッション
  12. 12. 122016年1月 WARAI アーキテクチャのはなし WARAI(関西SWテスト勉強会)160109 テストアーキテクチャ のおはなし ~おまけの資料~ みずのり(水野のりゆき) @WARAI(関西SWテスト勉強会)
  13. 13. 132016年1月 WARAI アーキテクチャのはなし 作ったネタ紹介 分かりづらい「テストアーキテクチャ」 に対していくつかネタを作ってみました。 ※一部「趣味」的な記載がありますので注意 1.アーキテクチャの意味・考え方 2.テストアーキテクチャの役立ちどころ 3.上下から辿る:下位テストケースから 4.上下から辿る:上位要求から 5.開発との対比を考える
  14. 14. 142016年1月 WARAI アーキテクチャのはなし 1.アーキテクチャの意味・考え方 「アーキテクチャ」の説明(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
  15. 15. 152016年1月 WARAI アーキテクチャのはなし 1.アーキテクチャの意味・考え方 「アーキテクチャ」の説明 アーキテクチャ記述言語(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
  16. 16. 162016年1月 WARAI アーキテクチャのはなし 1.アーキテクチャの意味・考え方 「アーキテクチャ」の説明 アーキテクチャは組織構造にも影響する場合も。 部門A - 通信機器設計課 - 回路設計課 - 熱機器観測課 - 電池設計課 ・・・ 部門B - 地上通信機器設計課 - 構造設計課 - 高電力設計課 - ソフトウェア課 ・・・
  17. 17. 172016年1月 WARAI アーキテクチャのはなし 1.アーキテクチャの意味・考え方 「アーキテクチャ」の要素をいくつか出すと… 建築的な「構造」に対して… ・抽象的な表現、問題分割で複雑性低減 ・全員の共有 ・追記型で最終形式にすることが出来る ・検証が出来ると良い 多くの人が使用して、組織構造までも影響することも。 テストアーキテクチャ設計は テストスイートの全体像を把握しやすくしつつ 後工程や派生製品、後継プロジェクトが作業しやすくなるように テスト要求モデルを整理する工程 引用:テスト観点に基づくテスト開発方法論VSTePの概要 http://qualab.jp/materials/VSTeP.130510.bw.pdf
  18. 18. 182016年1月 WARAI アーキテクチャのはなし 2.テストアーキテクチャの役立ちどころ アーキテクチャ自体/アーキテクチャ的な図があると… 引用: テスト設計コンテスト2014 http://www.aster.or.jp/business/contest/contest2014.html テスト設計コンテスト2015 http://www.aster.or.jp/business/contest/contest2015.html テスト観点に基づくテスト開発方法論VSTePの概要 http://qualab.jp/materials/VSTeP.130510.bw.pdf
  19. 19. 192016年1月 WARAI アーキテクチャのはなし 2.テストアーキテクチャの役立ちどころ アーキテクチャ自体/アーキテクチャ的な図があると… ・説明時に活用することが出来る(説明責任) ・巨大なモノ、複雑なものであるほど理解しやすくなる ・作成段階での確認によるフィードバックがされやすくなる ・(表記により)指示・方針展開にもつながる ・変化点を判断しやすくなる(例:試験後半でのトレードオフ) ・同じものを作りこまなくても良いようになる(抽象化の活用) ・派生案件や他案件にも活用できる。 ・分担が出来るようになる(問題分割) 引用: テスト設計コンテスト2014 http://www.aster.or.jp/business/contest/contest2014.html テスト設計コンテスト2015 http://www.aster.or.jp/business/contest/contest2015.html テスト観点に基づくテスト開発方法論VSTePの概要 http://qualab.jp/materials/VSTeP.130510.bw.pdf
  20. 20. 202016年1月 WARAI アーキテクチャのはなし 2.テストアーキテクチャの役立ちどころ アーキテクチャ自体/アーキテクチャ的な図があると… ・説明時に活用することが出来る(説明責任) ・巨大なモノ、複雑なものであるほど理解しやすくなる ・作成段階での確認によるフィードバックがされやすくなる ・(表記により)指示・方針展開にもつながる ・変化点を判断しやすくなる(例:試験後半でのトレードオフ) ・同じものを作りこまなくても良いようになる(抽象化の活用) ・派生案件や他案件にも活用できる。 ・分担が出来るようになる(問題分割) 説明・理解 <参考:ロジカルシンキングの狙い> ・理解 ・フィードバック ・アクション 抽象化 の活用 問題 の分割
  21. 21. 212016年1月 WARAI アーキテクチャのはなし 3.上下から辿る:下位テストケースから 「役立ちどころ」を意識しながら、テストケースから テストアーキテクチャの役割を辿ってみましょう ※注:説明はスクリプトテストのみをターゲットにしております テスト ケース
  22. 22. 222016年1月 WARAI アーキテクチャのはなし 3.上下から辿る:下位テストケースから ※注:説明はスクリプトテストのみをターゲットにしております 技法 その他 分析 ターゲット 範囲 大人人数 子供人数 合計金額 人 人 円 製品画面 過去の テスト テストベース 同値分割 境界値分析 デシジョンテーブル CFD/CEG 直交表、All Pair法 状態遷移図/表 テストケース 主に「テスト技法」はテストケースを作るための手法です。 テスト技法を使う等でテストケースを作るためには、 製品画面など何らかのターゲット範囲を決める必要があります。
  23. 23. 232016年1月 WARAI アーキテクチャのはなし 3.上下から辿る:下位テストケースから テストケース ※注:説明はスクリプトテストのみをターゲットにしております 技法 その他 分析 ターゲット 範囲 大人人数 子供人数 合計金額 人 人 円 製品画面 過去の テスト テストベース 同値分割 境界値分析 デシジョンテーブル CFD/CEG 直交表、All Pair法 状態遷移図/表 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース 1ターゲット範囲から生成されるテストケースは複数存在します。 また、ターゲット範囲は多数存在しております。
  24. 24. 242016年1月 WARAI アーキテクチャのはなし 3.上下から辿る:下位テストケースから テストケース ※注:説明はスクリプトテストのみをターゲットにしております 技法 その他 分析 ターゲット 範囲 大人人数 子供人数 合計金額 人 人 円 製品画面 過去の テスト テストベース 同値分割 境界値分析 デシジョンテーブル CFD/CEG 直交表、All Pair法 状態遷移図/表 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テスト 設計担当 テストケースを 作る時には 気にしたくない テスト 設計担当 集中しないと 抜けも出るし 効率も悪い… テスト担当者はテストケース作成に集中する必要があります。 その際、複数のターゲット範囲で抜けがあるコトは考えづらいです。
  25. 25. 252016年1月 WARAI アーキテクチャのはなし 3.上下から辿る:下位テストケースから テストケース ※注:説明はスクリプトテストのみをターゲットにしております 技法 その他 分析 ターゲット 範囲 大人人数 子供人数 合計金額 人 人 円 製品画面 過去の テスト テストベース 同値分割 境界値分析 デシジョンテーブル CFD/CEG 直交表、All Pair法 状態遷移図/表 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テスト 設計担当 テストケースを 作る時には 気にしたくない テスト 設計担当 集中しないと 抜けも出るし 効率も悪い… 何らかの図や表で全体としての抜けが分かり、議論できる内容が あると便利。それが各テストとのリンクがあると使いやすいです。
  26. 26. 262016年1月 WARAI アーキテクチャのはなし 3.上下から辿る:下位テストケースから テストケース ※注:説明はスクリプトテストのみをターゲットにしております 技法 その他 分析 ターゲット 範囲 大人人数 子供人数 合計金額 人 人 円 製品画面 過去の テスト テストベース 同値分割 境界値分析 デシジョンテーブル CFD/CEG 直交表、All Pair法 状態遷移図/表 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テスト 設計担当 テストケースを 作る時には 気にしたくない テスト 設計担当 集中しないと 抜けも出るし 効率も悪い… 抽象化 の活用 問題の 分割 抽象化の活用 ドメイン単位で分析しやすい パターンなりがあるはず 他プロジェクトの 検討方法を流用 そこで使われる図や表(アーキテクチャ?)は、 抽象化や問題の分割により担当分担や流用が出来ると役立ちます。
  27. 27. 272016年1月 WARAI アーキテクチャのはなし 3.上下から辿る:下位テストケースから テストケース ※注:説明はスクリプトテストのみをターゲットにしております 技法 その他 分析 ターゲット 範囲 大人人数 子供人数 合計金額 人 人 円 製品画面 過去の テスト テストベース 同値分割 境界値分析 デシジョンテーブル CFD/CEG 直交表、All Pair法 状態遷移図/表 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テストケース 技法 その他 分析 ターゲット 範囲 テストケーステストケース テストケース テスト 設計担当 テストケースを 作る時には 気にしたくない テスト 設計担当 集中しないと 抜けも出るし 効率も悪い… テスト 実施 環境の準備 (治具ツール検討) 試験のやりやすさ 自動化有無 … 抽象化 の活用 問題の 分割 実際のテスト作業としてはテスト実施までが有ります。 この辺をテストアーキテクチャ図でリンクできると良いですね。
  28. 28. 282016年1月 WARAI アーキテクチャのはなし 4.上下から辿る:上位要求から 「役立ちどころ」を意識しながら、上位の要求から テストアーキテクチャの役割を辿ってみましょう ※注:説明はスクリプトテストのみをターゲットにしております 上位 要求
  29. 29. 292016年1月 WARAI アーキテクチャのはなし 4.上下から辿る:上位要求から 開発 プロダクト テストケーステストケース テスト・ 品質担当 (BtoB)契約定義 (BtoC)企画書 要求仕様書 もしくは何か 契約で定義される内容や企画書から要求仕様書が作られて、 開発によりプロダクトが作られ、テストケースで確認されます。
  30. 30. 302016年1月 WARAI アーキテクチャのはなし 4.上下から辿る:上位要求から テストケース 開発 プロダクト テストケーステストケース テスト・ 品質担当 (BtoB)契約定義 (BtoC)企画書 要求仕様書 もしくは何か 問題発生 暗黙の前提 前商品のクセ テストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケース 顧客 監査担当 テストやプロセスで説明 (おもにBtoB) テストで説明 (おもにBtoB) 社内での確認 社 内 他 の 確 認 改善! BtoBでの受け入れでは、テストケースで説明が行われる場合も。 また、問題発生時の説明や改善時にもテストケースが活用されます。
  31. 31. 312016年1月 WARAI アーキテクチャのはなし 4.上下から辿る:上位要求から テストケース 開発 プロダクト テストケーステストケース テスト・ 品質担当 (BtoB)契約定義 (BtoC)企画書 要求仕様書 もしくは何か 問題発生 暗黙の前提 前商品のクセ テストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケース 顧客 監査担当 よく分かんない 抜けないの? テストやプロセスで説明 (おもにBtoB) テストで説明 (おもにBtoB) 安心? 納得? テストケースで XXXのように 確認してます… 社内での確認 社 内 他 の 確 認 改善! テストケースは大量にあり、テストケース単体で説明は大変です。 安心したい顧客に理解して貰えない場合もあるでしょう。
  32. 32. 322016年1月 WARAI アーキテクチャのはなし 4.上下から辿る:上位要求から テストケース 開発 プロダクト テストケーステストケース テスト・ 品質担当 (BtoB)契約定義 (BtoC)企画書 要求仕様書 もしくは何か 問題発生 暗黙の前提 前商品のクセ テストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケース 顧客 監査担当うーん、不具合はダメだが やり方は悪くなかったと 判断しましょう テストやプロセスで説明 (おもにBtoB) 安心 テスト全体で XXXで見てます。 今回の問題は… 社内での確認 社 内 他 の 確 認 テストで説明 (おもにBtoB) 納得 改善! 説明・理解 ・理解 ・フィードバック ・アクション そこで、テスト全体を俯瞰できるような図を用いて説明、辿ることで 理解を容易にして納得して貰うことも出来るかもしれません。
  33. 33. 332016年1月 WARAI アーキテクチャのはなし 5.開発との対比を考える 少しだけ開発側のアーキテクチャ設計との 対比を行ってみましょう。 ※かなりマニアックです。 注意事項: こちらの内容は作成者の個人的趣味が多数入ってます。 言葉での説明で補足する部分も多くありますので、 スライド内容だけで理解しようとすると テストアーキテクチャへの理解を逆に損ねてしまう 可能性がありますのでご注意ください。
  34. 34. 342016年1月 WARAI アーキテクチャのはなし 5.開発との対比を考える モノを作る、デザインするという考え方。 要求 ニーズ 1.形をコンテキスト から作り出す (or 自然に発生する) 2.分析段階で分解して 統合して形を作る@デカルト的 コンテキスト フォース(傾向など) デザイン 形 分析 統合 (綜合) フォース/コンテキストが 形を作る例
  35. 35. 352016年1月 WARAI アーキテクチャのはなし 5.開発との対比を考える みんな大好きV字に当てはめると…? 要求分析 要求分析 方式設計 詳細設計 SW適格性 確認テスト 結合テスト 単体テスト コード作成 綜 合 方式設計?で なんか形が 決まる 詳細設計の 分解は それっぽい そういえば 組み立てる 作業は? 要求 ワールド 形 ワールド ※SLCP: Software Life Cycle Process (共通フレーム参考)ベース
  36. 36. 362016年1月 WARAI アーキテクチャのはなし ※SLCP: Software Life Cycle Process (共通フレーム参考)ベース 5.開発との対比を考える みんな大好きV字に当てはめると…? 要求分析 要求分析 方式設計 詳細設計 SW適格性 確認テスト 結合テスト 単体テスト コード作成 綜 合 方式設計?で なんか形が 決まる 詳細設計の 分解は それっぽい そういえば 組み立てる 作業は? ひとまず、こっちに着目してみる
  37. 37. 372016年1月 WARAI アーキテクチャのはなし 5.開発との対比を考える 実際の開発でやっていること 要求 方式設計案 要求 形 実際の開発では要求を形に置き換える作業を行っているとします。 要求から「形」として方式設計の案を作る作業をするとします。
  38. 38. 382016年1月 WARAI アーキテクチャのはなし 5.開発との対比を考える 実際の開発でやっていること 要求 方式設計案 要求 形 要求から形の変換というのは大きく飛躍が発生することが多いです。 大きな隔たりがあると考えます。 大きな 隔たり なお、形の世界はデカルト的な 分析作業が適用できると考えます。
  39. 39. 392016年1月 WARAI アーキテクチャのはなし 詳細設計 5.開発との対比を考える 実際の開発でやっていること 要求 方式設計案 小さい要求や ユーザー ストーリー 詳細設計 ⇒方式設計 の分解 詳細設計 詳細設計 詳細設計 詳細設計 詳細設計 複雑であり アーキテクチャ で解決する箇所 要求 形 小さい 要求 小さい 要求 小さい 要求 小さい 要求 大きな 隔たり 実際は要求を小さく分割、方式設計も詳細設計へ細かくします。 ここで、要求と形は隔たりが大きく、この部分がアーキテクチャで 解決が必要となる部分とも考えられます。
  40. 40. 402016年1月 WARAI アーキテクチャのはなし 詳細設計 5.開発との対比を考える 実際の開発でやっていること 要求 方式設計案 小さい要求や ユーザー ストーリー 小さ い要 求 小さ い要 求 小さ い要 求 小さ い要 求 詳細設計 ⇒方式設計 の分解 詳細設計 詳細設計 詳細設計 詳細設計 詳細設計 複雑であり アーキテクチャ で解決する箇所 トレーサビリティマトリクス@XDDP 要求 形 この要求から形(方式設計~詳細設計)の難しい隔たりに対しては XDDPではTMを用いての分析・解決を行う等を行っています。
  41. 41. 412016年1月 WARAI アーキテクチャのはなし 5.開発との対比を考える テストプロセスでは? テスト要求 小さい 要求 小さい 要求 小さい 要求 小さい 要求 小さい 要求 小さい 要求 テストケーステストケーステストケース テストケーステストケーステストケース テスト要求モデル 要求 形 アーキテ クチャ? ※あくまで個人の意見です。 大きな 隔たり? さて、同様の流れをテストプロセスで考えてみましょう。 テスト要求を分解し小さくします。この際、要求モデルも作ります。
  42. 42. 422016年1月 WARAI アーキテクチャのはなし 5.開発との対比を考える テストプロセスでは? テスト要求 テストケーステストケーステストケース テストケーステストケーステストケース テスト要求モデル 要求 形 アーキテ クチャ? ※あくまで個人の意見です。 小さい 要求 小さい 要求 小さい 要求 小さい 要求 小さい 要求 小さい 要求 意外と 小さい 隔たり? 今までの(テスコン)事例を見ると、小さい要求からテストケースを 作ることが出来そうです。要求⇔形の隔たりは意外と小さいかも?
  43. 43. 432016年1月 WARAI アーキテクチャのはなし 5.開発との対比を考える テストプロセスでは? テスト何とか ?? テストケーステストケーステストケース テストケーステストケーステストケース テスト要求モデル ≒テストアーキテクチャ要求 形 ※あくまで個人の意見です。 テスト要求 分析 テストアーキテ クチャ分析 テスト 詳細設計 小さい 要求 小さい 要求 小さい 要求 小さい 要求 小さい 要求 小さい 要求 要求と形という対比では、テスト要求モデル≒テストアーキテクチャ という考え方で「形」サイドへの割り当てが出来るかもしれません。
  44. 44. 442016年1月 WARAI アーキテクチャのはなし 5.開発との対比を考える テストプロセスでは? テスト何とか ⇒テスト要求B テストケーステストケーステストケース テストケーステストケーステストケース 要求 形 ※あくまで個人の意見です。 テスト要求A 品質的な要求 企画や狙い ・・・ テスト要求 分析 テストアーキテ クチャ分析 テスト 詳細設計 小さい 要求 小さい 要求 小さい 要求 小さい 要求 小さい 要求 小さい 要求 現状の分割では「テスト要求」の役割が大きいのかもしれません。 テスト要求の作業を下記A/Bのように別の区切りで分けて 名前付けを考えて整理が必要かもしれませんね。 テスト要求Bモデル ≒テストアーキテクチャ
  45. 45. 452016年1月 WARAI アーキテクチャのはなし つーことで なげっぱでおわります! 何処かでブログるかも 複数のモノの見方を得て、 自分に役立つ理解や納得感から 「役立つ」モノを採用する、というように して頂ければ良いと考えてますー。 (・ω<) てへぺろ
  46. 46. 462016年1月 WARAI アーキテクチャのはなし 引用 テスト設計コンテスト2012 http://jasst.jp/symposium/jasst12tokyo/report.html#plan9 テスト設計コンテスト2013 http://www.aster.or.jp/business/contest/contest2013.html テスト設計コンテスト2014 http://www.aster.or.jp/business/contest/contest2014.html テスト設計コンテスト2015 http://www.aster.or.jp/business/contest/contest2015.html 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 テスト観点に基づくテスト開発方法論VSTePの概要 http://qualab.jp/materials/VSTeP.130510.bw.pdf

×