テスト担当者も上流工程の技術を学ぶべき3つの理由

ソフトウェアテスト Advent Calendar 2018の14日目です。

今日はJaSST'18 ShikokuとJaSST Review'18が同時開催という、前代未聞の豪華な一日でしたね。

はじめに

2018年は主に自動テストの要件定義ゃーをやらせていただいているのですが、スポットで入らせていただいた業務システムのテストリーダーのお仕事は近年稀にみる学びがありま、テスト技術者もプロセス設計や要件定義といった上流工程の技術を学ぶべきとしみじみ感じた1年でした。
今日はそんなしみじみ感じた内容をだらだらと書いてみようと思います。¹「上流工程は上流工程の人に任せておけばいいんじゃ？」って人も「上流工程のことわからないで何をテストしてるの？」って人も²、駄文に少々お付き合いいただければと思います。

テスト担当者も上流工程の技術を学ぶべき3つの理由

2018年の出来事から、上流工程技術が必要だと痛感したことを3つ挙げます。

1. 計画を立てるため
2. 現場で使えるシステムを納品して受入れテストですんなりOKをもらうため
3. 業務を改善するため

1. 計画を立てるため

計画というのは、テスト計画だったり目標達成への計画だったり、テスト担当者にとっても身近な存在です。

計画を立てるためには、成果物を定義する必要があります。成果物の内容によってタスクが決まります。裏を返せば、成果物が決まらないとタスクが明確になりません。タスクが決まったら、依存関係とリソースを調整してスケジュールを作成します。

成果物に何を含むのか、要件を定義しないと、タスクがあやふやになります。後からタスクが漏れていることが分かるとスケジュールが押しますし、タスクが曖昧だと見積もりと合わなくなってやっぱりスケジュールが押します。
計画通りに物事が進まない方は、要件定義を学びましょう。いい計画はいい要件定義から。テスト担当者も要件定義を学びましょう。

2. 現場で使えるシステムを納品して受入れテストですんなりOKをもらうため

テストに寄せたくて受入テストってキーワードを使いましたが、テスト担当者はシステム開発チームの一員ですので、いいシステム（現場に定着するシステム）を提供するためには全力投球したいところです。

業務系システムの受入テストでは、システムが実業務にマッチするかどうかを見ていきます。すなわち、「現場で使い物になる」システムかどうかを見極めるテストをしていきます。最後の最後でひっくり返されないよう、テスト担当者として業務シナリオをレビューしたり、シナリオテストを実施しなければなりません。

シナリオテストのインプットはユーザーシナリオで、本来であれば要件定義の成果物に含まれているべきものですが、機能先行で開発が進んだ場合、ユーザーシナリオが存在しないことがあります。プロジェクトの一員としてテストに参画している場合、「ユーザーシナリオがないのでテストしません」と突っぱねるのはテスト担当者として仕事を放棄しているようなものです。
ユーザーシナリオがあったとしても、それが十分かどうか検証する必要がありますし、結局、ユーザーシナリオが作れるだけのスキルはあるに越したことはありません。

登場人物は誰なのか、業務の目的はなんなのか。システムが業務で使い物になるかどうかはそこからです。ヒアリング力と妄想力を駆使して、お客さまの業務を理解し、お客さまがすんなりシステムを導入できるよう検証しましょう。
それから、ユーザーシナリオが定義されていないような開発現場がこの世からなくなるよう、促しましょう。要件定義、マジだいじ。

3. 業務を改善するため

業務というのは、材料（入力）と活動と成果物（出力）の連鎖でできています。これを、プロセスと呼びます。プロセスは目に見えないので、書き出してみることで無駄が見えたり暗黙知が共有できたりします。もちろん、テストにもプロセスがあります。

プロセスについては私は、ボクらのプロセスにきづこう #wacateで学びました。形式としては、PFD（プロセスフローダイアグラム）³を使うと簡潔にまとめることができます。PFDは私がの周りのテスト技術者の中で広く広まっている手法です。
​もっと細かいプロセスを書くなら、マジカが使えます。IT屋さんではない人に業務フローを定義してもらうときに活躍しているツールです。以前、自分が暗黙でやってたいろんなタスクを引き継ぐときにマジカを使ってみたら、スムーズに定義ができて感動ものでした。
「可愛いは正義」が口癖の羽生さん⁴が作っているだけあって、可愛いくてとっつきやすい反面、現場に持ち込みにくいのが若干の難点。とりあえず社内で付箋とゴミ袋のスタイル⁵に抵抗がなくなってきているので、次はマジカの普及を狙っていたりします。

業務を楽にするためにも、業務プロセスが見えないと始まりません。
テスト担当者も業務プロセスを書けるようになりましょう。

まとめ

テスト担当者も、武器は多いほうがいい。

テストと要件定義の関係についてはもうちょっと掘り下げたいところですが⁶、忘年会の時間が迫っているので今日はここまで。

今週末はWACATEやPHP Conferenceがあるみたいですね。参加される方は、いろんな方々とたくさん交流をされるとよいかと思います。それでは、忘年会に行ってきます！​⁷

1. アドベントカレンダーってこんなんでいいんでしたっけ？ｗ ↩

2. もちろん「上流工程のことわからないで何をテストしてるの？」派です ↩

3. PFDの適切なリンク先がわからなかったです…清水さんが書いたやつってないんでしたっけ？ ↩

4. 『はじめよう! 要件定義 ~ビギナーからベテランまで 』とか『改訂第3版 すらすらと手が動くようになる SQL書き方ドリル (WEB+DB PRESS plus)』とか、「できるを増やす」をテーマに活動されていて、大好きなのです ↩

5. ゴミ袋って、ホワイトボードマーカーで書いたり消したりできるんですよ。付箋を貼ってはがして線を書いて、更に持ち運べる。安い。素晴らしい！出所は、みずのりさんのTOCのワークショップだったか…？ ↩

6. 表記揺れとか考察とか不足しまくってますが今週は時間が…なぜ私はこの日にカレンダーを設定してしまったのか ↩

7. 乾杯の時間になってしまった！！！！！orz ↩