JaSST15東京(2) テスト開発方法論「解決!テストアーキテクチャ設計」
2015/2/20(金)~21(土)に開催されたソフトウェアテストシンポジウム'15東京(JaSST'15 Tokyo)で私が参加したセッションの内容を数回に分けて書いています。
(※おことわり(再掲):チュートリアルは有料セッションですのでblogに書けません。予めご了承下さい。)
今回は、セッションB2 テスト開発方法論「解決!テストアーキテクチャ設計」です。
セッションB2 テスト開発方法論「解決!テストアーキテクチャ設計」 塾長:吉澤 智美(日本電気)、塾生:村上 仁(智美塾)/西 康晴(電気通信大学)/湯本 剛(日本HP)
(1)背景
写真を扱うアプリ
(1-1)テスト設計導入以前
パラメータをいきなりテストケースにしていた。
(1-2)テストの特徴
- 工数によってテストケースを作る or 作らないことがあった
- 機能テストのみであった
- テスト目的が分かりにくい
- 機能間の連携なテストは無かった
(1-3)マインドマップで全体像を把握してみたところ...
テストケースが、2件→400件と増加し、内容が細かくなった。
(2)テスト設計導入時
(2-1)機能テスト
画面テストと遷移テストに分離した。
(a)画面テスト:単体テスト
(b)遷移テスト:結合テスト
(2-2)グリッドビューのテスト:システムテスト。
(2-3)全体のテスト仕様
テスト実施/実施しないを明記した。
(2-4)問題点
(a)機能が網羅されているか分かりづらい。
(b)遷移図を作ってみたが、大変であった。
(c)テスト観点を軸にしたため、分かりづらい。
成果物が大量になったことが分かりづらい原因。
(d)画面毎の機能が分かりづらい。
(e)案件毎にテスト設計を分けたため、新規リリースと機能追加/改修リリースで粒度がバラバラになった。
(3)コメント
(3-1)湯本さん
(3-1-1)成果物
- 見るところが多くて大変でした。
- 重複している箇所もありました。
(3-1-2)機能の理解に着目
ゆもつよメソッドで分析した。
1.論理的機能構造
2.テストカテゴリ
- 現場で使っている用語とした。
- 似た機能をまとめた。
3.テスト分析結果(テスト条件)の特定方法
- 入力しているもの/出力しているもの
入力→貯蔵→出力を脳内シミュレーションした。 - テスト分析マトリクス
ピボットテーブルで俯瞰した。 メンバーですり合わせた。
(3-1-3)アドバイス
1.「何をするのか?」があるとよい。
2.作ったものは1つに集約できるとよい。
3.もともと決めたルールに「常に立ち返る」ことが大切。
(3-2)にしさん
「20点の出来で見える問題より、40点の出来で見える問題の方が広く見える。」
(3-2-1)成果物
親子関係が整理されていない。
(3-2-2)アドバイス
- 補足事項欄に本当にテストしたいことが書かれている。
シートの使い方が問題。 - 役割が違う表は役割毎に分けるほうがよい。
- 隠れているテスト観点を探す。 リバースする。
- テスト観点
役割毎に分ける(ふるまいや検出したいバグなど) - Excelの見出し
見出しを正規化する(by @kz_suzukiさん) - いきなりテンプレを埋めようとしない。 テストの趣旨や意味をとにかく書く。
- 何が問題かとことん考える。
- 道具を何でも担わせないこと。
- それを変えて何が嬉しいのかをいつも意識。
(3-3)会場からの質問
Q:テストレベルは意識しているか?
A(村上さん):システムテストをスコープとした。
所感
テスト設計導入以前からテスト導入以後に至る過程で発生する問題のうち、「(c)テスト観点を軸にしたため、分かりづらい。」は、私自身が担当した案件でも発生しました。伝えたい情報(観点)をシンプルに伝えないと、ステークホルダに伝わらないと痛感しています。
本セッションで印象に残ったのは、湯本さんのコメント:「もともと決めたルールに「常に立ち返る」ことが大切。 」です。過去の資料で「何故、そう考えたのか?」、書いた人の意図を理解してから、意図を損なわずに改善しないと、後々引き継ぐメンバーが困ることに対し、警鐘を鳴らしていると思いました。
これまで自分が書いてきた資料(テスト仕様)が他メンバーに伝わっているのか、立ち返ることにします。