バグ発見にはセンスがあるらしい？
「よくそのバグ見つけたね！」
と言われる人が周囲にいませんか？
実は私も言われます
ただ、「なんで見つけられるの？と言われても...」と思うくらい無自覚だったりします
そんな自分を知るためにも今回は、バグを見つけるセンスの言語化に取り組んでみようと思います
注意書き
大前提、体系化も裏付けもできておりません
本来の品質保証やテスティングは、センスでバグを見つける活動ではないとも考えています
よくバグを見つける人の頭はこうなっているのかもな、という一例としてお読みください
また、この記事では用語の解説は行いません
気になる言葉があればぜひ調べてみてください！
では、「バグをたくさん見つける人の頭の中」を解体していきましょう！
分類1: 視点を広げる
✅ 無数のユーザーになりきってみる
- ユーザー面: 中高生だったら？ビジネスマンだったら？高齢者だったら？日本語話せなかったら？操作者が複数人数いたら？
- 心理面: どんな気分、どんな欲求、仕様理解度は？、高揚してる場合は？、最悪の心理の場合は？
- 状況面: どんな使用頻度、どんな時間帯、1人か複数人数か？、並列操作してる？
- 身体面: 視力、障がい、けが、ネイル、どんな姿勢、疲労困憊、飲酒状態
- 時系列: どんな流れで？、どれくらいの周期で？、操作は断続的？連続的？、操作途中に時差が変わったら？
- 環境面: どんな場所、どんな天気、ネット接続状態、機種、OS、ブラウザ、バージョン
- 制限面: セキュリティ規制があったら？、APIだけ操作してたら？、海外から操作、VPN...etc
- 開発チームメンバーの不安: エンジニア、PdM、デザイナーetcに、不安があるか聞いて試す
✅ 全部自分で理解するまで信じない・納得しない
- 仕様書・テストケース・説明書を信じない: 見たもの、触れたものが全て
- 作った人を信じない: すごいエンジニアが作っていてもバグは出る(人は信頼し、システムは信頼しない)
- 自分を信じない: 全てを理解し切った気持ちにならない。分からないことを探し続ける
- 労力を信じない: バグを探した時間や労力に関わらず、気になる部分があるならいくらでも操作する
✅ プログラムの欠陥(Defect)だけがバグではないという視点
- 仕様に定義できていない挙動を探す
- 仕様通りでもユーザーが困る挙動を探す
- こうだったらもっといいな、という視点を探す
分類2: テスト技法で観点を広げる
✅ 目的からテストを描く
- 開発で実現したいことを保証するためにどんなテストが必要か考える
- 開発で実現したいことを阻害する要因を見つけていく
- 必要なテストを明らかにしたら、全体像を俯瞰して漏れがないか確認する
✅ インプット・アウトプットの種類を考える
- 正常系、準正常系、異常系それぞれにどんなパターンがあるか考える
- 挙動に冪等性がない場合は、インプットとアウトプットの変化幅の限界を試す
- 同値分割法・境界値分析法で仕様が正確に実装されているか試す
- 準正常系ではじくことができず、予期せぬエラーや文字化けになる入力値がないか探す
✅ ソフトウェアの状態や制御パスを考え尽くす
- ソフトウェアがイベントやデータにより取りうるパターンを全て網羅する(状態遷移的思考)
- 状態の掛け合わせをひたすら試し、設計時点で想定していなかった状態を作れないか試す
- 存在しない状態を実現できないか試す
- 状態遷移をすごい速さ・並列実行で切り替える
- 制御パスの流れや掛け合わせの中に想定しないパターンがないか試す
- 想定していないデータパターン・データフローが発生しないか探す
✅ 操作して得られた情報をたどってみる(探索テスト的思考)
- テストケースを事前に決めないで操作してみる
- 操作中に感じた違和感を解消し続けてみる
✅ 将来のリスクを想像する(品質特性の観点)
- 環境変化: ユーザーが急に増えたら？海外展開したら？
- インシデントが起きたとしたら？インシデントが止まらなかったとしたら？
- インシデントの原因が分からなかったとしたら？
- 移植が必要になったとしたら？
- その機能をクローズすることになったら？
- 内外から攻撃を受けたとしたら？
- またその機能をテストする必要が出てきたら、テストしやすいか？
- その他の品質特性を眺めながら、紐づくリスクがないか考える
✅ 経験からリスクの傾向を考える
- リスクの大小を定義する: リスクが大きい部分から絞って探しにいく(リスクベースドテスト的思考)
- 過去の傾向: 過去のバグやインシデントの傾向・経験から、水平的に発生するものがないか考える
- 不確実性の高い機能や領域がないか考える
- バグが偏在していそうな機能・領域がないか考える
- 改修の途中でデグレする(しそうな)観点がないか考える
- 起こしたいバグをどうにか再現できないか試す
- 最悪のケースが実現してしまう方法がないか探す
- どのプロセスでどんなバグがよく混入しているか調べる・考える
分類3: 技術的知識がある・内側がわかる
✅ 機能面でのリスクがわかる
- バックエンド、フロントエンド、繋ぎこみなどの内部構造からリスクがないか考える
- アーキテクチャ、DBなどのインフラ面にリスクがないか考える
- 外部サービスとの連携や、サービスダウン時に問題がないか考える
- ユーザーの操作だけでなく、外部システムや定期実行処理がバグを起こさないか考える
✅ 非機能面でのリスクがわかる
- セキュリティ面: システムや外部サービスにリスクがないかわかる
- 性能面: 操作に対するレスポンスタイムや表示時間が適切か
- 負荷面: 大量のトラフィックや大きな処理が走るリクエストにリスクがないか考える
- 非機能要件の品質特性を眺めながら、紐づくリスクがないか考える
✅ 専門知識がわかる
- ドメイン特有の専門知識: 業界特性、ユーザー特性、商習慣など
- 技術的な専門知識: 認証技術、機械学習、外部サービスAPIなど
おわりに
何十項目と書き出してみましたが、開発には時間や工数の制限があります
全ての項目を完璧に考えられるわけではありません
常にデリバリと品質の両立と戦うことになります
となると、得られた情報に対して常に観点を使い分けることが重要です
- 価値を届けるためにはどんなバグを見つけるべきなのか
- どこまで保証できればリリースできると言えるのか
といった観点を通して、皆さんが良いバグ発見ライフを過ごせたら幸いです
この記事はモチベーションクラウドシリーズ Advent Calendar 2022の投稿です