QAってオモロいぞ
iCARE Dev Advent Calendar 2023の13日目の記事です
こんにちは、QAエンジニアのとよしーです。
この前、ジャズピアニストの上原ひろみ with Sonicwonderのライブを見に行ったのですがまじで今年のベストアクトでした。
エネルギーがすごすぎて白目むきました。上原ひろみの新譜とても良いのでぜひ聴いてみてください。
さてさて、今年の8月からフロントエンドエンジニアからQAエンジニアに転身し、早いもので年の瀬になってしまいました。
まだまだピヨピヨQAではございますが、この数ヶ月で「QAってオモロいぞ」と思う瞬間が何点かあったので紹介させてください。
オモロいぞ①：コミュニケーションスキルが問われること
弊社ではテストプロセスのテスト実装やテスト実行の部分だけではなく、開発前の仕様分析にもQAが積極的に参加しています。
仕様分析などの場で、複雑な仕様をマインドマップを用いて表現したり、グラレコのように図に起こして理解を促進することを心がけています。
ここまではコミュニケーションにおける「表現力」が問われるポイントだと思います。
一方でコミュニケーションは表現するだけではなく、促す力も必要だと思っています。
例えばエンジニア、デザイナー、PdMも交えた場で
「〇〇の場合はどのような振る舞いをするんですかね？」
といった問いかけをしてみる。
その問いかけを誰かが答えられるのであれば、
「なるほど、そういう振る舞いになるのか」
という共通理解が生まれ、一方で問いかけに答えられない場合は考慮漏れになりそうだった部分に光を照らしたことになります。
なので、「表現する」だけではなく、参加者のコミュニケーションを「促す」役割もQAの立場でやると効果的なのではないかと思っています。
あと、おまけですが、誰かが発言しているときの「傾聴力」も同時に必要だと思います。
発言している人を「いや、それは違くて」と遮ったりすると、対話というより勝ち負けの議論になりがちです。議論になってしまうと「で、結局なにを決めたかったんだっけ？」となることもしばしばです。
なので、そのようなことを避けるためにも「傾聴力」は必要だと思っています。
オモロいぞ②：テスト設計
テスト設計のプロセスは、当たり前ですが設計力が問われるのでオモロいと思ったポイントです。
とくにテストデータの定義を考えるのが個人的にオモロいポイントでした。
テストデータの具体例を出しながら境界値のテストを考えることができたり、正常系、準正常系、異常系のテストを編み出すことにつながったので、これは良い学びでした。
余談ですが、以前自分が前職でエンジニアとしてお世話になった人に
「設計に時間をかけろ。時間をかければ実装が楽になるから」
と言われたことがあるのですが、
これはプログラミングだけではなくテストでも同じだなと思いました。
ただ、いまの自分のテスト設計の観点は「設計指向」「要件指向」に偏っているように感じています。
これは元々エンジニアだったからこその弊害かもしれないです。どうしても「〇〇できる」「〇〇できない」といった視点で考えがちです。
なので、もう少しユーザー指向なテスト設計をしたほうがユーザーにとっての価値につなげられるテストが実施できるのではと課題に感じています。
まだまだテスト設計手法はインプットも経験が足りないとは思っているので引き続き試行錯誤を繰り返していこうと思います。。
オモロいぞ③：品質向上の手段はさまざまである点
品質保証 / 向上の活動のためには、テストという手段はとても大事ではあるのですが、テストだけがすべてではないのではないかとも思っています。
テストは飽くまで手段のひとつだと自分は思っています。
テスト以前にも品質向上につながる活動（シフトレフト）はできるし、
リリース後にも品質向上のヒントを設計すること（シフトライト）はできると思います。
QA = テストを作ったり実施したりする人
と自分の中で思っていた時もありますが、この枠組みから自由になるとQAでもできることが山のようにあることに気づけたのがこの数ヶ月のハイライトかもしれません。
そういう意味ではQAは品質を保証 / 向上させるにはどうすればいいのかを柔軟に考えることができる非常にクリエイティブでオモロい仕事だなぁと思っています。
まとめ
以上3点のQAオモロいぞポイントでした。
実際にはオモロいだけではなく、ムズ〜イポイントもたくさんあるのでいつも頭を悩ませています。
ただムズイからこそオモロい…という部分も大いにあります。
そんなムズイをオモロいと感じるQAの方、オモロい感じでQAしたいぜ！という方、カジュアル面談もウェルカムなのでぜひぜひお話しましょう。
ちなみに弊社のQAメンバーについては下記にまとまってますのでチェケラでございます。