テストエンジニアが機械学習してみた備忘録

広島とジト目が好きなテストエンジニアが機械学習に手を出した備忘録。

平成の大発明を捨てたテスト管理について考えてみる

ソフトウェアテスト #2 Advent Calendar 2018 - Qiitaが結構空いてるなー、なんか書こうかなー、と思いつつぐだぐだしてたら枠埋まってしまった…orz

まぁそれはそれとして、アドベントカレンダーの中の以下の記事が気になったので取り上げてみたいと思います。

shiozi.hatenablog.com

※ 今回は機械学習とかデータ分析とか全然関係ないお話です

テスト管理(テストケースの管理)にはみんな悩んでいる

id:shioziさんの記事は主に「スプレッドシートのファイルで管理するケース*1」での困りごとですが、書かれていることは「そうそう、そうだよねー」なことが多いです。また、記事内で言及されているテスト管理を語る夕べ - connpass *2という取り組みがあることからも、自分が抱えている問題意識はいろんな人も共通して抱えているのだなぁと思いました。

平成の大発明を捨てる

どうしたらもっとスマートに管理できるのだろうと考え始めたちょうど1年前、前回取り上げたid:kokotatataさんのブログにあった以下の記事を読み、自分がもやもやしてたことが全部書いてあるなーと感銘を受けた覚えがあります。

kokotatata.hatenablog.com

もう冒頭からぐっときますよね。

「2次元の表によるテスト設計とテストケースの管理」はまさにこれにあたる。これだけ多くのテスター、テストアナリスト、テストマネージャーに親しまれ、長く使われて来たのはおそらく「革新的な発明」であり「とても便利なツール」だったからだ。しかし、次世代のテストを考える場合、この大発明を棄てる事も選択肢として考えなければならない。

スプレッドシートのファイルで管理するテスト管理は偉大だ。平成の大発明だ。OK、それは認めよう。でももう平成、終わるんだぜ?」って気持ちになりますよね?僕はなりました。

テストケース仕様とテスト手順仕様の分離

というわけで、「スプレッドシートのファイルで管理するテスト管理」は「なんかイケてない」と感じています。それはなぜなのかを考えたどり着いた仮説は、この伝統的な手法はテストケース仕様とテスト手順仕様の分離ができていないからではないか?ということでした。

テストケース仕様とテスト手順仕様という概念についてはISO/IEC/IEEE 29119を参照して知ったもののきちんと理解できているか怪しいのですが、私は以下のように解釈しています。

  • テストケース仕様
    • 各テストケースのテスト内容、テスト条件、期待値を簡潔に記載したドキュメント
  • テスト手順仕様
    • 各テストケースの実行や期待値の確認に必要な手順を詳細に記載したドキュメント

この2つが分離できていないことによって生じる問題は2つあると考えています。

問題点1: 粒度の異なる情報を2次元の表に押し込めている

一般的にテスト管理者やテストリーダーと呼ばれる役割の人が把握したい主な情報は「どのようなテストがどれだけあるのか?」や「テストスイート毎の進捗状況はどのようになっているか?」といった全体を俯瞰した情報です。一方で、テスト管理者やテストリーダーの指示のもと、テスト実施を担うテスト実施者にとっては、全体を俯瞰した情報よりも、各ケースを実行するのに必要な詳細情報の方が必要な場面が多いです。このように粒度の異なる情報を1つのスプレッドシートに押し込め、異なる視点を持つ人たちが同じ情報を参照することになるので、どちらにとっても中途半端なデータになってしまっているように思います。

問題点2: 表計算ソフトで文書管理をしている

上述の両名の記事にも書かれている通り、伝統的な手法では「テスト手順」がスプレッドシート内に記載されることが多いです。しかし、表計算目的であるスプレッドシートに、テスト条件などの「データ」を入れるならまだしも、テスト手順のような「文章」を書くのは本質的に何かが誤っているのではと思います。変更点の差分管理ができないという問題や、コピペが横行してメンテナンス性・再利用性が低いといった問題はここに起因していると考えています。

スプレッドシートwiki等の併用

というわけで、元々は「スプレッドシートのファイルで管理するテスト管理」は「なんかイケてない」という思いから始まった考察ですが、よくよく考えてみるとスプレッドシート自体は悪くなく、スプレッドシートに全て押し込めて管理している状況が悪いのではないかという仮説に至りました。ですので、テストケース仕様の管理についてはスプレッドシートでも許容できると思います。ただ、ファイルではなくWebアプリとして動作するツールを使う方が、データの分析、差分管理、関係者との共有といった面でメリットが大きいので、スプレッドシート使うにしてもそちらの方向に持っていきたいなとは思います。*3

一方で、テスト手順仕様はwikiを使うなりして「ドキュメントを書く&管理する」ことを目的としたツールを使うべきと思います。そしてテストケース仕様とテスト手順仕様の間でトレーサビリティを何らかの手段で確保できれば、上記で挙げた問題点は解決できると考えています。*4

詳細なテスト手順の省略

で、ここまで書いてさらに踏み込んで考えたことは「詳細なテスト手順、いらなくね?」です。id:shioziさんも別記事で以下のような記述をされていて、これらは結構共感できます。

shiozi.hatenablog.com

私は、人が実行する場合はテスト手順や値に自由度を持たせるほうがよいと思っています。そのほうがテスト実行者の思考がかたまらないのと、テストウェアとしての再利用度が上がると思っているからです。そのかわり、確実に「そのテストは何を確認したいのか?」というテスト設計者の意図を記入しています。あとは、テスト実行者もいろいろ考えて試せると信頼するほうがよいと思います。

そして、考える必要が無いほどのテストスクリプトであれば、できるだけ自動化を目指したほうがよいし、そのようなテストは繰り返し行う可能性のあるテストに絞り込んでいくほうがよいと思っています。

なので最近はとりあえず極端に振り切ってみて「テスト手順書かない運動」をしています。もちろん試行錯誤中なので全てが順風満帆ではないのですが、諸々の工夫もした結果、なんやかんやでなんとかなってるので、筋は悪くないのかなと思っています。長くなってきて疲れたので、この辺りはまた機会を改めて書き留めてみようかなと思います。

*1:E○cel

*2:行きたかったけど、さすがにこれの為だけに関東行きはなぁ…

*3:脱Ex○el

*4:なので誰かそんなツール作ってください