QAさん "じゃない人" 向け、かんたんテスト設計フロー

みなさん、テストしてますか?
テストせずに、本番リリースですか? (男前!!)

最近は、やれデジタルが、やれ自動化だ・・・とかなってきてて、、、
企画力も大事ですが、テストする力も大事だと思うわけです。
ここでは、GUIが存在するテストを想定して書きますが、なにごとも要点は同じはず。

| やることたち

• 目的とゴールの確認
• メインルートを可視化する
• メインルート内での分岐を肉付けしていく
• サブルートを洗い出す
• サブルートで必要そうなのをピックアップする
• サブルートを可視化 → 分岐を肉付けしていく
• 例外系を洗い出す
• それぞれの例外に対しての期待を明確にする
• 例外ルートを可視化する

これやったら、あとは項目書に落とすだけ

| 目的とゴールの確認

まずは、この画面なりシステムなりが、なんのために存在しているのか、なにを達成できたらみんなが嬉しくなるのかを確認します。
仕様に落とし込めていない部分をどう解釈するのか、不具合が出たときにの提案の方向性はどうするか、みたいなところは、ここにかかっています。

| メインルートを可視化する

最も一般的な使い方のフローを書きましょう。
ざっくりでいいです。

とかとか。
メインルートが一番しっかり設計されているはずで、どれがメインルート? メインルートわかりづらくね? ってなったら、そもそも企画段階でいけてない可能性あるので注意です。

| メインルート内での分岐を肉付けしていく

メインルート内での分岐を洗い出していきましょう。
脳内で自分の動きを再生できればOKですが、難しそうなら頑張ってフロー図を書きましょう。
(辛いけど、後で漏れるより100倍楽。)

| サブルートを洗い出す

一般的ではないけれど、こういう使い方あるよねという方法を洗い出しましょう。
ここで、とてつもなく大量のサブルートを見つけてしまったら、たぶんユーザーは迷います。
そもそも企画段階でいけてない可能性あるので注意です。(本日2度目)

| サブルートで必要そうなのをピックアップする

必要なもの、とばっくり書いてしまいましたが

• サブルート突入の前提条件
• サブルートに入るトリガー
• サブルート特有の動作

あたりが出てきていればOKです。

| サブルートを可視化 → 分岐を肉付けしていく

さて、脳内再生 or フロー図、でOK!
(辛いけど、後で漏れるより100倍楽。)

| 例外系を洗い出す

例外系、エラーが出てほしいものを洗い出しましょう。
これは設計段階で抜けていることがあります。
なお、「まぁ、単純な動作だから」「わかりやすいデザインだから大丈夫」とか言われる場合もあるかもしれませんが、 考慮してなさそうだな・・・と思ったら注意です。例外も考慮してない企画はユーザーのことも考えてません。

• エラーが出てほしいときにエラーが出ない
• エラー内容がおかしく、変にサポートコストがかかる
• 想定してなかった使い方により故障する

起こりますよ。

| それぞれの例外に対しての期待を明確にする

例外にも期待があります。

• xxx な状況で、A を入力したら → Error A って文字が出る
• yyy して zzz したら、 Error xyz ってポップアップが出る

とか。
例外に対して、システムがどのように振る舞ってあげるのかを明確にしましょう。

| 例外ルートを可視化する

さて、脳内再生 or フロー図、でOK!
(辛いけど、後で漏れるより100倍楽。)

| 結び

では、これをテスト項目書に落とし込んでいきましょう。
テスト項目書には

• 最低限
  └ 操作 + 期待結果

• あったほうがいい
  └ 画面名 or ID
  └ 部品名 or ID

があるとよいです。

では、素敵なテストライフを。

| スペシャルサンクス

画像提供: ぱくたそ (pakutaso.com) / photo by とむ