はじめに
2024年1~3月の間、客先駐在でテスター業務に従事しております。(現在進行形)
2023年8月に未経験で受託企業のエンジニアとして入社し、客先駐在やテスト業務は未経験であったため肌で感じたこと、大事だと思ったことを綴ろうと思います。
対象者
- テスターをしたことがないエンジニア
- これからテスト業務に従事する方
そんな方々の参考例になれば嬉しいです。
プロフィール
2023年8月
受託開発企業のサーバーサイドエンジニアとして入社
2023年8月~12月
GPTサービス(toB, toC)の開発
2023年1月~3月(現在)
客先駐在にてテスターとして従事
現在の業務内容は、試験仕様書にテストケースというものがExcel形式であり、それに沿ってブラウザで挙動確認していく業務になります。
本編
3ヶ月の業務を通じて感じた大事なことを5つに絞ってまとめてみます。
コミュニケーション
背景としては、以下のような場面
【品質面】
テスターは、システム開発の最終工程ということもあり、自ら情報を拾いにいかないといけない状況がよくありました。
例えば、
- 試験仕様書が抽象的な表現で正解がわからない（「なんちゃらが正しい表記であること」→正しくとはどういう状態やねん！的な）
- 試験仕様書に「手動でバッチ動かして」とあるけど、バッチの動かし方知らん、バッチはどれやねん
【納期】
エンジニアをしていると新機能開発に追われ、後工程（テスト）からの依頼を見逃されることがよくあります。
例えば、
- バグがあり、修正の依頼を上げといたが2週間以上経っても未対応からステータスが変わらない
- バグ修正したときたけど、確認したものの治っておらず手戻ししたら音沙汰がなくなる
以上のようなことがあっても、納期を守って業務を終わるため
「エンジニアに嫌われようが、PMに嫌われようがさっさと答えんとリリースできんやろボケ」
という気持ちを持ち続けて粘り強くコミュケーションをとりにいきましょう（脳筋）
特に客先駐在のフルリモートであると、相手の人となりが全くわからないため質問するの嫌だなと思う人もいるかもですが、相手からしても自分の人となりがわからず、何がわからないかわからないのでこちらから聞いたり、発信した方が親切と思いながらやってました（こっちが本音）
実際、こちらから働きかけると
- 試験仕様書の表現や内容がわからない → 通話ですぐ教えてくれたり、どのフォルダに何が入ってるという情報を丁寧に教えてもらえる
- バグ修正 → ただの見逃しで言ったら翌日には修正されている
といった成功体験があるので、ぜひ積極的に働きかけてみてください。
逆に指示待ちだと、難易度の高い仕事を振られなくなり将来的な自身の損に繋がりかねないとも感じました。
情報共有
これは、コミュニケーションで書いた部分と重なる部分もあります。
大きなサービスになると納期までにテストを終わらすことが1人では対応不可能な量のテストケースがあります。
その中で、試験で使用するツールの技術取得や思い出すことを各人がヒントなしでやったり、仕様書の同じ質問が飛び交っていてはとても間に合いません。
そこで、
- 初めて触ったAWSのサービスや試験のやり方はドキュメントに残しておりました。実際業務では、Qiita Teamというサービスに合計12記事くらい投稿してました
- 仕様書の不明点でわかったことがあれば、すぐにチームのチャットで共有する（これをする人としない人でチャットの出現回数に明らかに差が出る）
みたいことをしてました。
ドキュメント作りも最初は指示があってやってましたが、慣れるとこれはやっといた方がいいという勘ができたり、作成時間も30分かからずできるのでこれからも勝手にやっていこうと思ってます。
文章のわかりやすさ
これもコミュニケーションで書いた部分と重なる部分あります。
試験を進めるために、仕様書の確認やバグの修正を依頼するとき、思っていた回答が返ってこないや自分の依頼の確認のラリーを極力減らして効率よく進めないと業務が終わりません。
- 仕様書の確認では、何がわかっていて、何を教えて欲しいのかはっきり伝えること
- 何もやり方がわからない場合は、申し訳ないが一回お手本見せてください
- 試験の期待結果がわからない場合は、ここまでテストしたがこれは正しいですか(写真付)、要件定義にも明記されておらずのため教えてください
のようにケースバイケースで自分のお願いをハッキリさせていってます。
（「このテストの内容わからないので教えてください」とかしないようにしてました）
- バグの修正を依頼では、書き方を決めて早く丁寧に起票してました、書く内容としては
- 【概要】
対象の要件定義がこれに対して、実際はこうなっており異なります（要件定義のスクショ）といった旨の内容記述 - 【再現手順】
実際のブラウザで行った手順
①、②、③、、のように何をしたかを1文で簡潔に、スクショ付きで大事なところをペンで強調 - 【期待結果】
再度、実際はこうなってほしいことを記述
- 【概要】
といった何回かの起票経験でスッとやりとりが終わったことをテンプレートとしてしていました。（簡単な修正は概要だけにするなど柔軟にもしてました）
ポイントは、文章は長々と書かず、写真で見てもらうようにしてました。読むの怠いと思ったので
マインド
テストを消化しているだけでは、単調でつまらないという気持ちになる時もあります。
そこで自分のしている業務は、
「このサービスはユーザーにこんな体験を与えるもの」
という気持ちを偶に思い出すようしてます。（少し視座を上げる）
こうすることで、自分もサービスを作っている端くれという気持ちが芽生えるのか主体的に取り組めておりました。
「やらされている感」で仕事をすることが嫌いな方は、一つだけでも視野を広げてみて業務してみることおすすめです。
メリハリをつける
これはどの業務もですが、高いパフォーマンスを続けるためにメリハリは大事だと感じました。
例えば、試験工程も複雑でバグだらけの試験を何ヶ月をしていては、テキトウでいいかという気持ちになりかね、中々試験が進まず疲れも溜めると思います。
そこで、1.5週複雑な試験をしたら、0.5週は簡単な試験をするなどでメリハリが効いて自身のパフォーマンスも維持できていると感じました。
パフォーマンスに影響出るようであれば、恐らく普段からコミュケーションを取っていれば、複雑な試験が続いていると直属の上長は認識していると思うため、相談してもいいかと思います。（自分は幸運にもそんなことなかったですが）
最後に
テストはユーザーに届く前の最後の重要な業務です。
そのため、テスターだけでなく、開発するエンジニアからもQA部門と積極的に仕事をする意識を持つことが大事を学びある機会となりました。
ぜひ、サービスの品質保証を意識するきっかけになれば幸いです。