検証資料の変遷について
最初に
某SIerに勤務している自分が今まで作ってきた検証資料の変遷についてまとめてみました。あくまでも私の話なので、皆が皆同じではないです。
あと、検証資料のことをエビデンスという人は嫌いです。なんだよエビデンスって。海老でんす？
入社初期
- COBOLで書いたバッチプログラムのテストケースはexcelで作られた雛形に記入した。
- テスト結果は入力ファイル、出力ファイルをダンプ形式で紙に出力し、テスト番号やテスト結果の補足を手書きで記入&マーカーで印をつけて提出する。
- テストケースとテスト結果はレビュアーのチェックを通過後、お客様チェックまで進む。お客様のチェック結果も戻って来て、OKなら本番リリースが出来る。
- 社内ではある程度細かく見てもらえていた。
- 先輩社員はAS400の画面も新規開発、あるいは修正していて、画面のテスト結果はスクリーンキャプチャを紙に出力していた。
入社3年目頃
- AS400画面をWeb画面に作り変えるプロジェクトに携わる。
- この時も、提出物は紙だったので諸々印刷する必要があった。この辺りでexcelの図形を使えば強調したいところを強調出来るという発見があり、じわじわとプロジェクトメンバーに手法が広がっていく。
- データの集計結果確認にもexcelの機能が使えたので、ファイルを複数使うより、シートを複数使ってテスト結果をまとめていくやり方が当たり前のようになっていく。
- 最初は画面の機能もシンプルだったが、段々複雑なものが求められるようになり、スクリーンキャプチャを取るのが苦痛になってくるのもこの頃。
- 印刷する必要があったため、印刷時のレイアウトも考慮する必要があったのが辛かった。
入社10年目頃
- 承認フローのシステム画面が導入されたことに伴い、紙での提出が廃止される。すなわち、印刷時のレイアウトを気にしなくてよくなった。
- テスト結果に求められる内容は変わらないため、スクリーンキャプチャをペタペタ貼り付ける作業が必要なのは変わらない。
- ただ、この頃からJUnitも使い始めたのでJUnitの実行結果を貼り付けて終わりに出来る場合もあった。
- テスト結果の確認は、社内メンバーはレビューフローを明確にしたこともあり、ローテーションでチェック体制が出来ていた。チェックする側は大変だったけど…
現在
- プロジェクトが変わり、現在のプロジェクトではテスト結果を客先に提出はしていない。(お客様の受入環境があり、そちらで確認していただいている)
- そのため、テスト結果はかなり簡略化されて作成が楽になった。
- また、自分で開発、修正してテスト、と全部自分でやるためテスト結果をチェックする人もほぼいないに等しい。
- ではなぜ作っているのか？と聞かれると、テスト漏れがないかの自己チェックや、あえて資料化することで見落としを減らす、あとは後々担当が変わった時の引き継ぎ資料となればいいな、というのも含まれている。
考察
- 前提として、資料を作る過程で発見できる不具合は間違いなく存在するのでテスト結果は資料に残した方がいいという考え方。
- ただ、不具合ゼロを求め過ぎて、スクリーンキャプチャを大量に取らないといけなくなるのは無駄な仕事を増やすだけ。
- Excelだと、画面の遷移も静止画になってしまってわかりにくい部分があるので、gifや動画をうまく組み合わせたものが作れるとベストだと思っている。
- 今はmarkdownで書いて、html化することも出来るのでこの辺りを組み合わせられないかとも思っているが、excelのレイアウト調整のやり易さがそれを邪魔する…。
Wordを使えやという意見も散見されるが、Wordはレイアウトの調整がやりにくいのでストレスになるからダメ
私見
- 資料を見てもらえる人がいないなら、思い切って作るのをやめてしまうのも１つの手だとは思うが、テスト漏れがあった時のリスクも考慮しないといけない。
- 現場で求められている内容に応じて臨機応変にやりつつ、スクリーンキャプチャの嵐を軽減する方法をこれからも模索していきたい。
