「テスターちゃん」で学ぶソフトウェアテスト②

「Qiitaに書いてた記事をnoteに移行しよう」シリーズと言うことで、Qiitaに投稿している記事の掘り起こしとなります。また、内容の整理も行う予定のため、Qiitaに投稿した記事をそのまま移行する形とならない場合もあります。ご了承ください。

■Archives

■テストケース実行について

・テストについて

テストケースとはテストする項目のこと。

基本的に

・仕様の確認
・異常系の確認

が書いてある。
※仕様書をただ写すと正常系の確認のみのテストケースとなっている可能性もあるとのこと。

Excelやスプレッドシートを使う現場が多いが、テスト管理ツールを使うところもある。

テストの基本＝テストケースの実行である。
疎かにすると確認漏れが発生することもあるので、とても大切な作業である。

・テストケースの中身

・前提条件
・入力値(因子)
・Steps(手順)
・期待結果(期待値)
※但し現場によって書き方がさまざまなので、基本的に現場に沿う形で

前提条件やテストする場所に気をつけること。
※同じ機能が違う画面にも搭載されていたりするため。

期待値通りだからPass

これも現場ごとによって表現が異なる。

因みに過去にいた案件では、

・OK
・NG
・BL
・N/A

で表していた。

テスト実行の時も報連相はしっかりと！
自分の担当範囲が終わったら報告する→次の仕事がある可能性がある。

「多分これのことだろう」と自己判断してしまうことが一番やってはダメ！！
わからないことは必ず実行リーダーなどの管理者に都度質問すること。
※特に在宅などで直接メンバーと口頭でのやり取り出来ず、チャットなどで質問しても返信までに時間がかかる場合もあるが、そういう時こそ怠らないように気を付けよう。

そう思ってしまう原因としては、設計者の書き方が実行者に伝わり難いという可能性もあり得る。
なので、判断に迷うテストケースの設計は完全にOUTだと思われる。
因みに、「実行者が質問しなくてもスムーズに実行が出来るケースを書くように」と過去にいた案件のチームリーダーに口酸っぱく言われたことを今でも心に留めている。

そのため、テストケースは第三者が再現出来る、客観的に判断出来るように書くのがBEST！！
→実行者によって結果が変わってしまうのが一番の問題である。
新人でもプロやベテランでも同じバグが出せるような差が出ないはっきりしたケースが良い。
φ(.. )ﾒﾓﾒﾓ
絶対忘れないでおこう。
※但し、そうではないテストケースもあるので、その場合は実行者自身が考えることを求められる。

■バグ票の書き方

・バグ票って何？

どんなバグがあったか関係者に伝えるもの。
→バグの修正までの流れも記録される。
※現場によって言い方は異なる。

・バグ票の鉄則

・バグの情報が相手に明確に伝わるように
・関係者が再現出来るように

具体的に書くこと。

バグの内容が明確に相手に伝わるように書く。

・要約はどこで どうしたら こうなったと書くのが基本である。
〔EX〕
〇〇画面で「保存」を押すとエラーが表示される。

・本文で必要な要素は

・環境
・再現手順
・現状(実際の結果)
・期待結果

①環境
バグが出た時の環境のこと。
テストしているブラウザ・スマホの情報など。
何故なら、他の人も同じ状態で作業や確認をしているとは限らない。
環境を書かないと「再現するしない」のやり取りが増えてしまう。

②再現手順
他の人も再現出来るように手順を書く。
基本は1ステップ1行動。
→行動を詰め込むと勘違いの元になるため。

③現状(実際の結果)
どんなバグが発生しているか。
調べてわかったことも書いておくと、開発の人の調査の手助けになる。
→ただし、自分の推測を書くことは×。起きている事実を書くこと。

④期待結果
どう動作して欲しいか。

情報を分けて相手に伝わるように書くことが大切である。

・その他

・バグの優先度の設定。
  優先度はプロジェクトによって決まっているから確認しておく。
・画面キャプチャを使おう。
  画像や動画があると、それを見るだけで伝わり易い。
  ※会社によっては使用してもいいツールやブラウザの拡張機能が決まっている場合もあるので、要確認!!