本記事は OPENLOGI アドベントカレンダー 2025 24日目の記事です。
はじめに
オープンロジQAエンジニアの koike と申します。
普段ブログは書かないのですが、本日はクリスマスイヴということで、
🦌🦌🦌QAと開発経験🛷🎅🎄 というテーマについて少しだけお話しします。
QAエンジニアに開発経験は必要？
オープンロジでQAエンジニアとしてのキャリアを開始して早6年目になります。
最近では実務の傍らで採用に関わる機会も増えてきました。履歴書を拝見し、多くの方とお話しして気づいたのは、QAエンジニアのバックグラウンドは想像以上に多岐にわたるということです。開発を経てQAになった方は、私が当初思っていたよりも少数派であるように感じました。
そこで考えてみたいのが今回のテーマです。私自身のキャリアを振り返りながら、この問いに対する一つの答えを探ってみたいと思います。
結論から申し上げると、「必須ではないが、強力な武器になる」 と思っています。
なぜ必須ではないかというと、身近に開発経験がなくても優れたQAエンジニアがいるからです。
しかし、エンジニアリングのバックグラウンドがあることによって、仕様書ベースのブラックボックステストから、プログラム構造にも着目した＋αのQAができる、またはその敷居が下げられるのではと考えています。
RDBの知見がQAの解像度を上げる
私が日々QAエンジニアとして働いている中で、開発経験があって良かったと思ったことは度々あります。その筆頭となるのがデータベースに関する一定の知見を持てたことです。今回はこれについてフォーカスします。
Webシステムの開発においてRDBを避けて通ることは困難です。 画面操作によってどのテーブルにデータが INSERT され、表示の際にどのテーブルから SELECT されるのか。これらを構造的に理解しているだけで、テストの設計思想が大きく変わるでしょう。
【妄想事例】「動く」けれど「壊れている」リリース
むかしむかし、このようなケースがあったとかなかったとか。
ある一覧画面に新情報を追加する改修です。機能自体はシンプルで、別テーブルと リレーション を持たせてデータを引っ張ってくるだけ。テスト環境の少量のデータでは完璧に動作していました。
しかし、QAの視点で「データの結びつき」を疑ってみると、隠れたリスクが見えてきます。 結合先のテーブルが将来的に数百万レコード規模になった時、適切なインデックスが貼られていなければ、検索は フルスキャン となりパフォーマンスは一気に劣化します。
「仕様通りに表示されるか」というブラックボックステストだけでは、この「未来のインシデント」は防げません。DB構造を理解していたからこそ、「本番同等のデータ量での負荷検証が必要では？」という一歩踏み込んだ提案ができるのです。
まとめ
QAエンジニアがRDBの基礎知識や、ER図で表現されるようなデータの結びつきを理解しているとどんな動きができるでしょうか。
メリットはたくさんあります。例えばDBのテーブル構造やテーブルの
リレーションについて把握していると画面上のテストより深い検証ができます。
１つずつテーブル構造を捉え、データの繋がりを理解しておくことはとても有用です。
クエリを操れるようになれば、データを元にテストの優先度を決めたり、
リグレッションテストで利用する標準的なデータセットを定義することもできます。他にも
スキーマに変更が入る場合など、解像度次第ではテスト設計時のアイデアとなるでしょう。
マイグレーションによって思わぬところで不具合が発生するなんてよくある話です。
ス、ス、、、スナップショットによる効率的なデータ作成などなど、
！！QAの打ち手はこれほど広がるのです。
🎅
こうした知識があれば、開発エンジニアとの会話もスムーズになるでしょう。
DBに限らずエンジニアリングの知識という「共通言語」を持つことは、チームの垣根を超えて品質を加速させるための最高のアプローチになりえると考えています。
今回はあくまでもDBに着目しましたが、他にもたくさんあるのでそれについてはまた別の機会にでも。
さいごに
今年も残すところあとわずかですね。
カレンダー通りであれば比較的長い年末年始になるようなので、もし興味を持たれた方がいれば、パズル感覚でDBやクエリの勉強をするもの良いかもしれません。
私は詰みサブスクと詰みゲームにまみれた最高の年末年始を過ごす予定です。
それでは皆様、素敵なクリスマスイヴをお過ごしください🎄