19.テストケース実行 その②
テストケースの項目
現場によって違うけれど、基本的には
- 前提条件
- 入力値
- 手順
- 期待結果
- 結果記載
から成る。
次回の内容にもなるけど、「手順」「期待結果」だけのところもある。
というか、作者が見た限りそっちの方が多いゾ！
あと「振り返り」に一生懸命すぎるチームが陥る罠。
「項目がめったやたらに増える」
です(^-^;
仕様書どのページの記載か、何月何日に誰がやったか、何回目の実施だとか、優先度とか端末とか場所とかBTS URL記載欄とかテスト意図とか……。
で最終的にオールマイティ項目・備考！ 何を入れてもいい最強項目！
横にずらーーーーっと長くなって、テストの作成も実施時もドキュメントの記載に明け暮れることがあります。
どんな情報が欲しいのかは絞りましょう。
そうしないと作成者も実施者も一緒に召されます。
……ごめんなさい、私の経験談です(^-^;
ちなみにエクセルで実行するときは、横に項目が長いとスクロールする必要が出てきます。
実行時にいちいち横スクロール。
次の項目を見て横スクロール。
これってスンゴク面倒くさいです。
ひとつひとつ正確に
ドメインによって大きく変わるだろうけれど、項目数は数千を超えることも少なくありません。もちろん万のときもあります。
そんなとき
「目標をセンターに入れてパス……目標をセンターに入れてパス……パス…パス…パスパスパスパス」
と雑にパスを付ける人もいたり。
世の中よくできているもので、そういったところで大体本番障害が発生して泣くことになります。
テストケースを見返すと、本番障害箇所は「パス」
テスト実行者にヒアリングすると「あ、いや……見たと思ったっすけど。うっかりしてた感じッス」と返ってきたりします。
テストケースはほとんど「重複なし」で書かれていますから、一か所見逃すとその後通らない可能性がとても高いです。
ひとつひとつしっかりと確認しましょう。
このとき最もコワイ状態が「記載されたPassは本当にPassなのか」という疑心暗鬼になったときです。
信頼が失われること……本人にとっても、チームにとっても絶対に避けるべきこととなります。
……ごめんなさい、私の経験談です(^-^;
というか、この辺に書いてる話もマンガの話も大体私の経験談ｗ
ホウレンソウ
小さいチームは「報連相は必要ない！」みたいなこともあるかもしれませんが、大き目なチームで活動する際は必要です。
リーダーが「あっAさんが困ってる！ Bさんはそろそろ終わりそうな顔！ 」みたいに気付くことは（あったりするけど）そうそうないです。
管理コストがかかります。
メンバーの方から「これがわからない」「終わりました」と報告してもらうのが一番スムーズです。
あと「わからないけど聞けない人」も少なくはないです。
リーダーが忙しそうに見えるから……こんなこともわからないのかと言われるかも……新人なのにいっぱい質問したら嫌われる……理由はたくさんあります。
ここは本人に「わからなかったら必ず聞くんだよ！」と注意するのではなくて、リーダーや周りの人が確認したほうがよさそうです。
大体は「困ったさんオーラ」が出ています。
例えばスマホを見たままフリーズしていたり、チラチラとリーダーの方を見たり、しきりに首を傾げたり。
合図は発しています。
最初のうちはできる限り気付いてあげるのが良いです。
私の場合は、新しく来た人の隣には説明が上手な人に座ってもらうようにしていますｗ
黒い影の人
某少年探偵団でいっぱい出てくる人。
割と使いやすいことが分かったので、この先このマンガでもいっぱい出そうな予感。
