底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

【UIテスト】クソみたいなテストケースを設計してたので反省している

これまでSEとしてシステム開発の現場でコーディングと共に単体テスト(UT)や結合テスト(IT)もやってきたが、これこそがテスト設計の本質、というようなものが自分の中ではっきりなかった気がする。客先常駐での期間の短さもあるし、現場ごとに「やり方」が異なるというのもあるし、最大の要因は自分の中で考えて設計してなかった、ということだと思っている。ただ単に日々のタスクというかノルマというかそういったものを消化することが念頭にあり、良い設計とは?という意識がなかったと思う。

 

「じゃあ今は『良い設計とは何か?』という意識のもとでしっかりテスト設計できているのか?」と言われると正直「できてません」と答えてしまう状態。徐々にそういう意識が芽生えつつある、という感じ。

 

芽生えつつある、というか必要に迫られてそういう意識に切り替えてる、という方が近いかもしれない。きちんと設計されていないテストケースをベースとしてチームでテストを実施すると、「実施できない」「確認内容が不明」などテスト実施中に中断して確認作業やテストケースの修正などで時間が取られることが増えたからだ。

 

少しでもそのような余計な時間を取られないためには「実施するにあたってテスト実施以外で時間を取られないようにしよう = だったら最初から良い設計をしておこう」という認識にならざるを得ない。

 

異常なテストケースを疑問に思わない

今のSES先にQAエンジニアとしてアサインされて、テストケースを確認したときに、こんなテストケースでも疑問に思わずにテストを進めてしまっていた。

 

f:id:starscream1999:20210710215328p:plain

悪い見本

だいぶ記述を端折ってはいるけれど、このようなテストケースが当たり前のように使われていた。ログイン画面に対して、IDとパスワードをそれぞれ入力し、次の画面に遷移してその画面の表示を確認するというような感じのテストケースにはなっている。どのあたりがテストケースとして正しくないかわかりますか。

 

このテストケースを一目みて、違和感を覚えることがQAというかテストエンジニアとしての第一歩かなと思います。ちなみに私は、このケースに違和感を覚える前に「こういうものか」と納得してテストを実施してしまっていました。程度が知れますね。

 

こんなケースが1年くらい前まで散見されたのが今のQAチームだった。これでは良いテストにならない。

 

それでは、どこが正しくないか見ていきましょう。

 

期待値があいまいなテストケースはとにかくダメ

「XXXXが正しいこと」という期待値はやりがちなのだけど、テスト設計者の意図とテスト実施者の意図が一致してれば良いだろうけど大概一致しないので、期待値としてはダメな記載です。何を持って正しいと判断するのか、を判定できないため。

 

ちなみに今のSES先のテストケースにはこのような記載がめちゃくちゃ散見されていた。それについて「これではきちんとした確認ができないのでは?」と主張すらしていなかったので自分も当然同罪だし、実際に設計時に「XXXが正しいこと」と期待値に記載していた。疑問には感じてはいたが、「妥当性をきちんと書くと手間が増える」という滅茶苦茶な理由でそのままにしていた。情けない話である。これでベテラン顔していたのだから始末に負えない。

 

別の話題になるけど、「XXXが表示すること」「XXXが表示されること」などの表現の差異に時間を取られるのは馬鹿馬鹿しいと思ってる。システム側が表示するので「表示すること」が正しいというのはわかるが、別にそこを「表示されること」と記載したとして影響はない。こんな指摘は設計書の文字サイズが揃ってないとかの指摘と同じだと思う。

 

実施手順が書いてない

そんなテストケースあり得るのか、という感じだが、あり得たというかそんなテストケースでテストを実施していた。「なぜテストケースに実施手順がないのだろう」と疑問に思わなかったのだろうか?「ここの現場はそういうやり方なのだな」という意識だったと思うけど、それにしても手順がないことそれ自体に対して違和感を覚えるべきだった。言語道断だと今は思う。

 

では、実際にテスト実施手順が書かれていないテストケースをどのようにすすめていたか?それはもう単純に業務システムの仕様を覚えて、頭の中で実施手順を描きながらすすめていたのです。これが何を意味するか。つまり、業務システムを知ってる人でないと実施できないということ。

 

例えばその業務システムを知らない人に急にテストを実施してもらうことになっても、その都度「X画面はこのA画面でBボタンを押して、Cを入力すると〜」というようにいちいち説明することが必要になる、ということ。非効率極まりない。

 

実際に、「どこまでの粒度でテスト実施手順を書くか」という部分についてはテスト実施者のレベル(例えば昨日今日入ったアルバイトにもテストしてもらう必要がある場合など)を考慮して設定する必要があるだろう。ただ、どのような場合でも「テスト実施手順が書かれていない」というのはあり得ない。

 

 

テストタイトルが同じものがいくつもある

例えば同じ画面内で同一項目の複数のテストを実施するにあたって、「X画面_Y項目」というタイトルのテストケースが並んでいたらどうだろうか。実施者は期待値や実施手順、前提条件などを見比べて異なるテストケースを実施していることを確認しなくてはいけない。

 

設計者の怠慢という部分もあるだろうが、設計時にどんなことを確認するテストなのかを端的に書けないというのはテストの期待値を誤っている可能性も出てくる。どんなことを確認するかわかっていないのに期待値をきちんと書けるだろうか?

 

同じ表示系の確認であっても単に数値が表示されることを確認するのか、計算結果を確認するのか、計算結果に例外が起こることを確認するのか、パターンは考えられる。

 

テストタイトルがない、単に「10A-1」というような管理番号でテストケースを管理する場合もあるだろうからテストケースタイトルをつける設計の場合に必要な意識だと思ってください。(シナリオテストとか)

 

また思い出したら続き書きます。