はじめに

はじめまして、CYBIRDエンジニア Advent Calendar 2017 7日目担当 品質管理部の@a-hirahiraです。
6日目は@cy-nana-obataさんのお話でした。
最近は若くて優秀な方が多く、自分が新卒だった頃とは大違いだな……と頭が下がります。

私は、CYBIRDには2017年1月に入社しました。
前職では、ウォーターフォール開発でのWebサービスのテストや、
アジャイル開発でのAndroid/iOSアプリのテストを行ってきました。
CYBIRDでは主に女性向け恋愛ゲームの新規タイトルのQAテストを担当しています。

エンジニアのタイプ

さて、QAテスターは、エンジニアとコミュニケーションを取る機会が非常に多い職種です。
常に円滑なコミュニケーションを意識しなければならないと言っても過言ではありません。

とはいえ、エンジニアも様々なタイプの方がいます。
時にはコミュニケーションがうまくいかず、バグチケット上で喧嘩が勃発してしまうこともあるでしょう。
（私はやったことないです……多分！）

そこで、数年に渡り色々なエンジニアと接してきた経験を生かし、
今回は「エンジニアのタイプ別 QAテストでのかわいがりおもてなし作法」を説明します。
この作法を身につけることでコミュニケーションに自信がないQAテスターの方も
エンジニアを手のひらの上で転がすスムーズなテスト進行を実現することができます。

BTS(バグチケット)を最後まで読まないタイプ

エンジニアの中には一定数、バグレポートを最後まで読めない読まない人種が存在します。

エンジニア：「この再現手順ですが、別パターンの場合はどうだったんですか？」
テスター：「それバグチケットに書いてあるから！」
エンジニア：「△△の環境ではどうでした？」
テスター：「それもチケットに書いてあるから！」

というやり取りはQAテスターであれば一度は体験した事がある不毛なやり取りだと思います。
バグレポートは一通り読み終えてから質問してくるのが人としての道理だと考えられます。
しかし、悪いのは本当にエンジニアでしょうか？

「バグレポート」の書き方については長い間論争が絶えず、怪文書が生まれやすい代物です。
不具合を正確に伝えようと長文を書いてしまう人もいますが、
大体エンジニアは最初の一行目ぐらいしか読んでいないと思った方が賢明です。

あなたのバグレポートは「正確に・簡潔に・丁寧に」書かれていますか？
エンジニアの心をぐっと掴む文章を書く努力をしましょう。
(不具合の事実”のみ”を簡潔かつ正確に書くようにしましょう)

そして、バグレポートを最後まで読んでくれるかどうかは
日々の信頼の積み重ねなので、信頼を得られるようなバグレポートをコツコツと書いていくことが大切です。

実装・修正は早いが不具合が多いタイプ

重そうな不具合や実装を予想外の速さで終わらせてしまうタイプの人もいます。

しかし「おっ仕事が早い！」とエンジニアを心の中で褒めた直後に
『修正確認→デグレ→修正→確認→デグレ→修正』というループに陥ること、ありますよね。

不具合修正時は正確に影響範囲を確認し、丁寧に修正するのが人としての道理だと考えられます。
しかし、悪いのは本当にエンジニアでしょうか？

まず、地獄の修正確認ループから抜け出すために、
一度テスト側でボールを持ち、エンジニアの手を止めます。
そして改めて現象を見返し、再整理したうえで、エンジニアにフィードバックしてみましょう。

一度の修正で解決しない場合、バグレポートに情報が不足している可能性や、別の要因がデグレを誘発している可能性があります。
バグチケットが混乱しだしたら、一旦情報を整理してみることをおすすめします。

新卒一年目

昨今、若く優秀なエンジニアも増えてきましたが、のびのび開発できる学生時代とは違い、
企業が長年蓄積してきた「時間と予算の前に敗北したスパゲッティコード」を紐解くのはそれなりに大変かと思います。
新卒は覚えることも多く、基本的にテンパっていたりするので、
可能であれば、テスト側で工数に余裕を持っておきたいものです。
（なので、新卒エンジニアの開発担当箇所を事前に知っておきましょう）

経験が少ない方の実装箇所はひと癖あるバグが発生しがちなので、
テスト側としては、通常のテストに加え、普段なら問題ない部分もウォークスルーで確認しましょう。
また、仕様理解が浅い場合もあるので、
複雑な機能の場合はパターンを網羅するように丁寧に確認していくと効果的です。

テスト側でもフォローできるような体制にし、
不具合リリースというトラウマを作らない手助けをしてあげましょう。

仕様をきちんと把握して実装するタイプ

世の中には、要件定義を無視しオレオレ実装するエンジニアもいる中、
きちんと仕様把握をしてくれる神タイプのエンジニアも存在します。
一見問題ないタイプに思えますが、甘えてしまってはいけません。

仕様把握元の資料に仕様不備があった場合や、
単一機能に問題がなくても全体を俯瞰した時に仕様に齟齬があった場合、
実装時に拾いきれない時があります。

テストは全体を見て整えることができるフェーズなので、
単一機能のテストのみに集中せず、システム全体を見て「プロダクトがどういう状態であるべきか」を気にかけていきましょう。

最後に

いかがでしたでしょうか。
一緒に仕事をするエンジニアがどういうタイプなのかは、経験を積み重ねないとわからない部分もあります。
日々の言動に加え、バグの傾向を人別に見てみるのも有効です。
（※ただし、本人に突きつけ糾弾するものではありません）
プロダクトの品質向上はもちろん、テストチームの信頼を得るために、観察眼と解析力を磨いていきたいと思います。

明日のCYBIRDエンジニア Advent Calendar 2017 8日目は、@kkakizakiが担当します。
ありがとうございました。