ソフトウェアテスト #2 Advent Calendar 2018 への参加投稿です。
ソフトウェアテスト #2 Advent Calendar 2018 - Qiita
昨日はJaSST東海に関する記事でしたね。私も参加しましたが、基調講演も特別講演もアジャイル井戸端会議もどれも予想以上に楽しんできました♪
さて本題。
11月2日にテスト管理を語る夕べというものが開催されました。
みなさんはテストケース、あるいはテストの実行結果を管理するときに困っていることはありますか?この記事では、私が経験してきた現場のありがちなテストケースやテスト実行の項目と、その項目に対して困っていることを列挙してみます。自動実行だとテストスクリプトの管理やテスト実行の管理が異なるので、とりあえずここではマニュアルテストに絞り込みます。また、主にスプレッドシートタイプのファイルで管理するケースで考えてみます。
[手順が含まれたテストケースに関する項目]
・テストケースID
・いわゆるテスト観点と呼ばれるようなキーワードや条件の記載
(「大中小項目」形式がやはり多いかなぁ・・・)
・仕様書の記載箇所
・テストケース名
・事前条件 (「前提条件」と記載されることがよくある)
・テスト手順
・期待結果
・テストケースに対する備考
・テスト実行年月日
・テスト実行時のテスト対象バージョン
・テスト実行者
・テスト実行結果
・インシデントチケットID
・テスト実行に対する備考
上記の項目があるという前提で、このテストケースを運用するときに困ることを挙げてみます。
[テストケースそのものに対する困りごと]
- テスト観点と呼ばれるようなキーワードや条件の記載項目に対して
→大中小項目のように、観点に該当するキーワードを入れたいが、シートで管理しようとすると、カラム単位の粒度がバラバラになったり整理ができなくなるし、ツリーで管理しようとすると、重複したりどこにぶら下げてよいのかわからなくなることがある
→とにかく再利用の仕組みをつくるのが難しい(コピペ祭りになる) - 仕様の記載箇所に対して
→どのような記載をしても変更が起こるため、そのうち追従できなくなる - テストケース名に対して
→テストケース名からテスト要件が理解できないことがある、もしくは、テスト要件とテストケースの関係を見せようとしてカラムが増えすぎてメンテナンスがしにくくなる
→そもそもテストケース名をつける意図が共有されず、適当な名前をつけてしまい、ケース名の存在価値がなくなる - 事前条件・テスト手順・期待結果に対して
→変更が入ったときの記載ルールが定まらない
→そして訂正箇所や変更前を残そうとして見た目も可読性も悪くなる
(以下のような変更が入るため、それぞれ対応しなければならない)
・テストの事前条件を一時的に変更する必要がある
・テスト手順を一時的に変更する必要がある
・期待結果を一時的に変更する必要がある(政治上の都合とか)
・テストの事前条件を恒久的に変更する必要がある
・テスト手順を恒久的に変更する必要がある
・期待結果を恒久的に変更する必要がある(仕様変更とか)
→ケース展開後なので修正箇所が飛び散っていて反映させるのが大変
→マニュアルテストだと、データ駆動やキーワード駆動ができなくてコピペ祭りになる
[テスト実行時に関する困りごと]
- 実行に関する項目全体に対して
→実行結果をケースと分離して管理することができない
(毎日結果データがファイル単位で増えていくことがありますね・・・) - インシデントチケットIDに対して
→実行結果からチケットにアクセスするのは容易だが、チケットから実行結果にアクセスすることが容易ではない
→実行結果に複数のチケットが関連すると、修正確認の管理が難しくなる - テスト結果に対して
→テストケース単位で、どの段階でステータスが変わったのかをたどるのが面倒になる
[共通する困りごと]
- 困りごとに対応するときに、なんでもかんでも「備考」に逃げる!!!(笑)
これらの問題に対して「これなら解決できる」という唯一の案があるわけではないです。具体的に言えば「テスト管理ツールを使えばよい」という簡単なものではなく、上記の問題にすべて対応可能なツールをつくったとしても、導入にあたってルールを決めたり、カスタマイズを行ったりする必要はあります。そして、どのような解決策をとるにしても、データモデルを意識しているほうが、より納得がいく解決策を見つけやすくなります。私はデータモデルの作成に慣れていないので、うまく作成できるようになれたらいいな、とは思っています・・・でもまだ学べていないです;あぁぁ;
テストケースの管理って難しいしめんどくさいです(笑)。だけどどうやったら最適解を出せるかなぁってツールと格闘するのは結構楽しいなぁって思っています。