｢テスト設計コンテスト2015｣ 参加レポート

こんにちわ。GaiaX 技術開発部 QAチームの境野(@sakaimo)です。

さて、エンジニアっぽいことなら載せてもいいよね、ということで弊社の技術者ブログに仲間入りさせてもらいました。
おそらくこの画面を見ている9割位の人は開発者だと思いますが、弊社には開発チームとは別にQAをするチームが存在します。このチームは開発者が精魂込めてつくったシステムに対してダメ出しをするチーム、、、ではなく、開発者と一緒になっていいモノを世の中に送り出すのがお仕事です！ホントですよ。
ところでQAって何の略でしょうか。そうだね。Quality Assurance だね。(現在6人です)

「QA勉強会」と称してチームメンバーが集まって勉強会を行っています。例えばディシジョンテーブルの作り方だったり、セミナー参加報告だったり、バグ自慢大会だったり、お悩み相談だったり)を開催しています。
あ。もし一緒に勉強会(というか交流会(というか飲み会))をしたいというQA/テストチームがいらっしゃいましたら遠慮無くお声がけください！

今回は2/13に行った勉強会の内容を紹介したいと思います。内容は私がテスト設計コンテストに参加したときの話を他メンバーに共有する、という内容でした。

コンテスト自体は予選落ちでした。はい。

参加目的

「テスト設計」ってテストの上流工程で重要なことみたいだけど、一体何をしたらいいんだろう。ネットで調べてもわかんないから、参加してみてどんなことなのか学んでみよう。

参加に至るまでの経緯

JaSST’14の打ち上げで知り合ったCさん(女性)に誘われたから。←これ重要

コンテスト概要

• テストベース(= 飲み物の自動販売機の仕様書2つ。こちらからDLできます )
• 「このテストベースに対するテスト設計を行い、その優劣を競います」とのこと。
• うん、なにしたらいいんだろう、って思ったね。

日程と投下時間

1. 誘われた日 　2014/07/02
2. チュートリアル　2014/08/02
3. 資料提出　2014/11/26
4. 予選　2014/12/20
5. 本選　2015/02/21

1から4までに19回のmtg(1回2～4時間) + 自分の作業時間(5人日くらい?)。 これだけ見ると結構時間使ってますよね。

チームメンバー

• 私を含む4人。1人は経験者。3人は初出場。
• 今回は4人とも別の会社のメンバーでパーティーを組みました。

テスト設計のゴールとは？

• チュートリアルや、参加者の話を聞いて私が思った「テスト設計とは？」
  • テストしやすいようにテスト全体を俯瞰して作戦を考えること
  • 「なんでそのテストで十分なの？」と言われた時に納得させられる報告(説明)ができること
  • それにより自分たちが自信を持てること
• これらが満たされるとコンテストに勝てるかというとそれはわかんないｗ
• だけど実務の中で必要なのはこういうことなんだと思う。

やったこと

• ステークホルダー分析/リスク分析
  • ステークホルダーを考えて、その人にとっての「あたり前品質」「魅力的品質」「あったら困ること」を書き出す
  • そうすることで、例えばあたり前のことが確認できるテストが存在するよね、みたいに使う
• FV表作成
  • 仕様書から「目的機能」を洗い出す
  • その機能って何のためについてるんだっけ？を考える作業
• 機能モデルの作成
  • ここがこのチームの一番のウリ
  • ソフトウェア自体の設計をモデル化して、それを元にテストを組み立てる、という試み
  • って書いても伝わらないですよね。。。
• ラルフチャート風マインドマップ
  • モデル化した各機能に対してラルフチャートっぽいものを書く
  • インプット、内部処理、ノイズ、アウトプット
• テストケース作成
  • 単体、結合、システム、受け入れ、の4つのテストレベルのテストケースを書く

感想・反省点

• PFD(Process Flow Diagram)はどんな業務でも取り入れられる
  • 作業の全体像をつかむのにとても有効でした
  • 1人でやるときも、複数人でやるときも、インプットとアウトプットを明確にしておくのは有意義
  • PFDでは去年の夏に参加したWACATEでも活躍してました
• 最終成果物に対するイメージ(フォーマット、粒度、他成果物との関連)が曖昧だった
  • たぶんこの辺りは、毎日一緒に仕事をしているメンバーと組んだら認識合わせは容易だと思います
• 「こうやったら良い設計ができるのでは？」というプロセス(やりたいこと)を盛り込んでみたが、弊社の実務の中では「やり過ぎ」感ある
  • やり過ぎというか、そんなに時間とコストが確保できないので「できない」が正しいですね
• だとしたら「この仕様書と出来上がった自販機を10台渡されて、2週間でテストするように請け負った第三者検証機関のチーム」という前提でテスト設計するとどうなるか、というのは1つのチャレンジになりそう
• まさに先週、「新しいサービス出すんで1人で3日でテストして」というお仕事がありました。そこではテスト設計コンテストの経験が活きた。。。はず

まとめ

• テスト設計に触れられたし、他チームの発表や考え方も知ることができたので、当初の「参加目的」は達成できました。
• が、一方で「何が正解というのは無い世界であり、それは自分たちで見つけていく」ということなんだなーと思いました。
• テストって「狙ってる品質が達成できているかを確認する手段」だと思います。
• でも「狙ってる品質」を言葉にするのもムズカシイ(可能だとは思う)のと、品質は目に見えないというあたりが困るところ。
• だから「こういう作戦でテストすると、こういうことが言えるから、これで十分だよね」っていうのを自他共に納得できるようにしまよう、ってことなんだろうな。
• 一番の課題はそれを実務で活かさなければならないこと。例えば「3日間でテストしてね」って言われた時のテストに適したテスト設計、というものがある、、、ハズよね。

P.S. 一緒に参加した方、私の認識が違ってたらゴメンナサイ＞＜