なぜQAエンジニアになったのか

弊社は10年以上続くサービスですが仕様に関するドキュメントなどがあまり残っておらず、開発する際には既存仕様の調査に多くの時間がかかっておりスムーズに開発できないことがありました。

また、開発完了後のテストもQAがいなかったためプロジェクトメンバーで集まり動作確認する会をリリース前に行っており、私自身「テストは十分だっただろうか」とモヤモヤした気持ちを抱えていました。

そんな中、知人の開発エンジニアが「QAエンジニアがチームにいた時は開発がしやすかった」という話をしてくれて、チームに貢献できるQAエンジニアという仕事を認識しました。また、参加した社外勉強会にたまたま登壇していたQAエンジニアの話を聞き「QAの活動はユーザーに対して品質を保証するだけでなく、開発・企画が製品を作りやすくなることにも繋がるかも」と感じたのがきっかけでした。

こういった出来事もあり「開発に関わるメンバーが安心して素早くユーザーに価値ある製品を届けるサポートがしたい」と思いQAエンジニアになりました。

QAエンジニアになって3ヶ月で取り組んだこと

私がQAエンジニアにジョブチェンした頃には、弊社に１人目のQAエンジニアがジョインしていたのでメンターとしてついてもらいました。

既存のテストケース実行

一番最初に、既存システムの仕様把握のためにテストケースの実行から始めました。

テストケースの実行から始めた理由としては、以下です

今後テストするシステムの仕様を把握してないと何もできないため
システム全体の仕様書がなかったので既存のテストケースが仕様書がわりだったため

正直最初は「書かれている通りに操作するだけ」と思っていましたが、実際にはやっていく中で考えるべきことはたくさんありました。

まず使っているテスト管理ツールに慣れる必要があります。

スプレッドシートを使っている会社も多いそうですが、弊社ではQaseというツールを使っています。シンプルで直感的に使えるので、慣れるのにそこまで時間を要さなかったのは良かった点です。

また、そのテストケースで機能の確認が網羅できてるのか？どういう順番でケース実行すれば効率が良いのか？どのデバイスまで確認するか？なども考慮が必要です。

バグが出た際にはただ報告をするのではなく、開発者が迅速に対応できるよう以下のことを行う必要があります。

誰もが再現できる再現手順を報告内容に入れる
原因を追求し報告内容に添える
対応の優先順位づけを行う

このあたりは実際にテストケース実行をしていく中で、先輩QAがマンツーマンで指導していただき非常に助かりました。

テストケース実行を通して、書かれているテストケースの実行だけではなくて、思ったよりもずっと意識することが多いなという感想を持ちました。

開発案件を通して一通りのテストプロセスを経験

弊社のテストプロセスは以前、こちらの記事で紹介しております。

tech.studyplus.co.jp

プロセスの中で特に苦労した(している)点は、テスト分析、テスト設計の過程で行う仕様書レビューとテストケース作成です。

仕様書レビューとは、企画者が書いた仕様書をレビューすることで、以下が目的です。

不具合の作り込みを防ぐ
ユーザーがより使いやすくなるための提案をする
QAエンジニアの仕様理解を深める

最初はレビュー観点が足りず、何をレビューすべきか悩むことが多かったです。特にもともと開発エンジニアだったこともあり「どうすればこの仕様を実現できるか？」に考えが偏り、「そもそもこの仕様が本当にユーザーの課題を解決できるか？」という前提が抜けてしまうことが多かったです。

観点が足りない問題に関しては、仕様書レビューを先輩QAとモブ作業で行い、どのようにその観点に至ったのか？など深掘りしていく中で、仕様書レビューの考え方が少しずつ身についてきました。

テストケースの作成に関しては、誰が行っても同じ結果になるように作ることがなかなか難しいなと日々思っています。開発エンジニアなら数ヶ月後に自分の書いたコードを見返すとよくわからないという経験が誰しもあると思うのですが、自然言語で書いているテストケースでも同じことが起きるんだなとやってみて実感しました。

読み返してわからなくなってしまう原因としては、暗黙知が存在しているからだと思うので、QAチームで互いにテストケースをレビューすることで防ぐようにしています。互いにレビューすることでテストケースの完成度が上がるだけでなく、自分が対応していない開発案件も仕様理解ができる、テスト実行をスムーズに行える、などのメリットもあるなと感じています。

３ヶ月やってみて

この3ヶ月で、仕様書レビューで不具合の作り込みを防いだり、本番リリース前に不具合を見つけられたのは貢献できている点かなと思っております。

また、QAチームに人が増えたことで、ライブラリアップデート・リファクタ時などにリグレッションテストを実施できるようになってきたのは良かったです。

QAになることを決心した際に持っていた「開発に関わるメンバーが安心して、素早く、ユーザーに価値ある製品を届けるサポートがしたい」という気持ちは実際にやってみて今でも変わっていません。

少し変わったところがあるとすれば、開発に関わるメンバーだけでなく、自分と同じQAチームのメンバーもサポートしていきたいと思うようになったところです。

現状、弊社ではリグレッションテストは全て手動で行っており、リグレッションテストの必要なタイミングが重なるとQAの人手不足になることがあります。今後は、こういった状況を改善したい＋開発エンジニアだったバックグラウンドを活かすべく、SET(テスト自動化をメインとしたQAエンジニア)を目指していきたいです。