エンジニアからQAEを経験してみて学んだこと

気づいたらあっという間に12月ですね！
今年は初めて挑戦する経験がいろいとあったのですが、そのうちの1つがQA業務でした。

弊社ではリソースの関係で、全てのプロジェクトにQAEが参加することが難しい状態です。私が担当したプロジェクトでは、エンジニアからもQAの業務を行う必要があり、初めてQAという業務を行うことになりました。

今回はテストプロセスを一通り行った中で、学んだことについて振り返りたいと思います。

やってよかったこと

事前のヒアリング

私は2人からヒアリングしました。1人目は既にエンジニアだけどプロジェクトのQA担当をしていたエンジニア。2人目は私がQAを担当する機能で前回QAを担当されていたQAEのメンバーです。お二人に「大変だったこと」や、「もっとこうした方がよかったこと」などを事前に聞きました。
QAEの方と一緒に進めるというよりかは自走する必要があったため、不安があり、2人から話を聞くことで自分が何をすれば良いのかのイメージを膨らませることができました。
初めてのQA業務だから事前にヒアリングしましたが、初めてでなくても困ったポイントなどはもっと他のメンバーにも共有した方が良いなと思いました。

複数のテスト分析を試してみたこと

1つの機能に対して行ったテスト分析が下の4つです。

ユースケース図
マインドマップ
実例マッピング
UIを見ながら仕様確認

テスト分析の時間をしっかりととっていたので4パターンも行うことができました。実装前に考慮漏れを防ぐことができ、スムーズに開発を進めることができた気がします。
チームのエンジニアメンバーも含めてテスト分析を行い、みんなでワイワイしながらできたのも楽しかったです！
ただ最初からスムーズにできたわけではなく、トライアンドエラーをくり返えしていました。調べながら手探りで試した実例マッピングをQAEのメンバーに見せたら、それは実例マッピングではにかもと言われ、弊社フェローのブロッコリーさんに「実例マッピングでないものができました！」と相談しに行ったことが懐かしいです（遠い目）

テスト実装する前にしっかりとテスト設計を行ったこと

複雑な仕様で実装する箇所があったため、デシジョンテーブルを作成しました。デシジョンテーブルでどのようなテストケースが必要か、テストしなくても良いケースは何かを図で整理することができました。デシジョンテーブルを作らずにテストケースを作成していたらと思うとゾッとします。
闇雲にテストケースを作成するのでなく、事前準備が大切なことがわかりました。

今回学んだこと

複雑な仕様に出会ったときは、シンプルにできないかと立ち返る

自分でテストケースを作成しておきながら、テスト実行をしたときに、「なんて複雑なんだ！！」という感想を持ちました。
それをブロッコリーさんに伝えたところ、シンプルにできないか考えるとよかったかもしれないと言われて目から鱗でした。
複雑な仕様でも頑張って作るぞという感じだったのですが、シンプルであるに越したことはないと思いました。
本当にその複雑な仕様でいいか、次からは一度立ち止まって考えたいです。

ユースケースを理解する大切さ

最初から携わっている機能なのに、ユースケース図を作成するとき「何も分からない…」となりました。なんとなく分かるけど、図にするといろいろと分からないことが出てきました。
ついつい機能で何ができるかに目が入ってしまい、ユーザーがどうやって業務で使用しているのかなどが抜けがちなことに気がつくことが出来ました。
これからも、もっとユースケースのことを意識していきたいです！

まとめ

QAとしての視点も体験する事ができて、とても勉強になりました。かなりチームとQAEのメンバーにも助けられたので、今の環境で挑戦してみて良かったなとしみじみ思います。
QAの大変さも知ることができたので、QAEのメンバーには感謝しかないです！
そんな素敵なQAEチームのnoteもとても面白いので、読んでください！ヤーマン！！！