3.2    技術セッション「単なる仕様チェックから卒業するために ~最初に抑えたいキホンのキ~」

3.2.1    はじめに

このセッションでは、池田 暁氏にご登壇いただきました。

「キ」を様々な漢字に当てはめ、これからテストを担当していくテスト初心者向けに、テストの基本についてご講演いただきました。

3.2.2    レポート報告

3.2.2.1   規/テストに必要となる思考

まず始めに、「規」の字が示すとおり、テストを設計していく上での規範をお話しいただきました。ソフトウェアの開発・設計において、そこには必ず「思考」が発生します。我々が普段行っているのは「設計のための思考」ですが、それとは別に、「テストのための思考」というものが存在します。この二つの思考を意図的に切り替えられるようにすることが重要です。

「設計のための思考」とは、問題領域を大きな問題から小さな問題へ、徐々に狭めていくことを意味します。「こう動くべき」から「こう動かないべき」を考えて、具体化していきます。それに対して「テストのための思考」とは、それに加え、「その他には何も起きないこと」を考えるのが重要だと言うことでした。仕様外のことにこそ目を向け、思考を発散・展開していくことがテスト思考の第一歩です。

思考を狭めて具体化していくことが「設計のための思考」だとしたら、思考を発散させていくことが「テストのための思考」です。仕様どおりに動作することを確認するだけでは、文字通り「単なる仕様チェック」です。その先に進むためにも、思考を切り替えていくために、まずはこの認識を持つことが重要です。

3.2.2.2   紀/テストの分析設計~マインドマップを利用して~

では、どのようにしてテストのための思考を効率的かつ視覚的に発散させていけばいいのでしょうか。筋道を立てて検討するという意味が込められた「紀」、それを実現するためのツールとして、氏は「マインドマップ」を推奨されていました。

マインドマップというツールをテスト設計に利用することで、「発想力が刺激され、全体を俯瞰できる」、「自身の思考の流れを可視化できる」などの利点があるということです。特に「テスト分析」「テスト設計」フェーズで取り入れると効果的だということでした。ここで注意すべきは、「見た目に執着せず身のあるマインドマップを描く」こと、「先に仕様を把握して疑問点を洗っておく」こと、「少しでも多くの観点を列挙する」ことなどです。その中でも仕様を把握するためのテスト分析を行う際に効果的な手法として、「設計仕様書に三色ボールペンで線を引く」ことを推奨されていました。

  • 赤:客観的に、特に重要であると感じた部分/こう動くべき
  • 青:客観的に気になる部分/こう動かないべき
  • 緑:主観的に気になる部分/それ以外

ルールに基づいて仕様書に線引きをしていくことでテストベースの品質を向上させられる他、仕様の抜け漏れに気づけるようになります。とは言え、テスト分析と設計は切っても切れない関係であるため、厳密に区切らずに作業を行ったほうが手戻りは少なくなるとのことでした。

3.2.2.3   伎/テストを学ぶための5つの軸

「伎」とは細かい技のことです。テストを学んでいくための指標として、次の5つを挙げられていました。

  1. プロセス
  2. V字モデルを例に説明。「コンポーネントテスト」「統合テスト」「システムテスト」それぞれの項目のうち、「分析→設計」まではプログラムの実装を待たずに着手できるため、前倒しにした方が良いとのこと。
  3. マネジメント
  4. 進捗管理だけがマネジメントではなく、「コンポーネント」「統合テスト」「システムテスト」計画(まとめてマスターテスト計画と呼称)に基づいてマネジメント・コントロールすることが重要。
  5. 設計技法(テスト観点ベース)例:NGT・FV表・ゆもつよメソッド・Tiramis・TAME…
  6. テスト観点ベースの分析設計技法はマインドマップ以外に数多くある。
  7. 設計技法(テスト技法)例:経験に基づいた技法・仕様に基づいた技法・コードに基づいた技法・フォールトに基づいた技法・利用に基づいた技法…
  8. 「テスト技法はホワイトボックス・ブラックボックス」だけでなく、様々な技法がある。
  9. ツール例:テスト分析ツール・テスト設計ツール・テスト実装ツール・コード解析ツール・テスト実行ツール・テストウェア管理ツール・テスト結果管理ツール・インシデント管理ツール…
  10. 「テスト実行ツール」だけでなく、テストを実行するために様々なツールがある。

(報告:テシマ ナオト)