20.テストケース実行 その③
UI (ゆーあい)
ユーザーインターフェースの略。
とりあえず何かとの接点は大体「インターフェース」。
ユーザーとの接点、つまり画面とか見栄えとか。それがユーザーインターフェース。
パソコンのインターフェースといったらUSBやDisplay portを差す場所。
ちなみにUIという言葉はIT関係の人は日常的に使うが、本当の新人さんはわかってない。
首をかしげていることがあるので注意。
正しい系の項目
テストケースの期待結果は「YES」「NO」で答えられるクローズドクエスチョンがいいゾ!
期待結果に「UI崩れがないこと」「UIが正しい」といった記載があると、これはオープンクエスチョン寄り。
YES, NOで答えられそうだけど、実は自由回答な感じ。
テストケースというよりは、探索的テストの「ミッション」に近い。
(このミッションがあるから、それについて探索する形)
こうなってくると、新人さんだとバグが出ない、もしくは実行時に質問の連続になります。
逆にプロがいると、その項目だけでバンバンとバグを出してくれたりしますが(汗)
ちなみにその昔私が20名以上のメンバーをまとめていた時のこと。
この手のテストケースがあるとそれはもう居酒屋のごとく手が挙がり質問が飛び交う大嵐となったりしたものです(^-^;
こんな「テストケース」があればすごい
- 第三者が再現できる
- 第三者が判断できる
- MECE(漏れなくダブりなく:Mutually Exclusive and Collectively Exhaustive)が完璧だ
- 項目数は少ないのに網羅率は高い
- バグがよく出せる
暗黙知が少なく、客観性があり証明になり、少ない手数で網羅率が高くてバグがよく出るテストケースですね!
…………。
言うは易く行うは難し。
……少なくとも私はそんな領域にはまったく達していません(滝汗
曖昧なテストケース
曖昧なテストケースはよくある!とてもよくある!
アプリ系とかゲーム系とかすごくよくある!
「任意の値を入力する→入力が反映される」みたいな!
だからといって「明確なテストケースを提示してください。私こうみえてもテストにうるさいのでこんなテストケースは実行できません」とテスト中に言っていたのでは何も始まらない。
というか終わる。
こういったテストケースの場合、主導権がテスターとなる。
入力値が決められている場合は自分の考えをはさまないが、この場合だと否が応でも自分が考えていかなければならない。
そうなるとテストケースでよく言われる「やらされている感」から「やってる感」となり、モチベーションの観点からだと、メンバーが張り切ってテスト実行したりする。
ただしマンガ内にも描いたが、抜け漏れは発生する。
メンバーのスキルに項目が左右される。
明確な品質保証をした、という観点からするととってもアブナイのだ。
プレースホルダー
メールアドレス入力欄に薄く「sample@example.com」みたいに描いているアレ。
説明にスペースを割かなくていいから楽になったりする。
仕様書ではさりげなく書かれていて、実装ではだいたい抜けている。
多言語対応の時も大体漏れている。
最終的にはなくても気付かれなくて放置されている。
そんな不遇な子。
てへぺろ
現実ではお目にかかったことがない。
以下の条件を満たしたときに発動可能となる技である
- 仲の良い人がいる
- 許される空気である
- 可愛い