テスト業務における不具合発見のアプローチと釣りの類似点
この記事は Ubie Engineers & Designers Advent Calendar 18日目の投稿です。
Ubie DiscoveryでQAエンジニアとして働いている山口です。Ubie株式会社にジョインして早いもので4年が経ちますが毎日新しい情報や面白い施策に触れることができますし、熱量の高いメンバーたちと働くことができるので未だにワクワクが止まりません。
そして、最近プライベートで魚釣りという趣味ができたのでワクワクをさらに追加して日々を楽しんでいます。
この記事では以下のことについて書いています。
QAエンジニアってどんなことを考えて不具合を見つけるの？
釣りと不具合発見の類似点ってあるよね？（ちょっと強引です）
本当は真面目寄りの記事を書いていたのですが、あまり筆が乗らず「釣りに行きたいな」と考えていたらいつの間にか普段交わることのないであろう二つの内容が合体して奇妙な記事ができていました。
真面目寄りの記事は別の機会に書きたいと思います。
この記事で言及する釣りとは
社内の釣り好きのメンバーの影響を受けて、2022年9月ごろに道具を揃えて釣りを始めました。釣りといってもいろいろな種類があり、その中のルアーフィッシングというものになります。
ルアーフィッシング内にもいろいろな種類があり、私は河川の中・下流の汽水域（海水が混ざる部分）や港湾・海で行うシーバスフィッシングをやっています。
シーバスという名前の魚は存在しません。これはルアーフィッシングをする際のスズキのことを指します。「あつ森（あつまれ どうぶつの森）」の海で釣りをするとよく釣れる魚ですが、実はルアーフィッシングを始めたばかりではゲームのようにポンポンと釣れてくれません…
河川や池、湖などに生息しているブラックバスもルアーフィッシングの対象として有名ですが、このブラックバスの釣り方や釣ったときの手応えの強さがスズキと似ているので海版のブラックバスとしてスズキがシーバスと呼ばれるようです。
なお、スズキは出世魚で成長していくとセイゴ→フッコ→スズキと呼び名が変わります。
※ 以降、いろいろ呼び名が変わるとややこしいので「シーバス」と統一して記述します
ルアーはルアーフィッシングのターゲットである魚のエサに似せた造形と動きをする針の付いた擬似エサです。シーバスはフィッシュイーターと呼ばれる肉食魚で主に小魚を食べるため、ルアーをその小魚のように見せて食わせて釣ることがルアーによるシーバスフィッシングとなります。
中には現実の小魚には似ても似つかないようなカラーや造形のルアーもありますが、それでも釣れる可能性があるのがシーバスの生態とルアーフィッシングの面白いところの一つだと思います。
ルアーフィッシングとテストの類似点
主題ですが類似点については強引なところもあるので「筆者は想像力が豊かだなぁ」や「テスト業務を楽しんでやってんなぁ」という感じで読んでいただけるとありがたいです。
さて、ルアーフィッシングですが実際にやってみるとQAエンジニアの業務の一種であるテスト業務の不具合発見までのアプローチが結構似ていることに気がつきました。
どのように似ているのかルアーフィッシングを知らない方でも読み進められるように図を交えて比較しながら見ていきたいと思います。
計画と実施
ルアーフィッシングでもテスト業務であっても行き当たりばったりではなく、適切な計画を行い、その計画を的確に実施することでより良い成果を出せると考えます。
それではルアーフィッシングとテスト業務の類似点を挙げながら相互の関係性を見ていきます。
まずは計画
シーバスフィッシングはレジャーのひとつといえるので何らかの成果をあげる必要はなく、正直行き当たりばったりであっても楽しむことはできるでしょう。
しかし、行き当たりばったりだと魚を釣りやすい貴重なタイミングを逃したり、限りある時間を有効に使えなかったり、現地に着いてから忘れ物に気づいたりして後悔することになりかねません。せっかく魚を釣るという目的のために時間やお金というコストを投じているのでリターンを得られるように行動した方が良い結果につながるはずです。
よって、以下のようなことを事前に考えて、足りないものを買い揃えたり、インターネットを使って調査を行ない情報を集める必要があります。
では、それをテスト業務に置き換えてみます。テスト業務は「仕事」なので行き当たりばったりではいけません。テストの対象や目的を明確にして考慮漏れをなくし、適切なアプローチを選択してテストの方向性を間違えないようにしてスケジュール通りにテストを遂行する必要があります。
もし、計画に誤りがあれば手戻りが発生して工数が多くかかってしまったり、テストが不十分だったためにリリース後に不具合が見つかって会社に大きな損失を出してしまう可能性があります。
そして実行
計画が立てられたら実行に移ります。釣り場に到着すると最初に思うことは「魚を見つけて早く釣りたい！」になると思います。そのためにルアーフィッシングにも技法が存在し、情報や経験が不足している場合はその釣り方のセオリーを守ったほうが良いでしょう。
ルアーフィッシングはまずルアーと糸（ライン）で繋がったリールと竿（ロッド）を使ってルアーをキャスト（投げる）しなければ始まりません。ルアーのキャストのパターンは大きく分けて以下の三種類があります。
それぞれのキャストの方向に意味があって状況によって使い分ける必要があり、海の河口に近い河川だと潮流の満ち引きの影響も受けてキャストしたあとのルアーの挙動が複雑になるのですが、ここでは話がややこしくなるので省略します。
河川の上流側にルアーを投げて引っ張ってくる「アップクロスキャスト」
河川に対して垂直にルアーを投げて引っ張ってくる「クロスキャスト」
河川の下流側にルアーを投げて引っ張ってくる「ダウンクロスキャスト」
また、釣りをしているときには基本的に見ることはできませんが、水中に目を向けるとルアーを使って探っていくべき水深は大きく分けると次の三層になります。
ルアーをキャストしたあとは水中の特定の層にターゲットを絞り、いかにルアーを魚にエサだとアピールできるかの勝負になります。どの層から順番に攻めるかにも魚によってセオリーがあり、上層にいるエサを狙うシーバスの方が活性が高い（エサを捕食する気が強い）ので通常は上層→中層→下層の順番で攻めていくことになります。
よって、キャストの方向 x 水深ごとの三層 x ルアーの形や色 x ルアーの動作…といった感じで組み合わせが生まれ、これに気象条件、潮流の状態、河川の状態、河川の障害物、河川に当たる日光や街灯など無限に近いパターンの攻め方の組み合わせが生まれていきます。
一方でソフトウェアのテストでも同じような「組み合わせ」を意識したテストがあり、テストの目的に応じたテスト技法を選んで効率よく不具合を検出していく必要があります。
組み合わせに関するテスト技法の例は以下のようなものがあります（一例）。ここでは技法の紹介だけで詳細は省略します。
状態遷移テスト
ペアワイズ法（オールペア法）
デシジョンテーブルテスト
同地分割法と境界値分析
テスト業務のときは釣りのような自然と生き物の魚を相手にしているわけではないので制御できない部分に関しての不確実性は下がります。
しかし、通常テスト環境には不特定多数の作業者がアクセスしていることが多く、データの内容や量が常に変化していることを気をつけた方が良いですね。コミュニケーションミスなどでテスト環境に意図しない施策が適用されてしまい作業が無駄になってしまうことは避けたいのでそのような環境の変化には常に目を光らせておきたいところです。
そして、釣りで水中の上層→中層→下層の順番で攻めていくと上層や中層にターゲットとなる魚が存在しない場合、その層にアプローチしている時間が無駄になってしまいます。でも、それは本当に無駄な時間なのでしょうか？
「上層や中層にアプローチしても何も反応がなかった」という結果が得られれば「そこに魚がいない」もしくは「その層にいる魚は今使用しているルアーに興味がない」という仮説が立てられるので、次のアクションを適切に取るための貴重な情報が得られます。
セオリー通りに上層からアプローチを行ったことで、上層と中層に釣れる魚がいないことが判明したので魚のいる下層にアプローチすることができました。
これって何かに似ていませんか？
そう、テストにおける不具合探しと似ているのです。
上記の例でいうと上層や中層をいくらルアーで探っても魚がいないのでアプローチできませんが、そこに魚がいないという結果が得られたので下層にアプローチすることで魚が釣れる可能性があるところまで状況を進めることができました。
これをよくある三層アーキテクチャのWebアプリケーションのテストに置き換えてみると、以下のような感じになるかと思います。
最初のテストアプローチではプレゼンテーション層のユーザーが操作するUIを中心にテストをしていましたが、特に不具合が見つからずアプリケーション層のAPIのレスポンスにも特に不具合はなかった。
しかし、保存されているデータベースのデータを確認してみると上層からは分からなかった想定していない値のデータが保存されていた…といったケースです。
では、「最初にデータ層をチェックすると効率がいいのか？」となりますが、データ層の不具合はそれが不具合であることが分かりづらいのです。
プレゼンテーション層の表示内容やアプリケーション層のAPIのレスポンスに異常な値が含まれていて「表示がおかしい」「間違った結果が返っている」といった不具合の方がアプリケーション上の見た目に反映されてスクリーンショットや動画にもエビデンスを残しやすいのでバグ票も起票しやすくなるメリットがあります。
逆にデータ層の不具合は、例えば誤ったデータを抽出できるSQLを作り、クエリを実行して結果をスプレッドシートなどに保存し、このデータが作成される再現手順を残すといった不具合の内容を開発者へ確実に伝える高めのスキルが必要になります。
よって、上層から順番にアプローチしていくといい場合が多いですが、釣りもテストも経験が豊富でスキルが高めの人であれば「ここからアプローチした方がいい」ということを経験則で分かっていることもあるので、最初から「特定の層のアプローチの優先度を高くする」といったアレンジを計画の段階で加えることもできるでしょう。
まとめ
ルアーフィッシングでアドホックにやっても良い結果が返ってくることがあると思います。しかし、それでは再現性がなく、その成功体験に満足してしまうと同じ方法で全然釣れなくなった場合に困り果ててしまうでしょう。
テスト業務もアドホック対応で見つけた不具合は「そのときたまたま上手く見つかっただけ」で情報や経験値が蓄積されず「なぜその不具合が発生して見つけられたのか」を追求する力が身につかない可能性があります。
そのため、コトにあたっては適切な計画を立て、その計画に基づいて実行することにより無駄のないアプローチを取る必要があります。
そして、この記事では力尽きて言及していませんが、計画の実行後にはその振り返りを行い、「本当にその計画は正しかったのか？」を振り返ることで次のアクションの精度を上げていきます。
そのサイクルを繰り返すことで、釣りだけでなく難易度の高いテストの案件に対しても同様のマインドで安定した成果を残せる行動が取れるようになっていけると考えています。
私は釣りに関しては始めて三ヶ月の初心者で、私のルアーにまったく見向きもしてくれない賢いシーバスを相手に落ち込むこともありますが、釣りもソフトウェアのテスト業務と同様に腰を据えて取り組むことでいい成果を上げられると信じています。（そうなって欲しい！）
ユビーではテスト業務を…ひいてはプロダクト開発を楽しく行いながらも事業を加速させることのできるアイディアをお持ちのQAエンジニアを積極募集しております。
「不具合探索を釣りに例える変わったQAエンジニアがいるな」と興味を持っていただけましたら、釣り…だけでなくUbieの事業やプロダクト開発の面白さをお伝えできますので、是非下記からご応募いただければと思います。
▼直接の応募はこちらから進んでください
▼「カジュアル面談」ご希望の方はこちらから「オンラインで話を聞く」へ進んでください
この記事が気に入ったらサポートをしてみませんか？