【Ultimate Agilist Tokyo 参加レポート】第4セッションD：テストを支える。テストを育てる。 #uatagile #uatagileD

• Ultimate Agilist Tokyo - 集え、日本の活動家たちよ。 - Ultimate Agilist Tokyo
• 2012/11/17 Ultimate Agilist Tokyo - テストを支える。テストを育てる。 #uatagile #uatagileD - Togetter
• 『Ultimate Agilist Tokyo - 集え、日本の活動家たちよ。-』に参加してきた #uatagile - Shinya’s Daily Report

登壇者

• 井芹 洋輝 氏 (TwitterID:@goyoki)

講演スライド

• テストを育てる。テストを支える（Ultimate Agilist Tokyo）
  • テストを育てる。テストを支える（Ultimate Agilist Tokyo） from H Iseri

セッション内容

• 自己紹介：
  • 仕事は組み込み
  • 仕事ででアジャイルはやってないです…
  • アジャイルなプラクティスは好きです

• 組み込みTDDの記事を執筆させて頂きました。
  • 組み込みがマイナーなため講演テーマとして断念(でも会場には10人ほど居た！)
• 書いたこと：
  • TDDは組み込み開発を大きく効率化させます！
  • 組み込みプログラマはTDDをしよう！

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

• ソフトウェアテストの課題
  • V字モデル開発
    • インプット資料をきちんと作ること
    • インプットに対しきちんとテスト分析・設計を行うこと
  • 変更や曖昧さに対応する
    • 反復開発、中間リリース
      • この状況では最初にテストと作りこむ事が難しい。

• 色々な目的で色々なテストが実施される
  • CIでのデグレード監視
  • 中間リリースのための品質保証
  • TDDでのプログラミング
  • 網羅的なバグ出し
  • 品質保証のためのテスト

• 取り組まなければ成らない問題
  • 変更による生産性低下
    • 変更のたびに…
      • テスト設計のやり直し
      • インタフェースの変更への対応
    • 既存テストの再評価
    • 回帰テストの追加
      • テストの変更性が劣悪だと、Cut & Runや非効率化を促す

• • テストの要求の見逃し
    • テストの要求を見逃したり阻害したりする
    • バグを見逃さない網羅的なテストを作るように色々対応(

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

• ソフトウェアテストを効果的に運用するにはどうすれば良いか？
  • テストを育てる。テストを支える。
    • 育てる視点
      • 全体方針を立てた上で、変化に対応しつつ全体最適が得られるようにテストを作る
    • 支える視点
      • 課題やリスクに対応

• テストを育てる
  • 一連の流れで
  • 育てる基本フロー
    • 1.テストへの要求を分析
    • 2.全体方針や構造を明らかに
    • 3.段取りを明らかに
    • 4テストを育てる
    • ※要求が変わるたびに実行。

• • 開発ライフサイクル上でどのようなテストが要きゅうされているのか明らかにする
    • [テストの対象]：対象の構造、開発フローやスケジュール。mindmapやフローチャート、図等を用いて
      • テスト対象の分析
        • システムテスト設計のための機能分析...機能のレイヤ設計/状態やインタフェースとの関連付けで整理
        • ※これらを階層一覧で整理
    • [テストの計画]：テストのフローやスケジュール。テストのどの段階で実行するか
    • [テストの運用]：環境、実行や管理上の要求。『1秒居ないでの軽快な実行を行う』など
    • [テストの目的]：着目する品質特性、品質基準。どのような品質目標を見るのかなど

• テスト目的の分析
  • 

• 参考文献

ソフトウェア・テスト PRESS 総集編

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

• 全体の方針や構造を明らかにする
  • 要求に基づいて、テスト活動を誘導する全体の方針や構造を明らかにする
  • テスト対象とテスト目的の関連付け
    • 
  • テストの運用や計画の方針を決める(写真)
    • 
  • 各フェーズでのテストの対象、目的、運用を明らかにする
    • 

• 段取りを明らかにする
  • どう育てていくかを考える
  • 全体としての整合性や生産性を求める

• 段取りの例 VOTDD 検証指向TDD
  • 
  • 1.パッケージや上位コンポーネントレベルでテストの方針や構造を明らかにする
  • 2.ユニットレベルで、テストリストをテスト設計技法にて整理する
  • 3.テスト設計、テスト実装を作りこみながらTDDを進める
  • 4.テストを綺麗にする
    • 安定したテストコードから巡回的にレビューし、テスト設計の補強や再構築を行う
    • 最終的に適切なテスト設計に基づいた網羅的なユニットテストを得る

• テストプロセスの活用
  • ゆもつよメソッド
    • 「勝手にゆもつよメソッド勉強会」実施要領 - たまゆら雑記
    • 「ゆもつよメソッド」をPFDで考えてみた。 | どしろうと製作所：WebLog
    • スケーラビリティに優れた方法論。
    • テスト対象から離れてテスト設計を行う事が出来る。
    • 変更が発生してもどのようなテストが必要か健闘しやすい。

• テストを育てる
  • 

• テストを支える
  • 育てる方針は分かっていても上手くいかない
    • ソフトウェアテストは問題の当事者になりがち
      • 問題の残留や遅延の影響
      • 品質やデリバリーに直結。
    • テストプロジェクトのリスクや問題を識別し、対策を打つ
    • テストの活動をより効率的にする

• • 1.テストプロセス
    • トップダウンで必要な支援作を抽出。
  • 2.プロジェクトリスクのリスクマネジメント
    • 問題やリスクを抽出し、ダメージの予防軽減などを行う

• • テストをささえる道具
    • 誘導する：ウォーキングスケルトンによるダブル・ループ
    • 選択肢を広げる：デュアルターゲット・テスト
    • 選択肢を広げる：マルチコンフィグレーション・テスト
    • 堅牢な構造を得る：データ駆動テスト
    • 自動化する：テスト設計の自動化
    • モデルベーステスト
      • 設計モデルからテストを自動生成

• こちらの書籍『ソフトウェア技法ドリル』も参考になる。

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際