テスターちゃん【4コマ漫画】

ソフトウェアテストの用語、やり方などを4コマ漫画でわかりやすく説明する(予定の)ブログです。脱線も多いです。



【新人さん向け】web系でよくあるテストケースの実行の一連の流れと注意点

こんにちは。作者です。

 

IT系では在宅業務になった会社さんが結構あるかと思います。

在宅業務は良いのですが、結構大変な目にあっているのが…新人さん!

入社早々在宅環境に投げ込まれ、先輩たちも慣れない環境のせいでサポートがあまりうけられない!なんて方々もいらっしゃるかと思います。

あと、先輩と同じ空間にいたら気軽に聞けていたことも、チャットを介してだと聞きにくくて放置している疑問もあるかもしれません。

その結果、自分がどういう風に動けばいいのかわかっているようで曖昧……

さらに、6/1から在宅があけて出社に!!

ああっ!!私はどうすれば!?

…みたいな人のために(?)、テスト系業務をすることになった新人さんが恐らく最初にやることになるであろう「テストケースの実行」のweb系でよくあるフローを書いておきたいと思います。

作者はwebやゲーム系の会社しか回っていないので、他の場所は知らないです。

けれど、ゲーム/web/appの巡った場所は大体似たようなフローだったのでそれについて書いていきます。

もちろん場所によってルールは様々。

大まかな流れ程度の把握にしましょう。

自分の会社、担当業務でのやり方はしっかりと先輩方に聞いて把握してくださいね!

 

【新人さん向け】web系でよくあるテストケースの実行の一連の流れと注意点

テストケースの実行の大まかな流れ

  1. テストリーダーからテストケース実行の担当範囲が割り振られる
  2. テストする環境とデバイス(ブラウザ)をしっかり確認
  3. テストケースをひとつずつ、手順をしっかり見て確認
  4. 問題がなければテスト結果をPassなどのステータスにする
  5. 問題があったらテストリーダーに問題があった旨を報告
  6. テストリーダーがバグか、問題なしか、既知(登録済み)の問題か判断して対応を指示
  7. バグ登録の指示があったらテスト結果にFailを入れてバグ票を書く
  8. バグ票を書いたらテストリーダーに報告する
  9. そのFailのテストケースとバグ票の番号(URL)を紐づける(記載欄に書くとかね)
  10. 自分の担当範囲が終わったらテストリーダーにちゃんと報告
  11. 登録したバグの修正が返ってきてたら、確認テスト(そのバグが直ってるか確認)を実施
  12. 直っていたら、バグ票のステータスを決められたステータスに変更(修正済みなど)
  13. そのバグ票が紐づけられているテストケースをPassにする(または修正済みステータスなど)
  14. もし直っていなかったら、テストリーダーに「直ってるっていってるけど直ってないです><」と連絡

 

大体こんなかんじ。

コレがweb系でよくあるテストケースの実行時のサイクルです。

さらに細かく見ていってみましょう。

 

 

テストケース実行の流れの説明

テストリーダーからテストケース実行の担当範囲が割り振られる

ソロのテストもありますが、チームプレイの場所が多いと思います。

そういうときは

「~さんは、ここのテストケースをお願いね」

なんて担当範囲の指示があります。

その担当範囲がどこを指しているかわからない、何をすればいいかわからない……

そんなときは迷わず周りに聞いてください。

なんとなく「ここだろう」でテストして全然違うところやっていた、なんてことはよく聞く事故のひとつです。

 

テストする環境とデバイス(ブラウザ)をしっかり確認

ここも事故を起こしやすいところなので要注意!

例えば「テスト環境」でテストするはずだったのに「本番環境」でやっていた!

これはテストリーダーが青ざめるヤツです。

作者はもちろん経験済みですよ!(ぉぃ

あとは「アルファ環境」でテストするはずだったのに「ベータ環境」でやっていた、みたいな間違いもあります。

この場合、テストすべき場所が違い、確認すべきテストができていないのでやり直しになります。

ご注意を。

同様に、テストすべきブラウザやデバイスを間違っても大変なことになります。

「AさんにXperiaのテスト頼んでたけど、BさんもXperiaでテストしちゃった!」

なんてテストすることがぶつかってしまったら、その日一日やったことが無駄になってしまいます。

 

テストケースをひとつずつ、手順をしっかり見て確認

テストケースの実行は丁寧にやっていきましょう!

ここも、指示された値があるならちゃんとその値でやりましょう。

作る側が「どの値でテストすると効率的か」と考えながら作っています。

あとたまに「これ同じじゃない?」みたいなテストケースがあります。

けどよく見てみてください。

よ~く見ると手順の最後が「キャンセルする」とかになってるかもですよ!

あとは同じ「xxと入力する」でもA画面とB画面の違いがあるかもしれません!

「よくわかんないけど、ま、同じだろうからpass」とかやるのが一番キケン!

要チェックです。

 

あとは、基本はテストケースは順番にやっていくようにはなっています。

ですが経験を積んで慣れまくったら、やりやすい順番でやっても良いと思います。

(順序が大事なケースもあるけど、そこはちゃんと判断してくださいね)

たまに順番通りやると悲惨な目に遭うテストケースがあります。

例えば上からテストケースを見ていったら……

  • アプリをインストール
  • アプリをアンインストール
  • アカウント登録をする
  • アカウント退会する
  • 登録済みアカウントで投稿する
  • ……

え、なにこの賽の河原…みたいな流れが爆誕することもあります。

作る人が「機能ごとにまとめてウンヌンカンヌン」と考えまくった結果、一周回って謎な順番になっちゃうヤツです。

 

他、よくあるのがフンワリしたケース。

  • 手順:入力欄に任意の文字を入力する
  • 期待結果:入力した文字が投稿される

これもまぁ偉い人が見たら怒るやつですが、テストケース作りこむ時間がないとかあるのですよね。

作者も気持ちわかるし、これはこれでやりようによってバグが出しやすいです。

 

この場合よく

「あ」って入力して出たからヨシ!

とやる人もいますが、もう少し頑張ってみましょう。

 

例えば、SNSっぽいサービスだったら、実際にユーザーが入れそうな入力をしてみましょう。

「この記事はいいけど、考えさせられる(^-^;  共有しときますね。https://~~~~~

みたいな感じ。

さらに

「何とかそのプロダクトのバグを見つけてTwitterでバラまいて注目を浴びようと目論む男子高校生」

になりきってテストするのもおすすめです。

そういう人なら何をするでしょうね?

改行だけとか、スペースだけとか、寿司ビールの絵文字問題とか……

そういう気分大事。

 

あと

  • 手順:UIを確認する
  • 期待結果:UIが正しい

ね。わかる!気持ちわかる!

まぁ、こういう場合はリリースされているプロダクトなら本番環境のUIと比較、出てないプロダクトなら画面仕様と比較です。

ユーザーとして違和感ないか、の判断基準でpassさせたときに見落とす最大の問題が

「そこにある予定だったボタンがない」

です。

「存在しない」ものはパッと見だと問題なく見えるんです。

気づかないんですよ。

けど、気づかずリリースすると、丸々項目1つが消えてなくなっているというかなり大きな事故になります。

めっちゃ叱られます(経験済み)

 

問題がなければテスト結果をPassなどのステータスにする

テストして問題がなかった時はPassなどの結果を入れて進めましょう。

エクセルやスプレッドシートだとpassのケースをまとめて一気に結果を付ける(セルの右下にカーソル当てて引っ張るヤツ)をやる人がいますが、それは止めておきましょう。

間違って、スキップしたケースをpassにしちゃうとか、FailのケースをPassにしちゃった、なんて事故が発生します。

リーダーから「ここ動かないはずだけど、なんでpassついてるの?」という怖いチャットが飛んできますからね。

 

問題があったらテストリーダーに問題があった旨を報告

期待結果と異なる場合や、それだけではなく、触っていて違和感があった場合はリーダーに報告しましょう。

そのとき

「テストケース12が期待結果と異なります」

だけだと「えーっと12は…12は…ふむふむ、これがどうなってたの?」とチャットの往復が増えます。

なので

「テストケース12の~~するケースですが、期待結果が〇〇〇ではなくxxxになっています」

と言ってくれると、地味に嬉しかったりします。

 

テストリーダーがバグか、問題なしか、既知(登録済み)の問題か判断して対応を指示

ここはリーダー側のお話。

たまに「バグ見つけたら報告しないでいいから登録しちゃって」という人もいるんですが、まとめ役による判断は大事です。

これやらないと、重複バグ登録がとても増えます。

みんながみんな、ちゃんと重複してないか確認して登録しているか……人数が増えるとそうもいかないのです。

あとは「いつぞやのスプリントの時にその挙動で良しとしたもの」がケースに残ってて再登録しちゃったとか、暗黙の仕様のものを登録してしまうことも多いです。

他、優先度や重要度の判断もとっても重要です。

なるはやで直さないと次のテスト進めないものは優先的に、UIの軽いバグなら優先度は後に……なんて判断が必要です。

結構いるのですが「自分で見つけたバグは最強だし問答無用で優先度超最大」みたいにつける人がいます。

リーダーの全体バランスが取れた判断や、判断基準を決めておいてそれに従って付けることが大切になってきます。

 

まとめ役がしっかり機能していないと、テストの交通整理ができずグチャグチャになってしまい、テスト側だけでなく、修正を直す開発側までテンヤワンヤになります。

そうなると炎上必至なのでお覚悟を!

 

バグ登録の指示があったらテスト結果にFailを入れてバグ票を書く。
バグ票を書いたらテストリーダーに報告する。
そのFailのテストケースとバグ票の番号(URL)を紐づける(記載欄に書くとかね)

まずはしっかりとテストケースに記録を残すことが大事!

ちゃんとそのテストケースが失敗した結果を残すこと。

忘れがちなのが、そのFailのテストケースと登録したバグ票を関連付けておくことです。

これはバグ修正後の確認テストをするときに大切になりますからね。

(管理する側としてはどのケースでどんなバグが出て、そのバグがどうなったかが追えます)

 

バグ票を書いた後もちゃんとリーダーに報告しましょう。

(バグ票の書き方は語ると長くなるので割愛)

自分ではステキに書いたバグ票でも、情報不足だったりすることがあります。

テストリーダーは

「このバグ票の内容が相手に伝わり、相手が再現させることができるか」

ということを確認しています。

 

自分の担当範囲が終わったらテストリーダーにちゃんと報告

自分の担当範囲が終わったら、次何するか聞くのが恥ずかしくて、リーダーが声をかけてくれるのをただひたすらに待ち続ける人がいます。

一緒の空間で働いていた時には(~さん、もう終わっちゃったかな?)みたいに気づけていたことも、リモートになると気づけないことはいっぱいあります。

リーダーはあなた以外のメンバーのことも見ていますし、他の部署のことも見ていますから忙しいのです。

なので終わったら「私の担当範囲終わりました!」と報告しましょう。

それでリーダーは「お~!終わったか!そしたら休憩にしよう!」とか判断をすることができます。

 

登録したバグの修正が返ってきてたら、確認テスト(そのバグが直ってるか確認)を実施 / 直っていたら、バグ票のステータスを決められたステータスに変更(修正済みなど) / そのバグ票が紐づけられているテストケースをPassにする(または修正済みステータスなど)

「開発の人が直ったって言ってるからテストケースをPassに直して完了!」

とやる人がいます。

けれどそれはダメ!!

本当にそのバグが直っているか、ちゃんと確認しましょう。

開発の人はプログラム上で、直したところだけプログラムを動かしてOKしているかもしれません。

プログラムだけではなく、システム全体をつなげて実際にアプリやwebを動かして確認すると、他のシステムとの兼ね合いでおかしな動きをする可能性も十分にあるのです。

必ず、確認テストは行ってからFailのケースはPassにしましょう。

 

あと「リグレッションテスト」というものもあります。

これは、修正した箇所以外の場所に影響が出ていないか確認するテストです。

テスト計画によって全体的なリグレッションテストがスケジュールに組み込まれているかもしれません。

ですが、余裕があるようなら、自分でも修正があったところについて

「あれ?これと似たような機能があそこにもあったような…。これとつながってるあの機能は動き変わってないよね…?」

などなど考えながら確認をしてみると、テストのよい練習になります。

 

さて、確認が終わったらちゃんとバグ票のステータスと、失敗したテストケースのステータスを変えておきましょう。

テストケースのステータス変更をしないとリーダーが夜なべをして

「pass rate 100%になってないなぁ…なんでだっけなぁ…ここfailのままだったけどなんだっけ……。バグ票のリンクを開いて……。あ、これもう確認済みのヤツやん……passにかえるか……」

という作業をする必要が出てきます。

ちなみにこの確認作業の時にバグ票のリンク張ってないFailが現れるとウンガーってなります。

リーダーは深夜23時にウンガーしながらレッドブルを飲むことになります。

チャットに愚痴を残していることもしばしば。

この作業ね、大事だけど地味だし、いろいろ大変なんですよ……(経験者)

 

もし直っていなかったら、テストリーダーに「直ってるっていってるけど直ってないです><」と連絡

バグ修正の話に戻りますが、確認テストを行うとバグが直っていないことがあります。

上で書いた原因のときもあります。

ただ、少し待ってください。

バグが直ってない!と思ったときにweb系で一番多いのが「キャッシュ」です。

ブラウザには、前の表示内容を取っておいて、それを出すことによって表示速度を速める機能があります。

それで、バグ修正前の表示がキャッシュされていて、修正後の表示が見えないことがあります。

UI系のバグならキャッシュは真っ先に疑いましょう。

で、その時は「キャッシュ削除」や「スーパーリロード」を試してみましょう。

そういったことを試してみて、それでも直ってなかったらリーダーに伝えます。

そしてリーダーから開発に連絡がいきます。

ちなみにこの時の返答で多いのは「あ、マージ忘れてました…」だったりします。

 

***

 

さて、いかがだったでしょうか?

最初にも書いた通り、これは「よくある流れ」です。

各社やり方の細かいところは異なります。

そういったところはちゃんと周りの人に聞いて覚えましょうね!

なんやかんやで周りの先輩方も新人さんのことは心配していて、質問すると細かく教えてくれるものですw

怖がらずに、わからないことは聞いてみてくださいね。

 

 

 

 

f:id:m_training:20200401070524p:plain