こんにちは、@illypon です。
趣味でソフトウェアテストをやっている者だ。
さて、ACCESS Advent Calendar 2019 8日目は、ソフトウェアテストが本業でない方にもできる、
早く・簡単に・重大なバグがポコポコ見つかる汎用的なテストの技法を紹介します。
ラインナップは以下の通り。ぜひお試しください。
- 画面遷移図A3印刷技法 (難易度★☆☆☆☆)
- ぶん殴り技法 (難易度★★☆☆☆)
- 椅子引き技法 (難易度★★★☆☆)
- 間違い探し技法 (難易度★★★★★)
画面遷移図A3印刷技法
- 難易度: ★☆☆☆☆
- 用法: 1秒で見つかるような恥ずかしいバグを撲滅したいときに。
やりかた
- 画面遷移図をA3用紙などなるべく大きい紙に印刷します。
- 印刷した画面遷移図を見ながら、テスト環境で同じ画面を遷移図の通りに順番に操作します。
- 操作が済んだ画面遷移は紙上で大きく×を書き込んでわかるようにしてください。
- すべての遷移をもれなく触れたら完了です。
ここがポイント
紙に印刷することでページスクロールする必要がなくなるので、
スクロールのし過ぎでドキュメントを読み飛ばしてしまうということがなくなりますし、
視認性が良いので作業効率が全然違います。紙は偉大。
また、確認済みのところに×を書き込むという行為によって、確認もれを防止できます。
シンプルな技法ですが、これをやるだけでも1秒で見つかるようなバグはなくなりますよ。
ぶん殴り技法
- 難易度: ★★☆☆☆
- 用法: 手っ取り早くバグを見つけて、設計からやり直した方がよさそうな雰囲気を作りたいときに。
やりかた
| テスト内容 | 起こりがちな現象 | 効果 |
|---|---|---|
| 長すぎる文字列を入力 | ●豪快にレイアウトが崩れる ●数値の見た目が指数表示になる |
●文字列の折り返しや...による省略表現など、長すぎる文字列への対処漏れに気付く ●バリデーションの漏れや誤りに気付く |
| 押せるものは何でも連打 | ●重複したデータが大量登録される ●APIが弱音を吐きだす ●非同期処理のキューが絶望的にたまる |
連打への対処漏れに気付く |
| 大量にデータを登録する | ●データを1件も表示できなくなる ●画面が表示されるのに何秒もかかるようになる ●登録したデータを一括削除するすべがないことに気付き、絶望的な気持ちになる ●検索窓やページャーが必要だと気付く |
大量データを想定することは大事だと気付く |
| でかすぎるデータを入力 | ●システムがだんまりになる ●そもそもPOSTできない ●登録したデータが生焼けになる |
●バリデーションの漏れに気付く ●Webサーバーの設定誤りに気付く ●トランザクションによるデータの整合性が担保されないケースがあることに気付く |
ここがポイント
この技法のコツは、システムを破壊してやろうという悪意を持って一切の手加減をせずに悪い行儀をすることです。
連打するときは1秒間に10回は打てるように鍛え、理解できないほど長ったらしいCSVファイルを作り、
4GBを超える画像やPDFを作り、偽装したファイルを食わせ、大量の一括更新をさせたり、
やたら途中でキャンセルをしたり、いきなり電源を抜いたり、HDDをサーバーからぶっこ抜いたりしましょう。
ぶん殴り技法に弱いシステムは設計時の考慮がいろいろと足りていない可能性が高いので、
設計レビューからやり直すことをおすすめします。
椅子引き技法
- 難易度: ★★★☆☆
- 用法: エラーケースの考慮漏れがいつも多いんだよなぁってときに。
やりかた
| テスト対象 | テスト内容 | 起こりがちな現象 | 対策の例 |
|---|---|---|---|
| ユーザー名を都度取得して表示に使っている画面 (たとえばチャットルームやテンプレートでのスニペット、データのプロパティなど) | よく使いこんだユーザーを削除 | ●ユーザー名の部分がundefinedになる ●ユーザに紐づくデータが見えなくなる |
●ユーザー削除は論理削除にとどめておき、「ユーザー名(退会済)」のように表示できるようにする ●物理削除した場合、ユーザー名は「退会済ユーザー」のような表記に置換する |
| フロントエンドの画面全般 | 別ウィンドウで更新・削除されたデータを操作 | ●データ更新の競合が発生する ●APIからエラーコードが返るが適したエラーメッセージを表示しない |
●データを操作できない旨や、リロードを促すメッセージを表示する ●APIのエラーコードに応じて意味の通じるメッセージをユーザーに表示する |
| 外部サービス(他社APIなど)に依存した機能 | ●だんまりをエミュレート ●メンテナンスモード応答をエミュレート ●異常応答をエミュレート |
●エラーログが大量発生する ●APIのエラーメッセージをそのまま表示してしまう ●よくわからないが失敗した処理がある |
●事前にメンテナンスなどで外部サービスが停止することが分かっている場合は、その時間帯は外部サービスに依存した定期処理を停止する ●エラーレスポンスが返ってきたときのことを考慮した設計にする ●エラー時にユーザーはどうすればいいのか説明する |
ここがポイント
いつまでもあると思うな参照先と外部API。初めからエラーケースのときの外部仕様を考えておきましょう。
画面や機能ごとにあまりにも担当者が違いすぎると、データがなかった場合の考慮漏れが起きやすくなります。
メッセージ一覧を確認するのも汎用的におすすめできます。正常系のメッセージしか定義していなかったらあやしいですね。
バックエンドAPIのエラーがフロントのどのシーンで起きうるのかが整理できているといっそうGoodです。
間違い探し技法
- 難易度: ★★★★★
- 用法: 万能にして最強
やりかた
- 理想通りに完璧にできあがったシステムであればこのように動くだろうというイメージを脳内に投影します。
- 目の前にある現実と向き合ってください。テスト環境を触ります。
- 理想と現実を比較して違うところ、違和感を感じるところがあれば、それは改善したほうがよい仕様であるか、もしくはプログラムの欠陥です。
ここがポイント
この技法の素晴らしいところは、テスト設計をしなくてもほぼ網羅的にインシデントを検出できる上に、
同時に探索的テストまで実行できてしまうという点です。
そしてこれが難なくできるあなたはテストエンジニアが適職です。QAチームにようこそ！
終わりに
ぶん殴り技法と椅子引き技法については、わざわざテストをしなくても、
こういうテストをされても問題が起きないような設計をしよう！と注意するだけでも十分だったりします。
ぜひチェックリスト的に参考にしてみてください。
明日は @diescake が何かIndexdDBネタを書いてくれるみたいです。
あと、12/12も私がソフトウェアテストのネタを投稿する予定です。お楽しみに！