読者の皆様こんにちは。今日の記事では前回の”効果的なバグ報告のポイント:開発チームに正確に伝えるためのガイド“に引き続き、効率よくバグを発見していく方法をお伝えしていこうと思います。
普通に考えてバグなんて1個も見つからないのが理想に決まってます。バグが効率よくボコボコと見つかるなんて全然嬉しくない話のように聞こえますが、人間がモノを作る以上ミスや不具合は確実に発生し、それがバグとして現れます。この前提がある以上バグが効率よく見つかってくれる方が仕事としてはいいんじゃないでしょうか?ちなみにある程度テストやバグ出しをしていると、バグが見つからないことに不気味さを感じることもあります(笑)
いきなり過激なタイトルかつ某茶色くみんなが嫌いな虫さんに向けたようなこと言ってますが、程度の違いはあれどこれが意外とバグ探しにも当てはまるんです(虫とバグだけに笑)。例えば作成中のウェブサイトにテキスト入力欄が複数あり、そこにバリデーションがついていたとします。仮にそのバリデーションに何らかの不具合があったり入力欄からSQLインジェクションが引き起こされる状態だったらどうでしょうか?おそらくそれらのパーツにはある程度の使い回しがあったり、1人の人間が全て作っていたりと同じ不具合が同様に紛れ込んでいる可能性があります。どれか一つの入力欄に不具合があることを見つけるまでには多少時間がかかりますが、1度見つけてしまえば効率よく他の箇所も叩きにいけます。
テスト箇所によっては1箇所しかないのにさまざまな動きをするパーツであったり、他の条件によって挙動が異なる部分があります。私の経験上こういったところは大抵作るのもややこしい場合が多いです。”作るのがややこしい”ということは”バグが生まれる可能性が高い”ということになります。全力で叩いてみましょう。たぶん、いや必ず、バグが見つかります。ただしこの時に気をつけなければならないのが、”正しい挙動が何か”ということをテスターがしっかりと把握しておくことです。ここの認識に仕様との相違があるとバグをバグとして見つけられずじまいになってしまいます。
多くの方は作ったアプリやウェブサイトを目的通りに利用し、サービスは正しく機能するでしょう。しかし世の中には正しく使っていても例外的な操作になってしまう時や、田代砲のように悪意を持ってサービスを利用するユーザーも一定数存在します。流石に、通常のテストのために悪意のある利用方法を試す必要はないかもしれませんが、作成したサービスを上限の文字数やファイルサイズ、多数のアカウントからの操作などといった、イタズラの派生レベルで起こり得そうな事象については試しておくといいでしょう。意外と、正規の動作がうまくいかないバグが見つかったりするので一見の価値はありますよ。
これは開発チームの規模やテストの方法によっては少し異なる部分もあると思いますが、過去に別のサービスやシステムを作成した時に見つかったバグを元にテストをしてみるとバグが見つかることもあります。特に”新しいサービスやシステムの作成時に見つかったバグ”を”古いサービスやシステムの更新時に試す”といった手法は有用な時があります。
もはや極意や効率化なんてもんではななくなってますが、実際の利用を想定して上から順に全ての項目を試していくのもアリです。全ての項目を試せば潜んでるバグに必ずヒットするでしょ笑。条件によって操作が異なる部分などは少し手間になりますが、私は最終的にはこの手法に辿り着いている気がします。
バグを見つけるというよりは、”Webアプリケーション作成の際に脆弱性を見つける”という形になりますがOWASP ZAPを利用するのも良いでしょう。これについては”OWASP ZAPの使い方: macOSとUbuntuサーバーを活用したセキュリティテスト“というタイトルで記事も書いているのでよければ参考にしてみてください。
その1からその5にかけてだんだんとパワープレーになっているような気もしますが、こんな感じでバグを探しています。もちろんこれらの手法が全てではないですし、現に私が見つけられないようなバグを見つける方が社内にはいます。実際の仕事環境や制作物に応じて根気良くテストとバグ出しを行っていきましょう。