モンキーテストのコツ ( システム開発の品質保証 )
モンキーテストとは
定められた要件は気にせずアプリケーションを動かして動作確認をすることだ。
要するに気ままに勝手に動かしてみるってことだ。
経緯
とある開発で品質保証のためにモンキーテストをした。
モンキーテストをするのはこれで2回目だ。
なので決して自分がテスターの腕が良いわけではないと思うのだが、そこで考えたことを記す。
心得: 壊すつもりで動かす
開発者には無意識にアプリケーションの弱点を見て見ぬ振りをする傾向があると思う。だがテスターはその逆を行く。なるべく意地悪に無茶をして欠陥を見つけ出すのだ。
これは基本中の基本で言わずもがなではあると思うが。
心得: 初心者の目線、ユーザーの目線で見る
システムについては全く無知なユーザーとして振る舞ったほうが良い。
結局ユーザーに見えるのはシステムの裏側ではなく目の前のアプリケーションだけなのだから。
逆にシステム的な都合で見てしまうのはアンチパターンだと思う。
たとえ「このUIは不親切に見えるが恐らくライブラリの都合で作りづらいんだろうな」などと考える必要はない。
たとえ考えたとしても自分で納得して報告を思いとどまる必要はない。
心得: バグを見つけても原因究明のためにコードを見ない
何かバグを見つけた時にコードを見る必要はない。
たとえあなたが開発者でコードが読めたとしてもだ。
コードを読む時間があるなら他のバグを見つけ出した方が有意義だ。
原因究明は開発者に任せよう。
もちろん状況次第だが。
心得: コードリーディングは弱点を見つけるために活かす
僕はモンキーテストと共にコードレビューにも加わっていたので、ある程度コードは読んでいた。この経験はアプリケーションの弱点を見つけるために活かす。
動作が怪しそうな点があればモンキーテストではその箇所を重点的に動かしてみるのだ。
心得: チケットを積むのを遠慮しない
「今は開発が忙しそうだからバグチケットを積むのは気が引ける、やめておこう」などと考えていてはテストは成り立たない。
まずは見つけられるだけのバグを見つけておいて、そこから優先度の振り分けをすれば良い。
「バグを全く知らない状態」よりも「バグを知っているが解決が間に合わない状態」の方がまだましだ。
何故ならプロジェクトでの問題認識さえしていれば未来の解決を検討できる。
もし当のアプリケーションが以後アップデートされないものだとしても、バグが報告されれば開発者は以後の別の開発で気をつけることが出来るだろう。
心得: 複数人でテストする
1人ではテストをやり切ったと思っても別の人が見ると別のバグ・不備が出てくることもある。
複数人の視点が必要だ。
心得: エンバグに気をつける
開発あるあるで1個の修正が別のバグを生むものだ。
修正がおこなわれた周辺機能は改めて動かしてみること。
反省: バグは早めに見つけたい
いちどテストをやり切ったと思っても実はそうではなかった。
また日を改めて試すと別のバグが見つかり始めた。
発見が遅れるほど修正も遅くなる。
なるべくテスト期間前半に多くのバグを見つけ出しておきたい。
反省: テストしにくい部分もちゃんとテストする
操作が難しい部分、準備が面倒な部分はテストを避けがちだ。
自分が避けてしまっているテストがないか自覚的になること。そしてちゃんとテストをしよう。
感想
- 「本当にこんな些細な点まで報告して良いのか？」「自分が変なことを言っていないだろうか？」という気持ちも持ちながらテストをしていた。だが迷ったらアプリケーション自体に尽くすことを考えた。
- プログラミングもせず、専門知識も全く必要なく、アプリケーションを動かしてケチを付けるだけで仕事になる。少し不思議な感じもした。
チャットメンバー募集
何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。
Discussion