ソフトウェアテスト技術振興協会のテスト設計チュートリアルに参加

By: Tomas

公式サイト：NPO法人 – ソフトウェアテスト技術振興協会で以下のチュートリアル資料を配布してくださっています．非常に勉強になりました．

【OPENクラスチュートリアル資料のダウンロード】
http://aster.or.jp/business/contest/doc/2017_open_V1_0.zip

開催日程：2016年8月20日（土）14時～17時（受付13時30分～）

場所：御茶ノ水駅から歩いて５分くらいの日本大学理工学部駿河台校舎7号館の3階

講師：長谷川聡さん（ベリサーブ）、吉澤智美さん（日本電気）

長谷川さん：テスト設計に焦点を合わせて話している。

概要：満足するテストができているか？そのテストは周りにきちんと伝わっているか？
テスト開発プロセスの流れ　TDLC：TRA-TAD-TDD-TI
テスト開発プロセスが必要である：このパワポの内容は１０年くらい前から変わっていない
- 少しずつ変わってきている感はするが、まだまだ課題がある
- テスト開発プロセス
テスト開発プロセスの基本的な考え方
旧来のテストプロセスは粗すぎる
- この図には全体を通して行うテスト管理や、要求分析の前にあるテスト計画が書いていない
- プロセスの中でも、テスト要求分析とテストアーキテクチャ設計は重要である。
上流工程でテスト観点を構成要素としてモデリングを行う
- モデル化しない場合は、個別具体化していかないといけない。
  - 一個一個に対して議論をしないといけない
  - テストケースのレビューしましょう＝２０００行のExcelを見てレビューしないといけない
  - 単純化してある程度の塊にする必要がある
- モデル化のいいところ、自分が理解しやすいかつ、相手も理解しやすい＝俯瞰的なに捉えられる（絵的にみやすい）
- 個別具体化の逆なので抽象化していくという認識でいいのか？→だいたいそう！
テスト要求分析（TRA）
- 1.要求の源泉の準備（元ネタwを探しに行く）
- 2.要求の獲得と分割
- 3.モデルの構築と納得
- 個別
  - 1.要求の源泉の準備
    - 要求の源泉の例
    - 一つも入手できない（開発仕様書がないとか・・・）なら、自分たちがステークホルダーになりきってブレストや仮想ヒアリングを行う
  - 2.要求の獲得と分割
    - エンジニアリング的要求とアネジメント的要求に分ける
    - テストケースを導くエンジニアリング的要求とテストケースを導かないマネジメント的要求に分ける
      - これを分けることで、何が良いのか？→リスクを見極めるために使用するのが良さそう！
  - 3.モデルの構築と納得
    - モデル構築
    - 自分たちが納得するまでリファインする
    - ステークホルダーも納得する
      - テストが重要ということを伝えるのでなく
      - テストを削る場合、そのテストの削る意味を納得した上で意思決定するため
- モデリングの２つのアプローチ
  - トップダウン
    - おもむろにテスト観点をあげて詳細化していく
    - マイヤーズの三角形
    - http://luvusa.seesaa.net/article/10232021.html
    - http://jasst.jp/symposium/jasst14tokyo/pdf/A4-1.pdf
  - ボトムアップ
    - 思いつくことからテストケースを具体的に描き、幾つか集まったところで抽象化しテスト観点を書き出していく
  - 実際には、トップダウンとボトムアップを循環させながらモデリングしていく。
- モデルのリファイン
  - 網羅化：MECE分析
  - 網羅化：親子関係分析
    - 網羅化はMECEと親子関係を使ってしっかりと納得できるモデルにしましょう
  - 整理
    - 読む人によって意味のとこなるテスト鑑定を特定し、名前を変更する
    - 本当にその関係・観点は必要か？もっと伝わりやすい・扱いやすいモデルはないのか？
  - 剪定
    - 見通しを良くするために、モデルから排除するものはないか？
      - インプットから剪定する
        インプットとは、組織の決まりごとや観点や関連性、網羅基準や組み合わせ基準の緩和など
        例：これまで十分に開発者が動かしてきて実績があることに関してモデルに入れる価値は、テスト項目数・リスク・コスト的にどうか？
  - 確定
    - レビューして確認する
テストアーキテクチャ設計（TAD）
- テストスイートの全体像を把握しやすくしつつ後工程や派生製品、後継プロジェクトが作業しやすくなるように観点をグルーピングしてテスト要求モデルを整理する工程
- で、何がしたいか？？→ざっくり言うと、全体像を把握しましょう！テスト実装できるように詳細化しましょう！の２点
- テストコンテナモデリング
  - グループの例:テストレベルやテストタイプ、テストサイクル
    - テストレベル（単体・結合・システム・受け入れなど・・組織によって違うが、これらがテストレベル）
    - テストタイプ（性能要件だと性能というテストタイプ、ユーザビリティテストもユーザビリティというテストタイプ）
      - ある目的を達成するために行うテスト
      - ユーザビリティテストは単体でも結合でもシステムでもやる可能性はある。つまり軸が違う
      - あるテストタイプのコンテナを
    - テストサイクル
      - リリースに対する一通りのテストの塊
    - テストフェーズ
      - 管理しやすいテストの塊にまとめたもの
  - いろんな観点からグルーピングした適当なもの→テストコンテナ
  - テストコンテナは入れ子（包含）でもおk：塊があることでわかりやすくなることが重要
  - まとめ
    - テスト観点よりも粒度の粗いテストコンテナを用いるので、俯瞰して把握しやすい
    - テストコンテナ間に含まれるテスト観点を比べると、役割分担を明確に把握できる
      - 現場で経験的に用いているテストコンテナの妥当性を評価したり改善できるようになる
        負荷テストと性能テストなど、違いがよく分からないテストタイプも区別できる
        単体テストと結合テストなど、役割分担がよく分からないテストレベルも区別できる
    - サブレベルなどを階層的に表現できる
    - テストスイートの品質特性(保守性や自動化容易性など)を意識してテスト設計に反映できる
      - 一回テストを作ったテストケースに関して、いじらないといけない場合
        個々ののテストケースを確認することは大変だが、保守性を意識しているとコンテナ毎に確認出来る
  - テストアーキテクチャ設計では、ソフトウェア設計のような設計技術やモデリング技術
    - テストコンテナ間の関係がなるべく少なくなるように分割する =結合度を下げる
    - テストコンテナの表している意味が明確になるように分割する =凝集度を高める
    - テストスイート(テストケース群)の品質特性を高めるように設計する
      - 高い保守性が必要、自動化しやすい、など
    - テストデザインパターンを抽出、蓄積、活用するとよい
  - テストスイートの品質特性
    - テストアーキテクチャ設計の中で
  - テストコンテナを使用するとリファインしやすい
- テストフレームモデリング
  - 実際のテスト設計では、複数のテスト観点をまとめてテストケースを設計したい場合がある
    - –この条件のテストは、テスト対象のどの部分に行うんだろう?
    - –この部分に対するテストでは、どの品質特性を確認するんだろう?
    - –この品質特性をテストするには、どの操作を行えばいいんだろう?
- テストアーキテクチャ設計が終わると、最小のコンテナではテストが実装できる状態になっているはずである。
  - ここまでが頑張りどころですよ！これ以降は作業が多い。
テスト詳細設計（TDD）
- テスト詳細設計は自動化しても良い？
- テスト実行環境
テスト実装（TI）
- テストプロセスでは非常に重要
- 手順を作っていく
- キーワード駆動・データ駆動

http://sssslide.com/www.slideshare.net/YasuharuNishi

ASTER テストツールガイド改訂WG（Test Tool Guide Working Group）

NPO ASTER

http://aster.or.jp/business/testtool_wg/pdf/Testtool_beginningGuide_Version1.0.0.pdf

404 Not Found

テスト要求分析（TRA）

コメント