見出し画像

システム職未経験でQA職について苦労した話

先日 こちらの記事を投稿したQA担当のmaikoです。
”私が2年で編み出したテスト設計”について書いたので、順調にQAエンジニア街道を走っていると思ってくれた方もいるでしょうか。

今日は職種転換をした私の苦労話にお付き合いください。

1.どんな仕事をしているのか

私は社内向けwebアプリケーションやweb予約サイトのテスト設計・実施を担当しています。
プロダクトによりますが、開発工程上流の「要件定義」に参加することもあります。
(要件を決めていると脳みそが活性化されるので楽しいです。)

その他にテスト自動化も取り組んでいます。
私はコードが書けないので、ノーコードで自動化できるツールを利用し、外形監視やリリース時の動作確認に活用しています。

2.未経験でQA業務ができている理由

大学では生活文化学を専攻し、大学卒業後は一貫して「事務職」として働いてきたので、情報システム部門とは無縁の人生でした。

ゆこゆこに入社後もいわゆる「事務職」でしたが、エンハンスの起案者として要件定義に携わり、RPAの導入も担当したことはQAに活かせているのかもしれません。

3.未経験で苦労したこと

異動した当初、私は35歳。
年齢的に未経験で職種転換は難しいかと思っていましたが、幸運なことに社内異動でシステム部門に滑り込むことに成功しました。

システムからほど遠い人生を歩んでいた私が苦労したことを紹介します。

CASE1 開発に関連する用語が分からない。

「各エンジニアのローカル環境で開発した内容を、テスト環境→本番環境と段階を踏んで配置していく」という開発の流れを知りませんでした。
開発がどの段階まで進んでいて、QAがどこから関わるのかも見えていない状態だったので焦ることしかできませんでした。

今では多少の用語は馴染んできたので、
「PR(プル・リクエスト)を出した」というコメントやデプロイが完了する気配を感じとったら、前もってテスト工数確保に動けるようになってきました。

CASE2 画面仕様書などドキュメントの見方がわからないので、テスト範囲がわからない。

複数のページに表示されているパーツに改修が入った場合、気合で全画面見に行くものだと思っていました。(運動部所属歴はないですが、仕事の時は体育会系になる習性があります。)

気合だけでは効率も悪く、アジャイル開発には適しません。
QAがリリースを遅らせてしまう状況が辛く、差し込み案件に対しても快く「できます!」と言えない状態でした。

解決策として開発チームに協力してもらい、修正した箇所に該当するURL例を教えてもらっています。(効率重視)
一方でQA視点も大事なので、画面設計書などのドキュメントの読み方を学んでいます。過去のテストケースや反省点を活かして、テスト範囲の把握をするようにしています。

CASE3 テスト方法がわからない。

私は自称「要件の理解は早い女」です。
そのため、テスト項目を考えることはできるのですが、テスト方法(再現方法)がわからないことがあります。
当初は「テスト方法は自分で考えないと。」と思っていましたが、知識がないので答えは出ません。

テスト方法が分からない場合には、早い段階で開発チームのエンジニアに相談し、内容によってQAと開発者で分担することもあります。
質問する前に「ここのコードをこれに書き換えるとテストできます」と教えてくれることもあり、開発チームもテストに対して親身になってくれます。


他にも苦労していることはたくさんあるので、開発経験がある人がQAエンジニアになるほうがいいのかもしれないと思うこともあります。
しかし、30代でシステム関連の職種転換を考えたとき、これまでの開発以外の仕事で培った経歴を生かせる職種がQAエンジニアだと実感しています。
周囲の協力のおかげで少しずつQAエンジニアに近づけているのかなと思うようにしています。

4.今後の展望…

ゆこゆこのQAは開発経験者がいないので、みんなも同じように苦労して悩みながら日々業務にあたっているのかな?と思っています。
少しでも自信をつけながら組織を発展させていくための目論見はこちらです。

  • QA内でのナレッジ共有・情報交換を積極的に行いたい

    • お互いの特技を生かして、情報交換。

    • 生産性を優先し、周囲へどんどん質問。聞いたことはチーム内で共有。ドキュメントに残してナレッジを貯めていく。

  • テストの自動化・テスト準備の簡略化

    • リリース前のリグレッションテストに使えるシナリオを作成したい。

    • テスト準備にかかる時間を短縮したい。

  • 何か一つ言語を学びたい

    • Playwrightにも適用できるjavascriptを勉強したい。

頼るべきところは頼り、得た知識は共有し、自動化も取り入れてより効率的なQA業務を目指していきたいです。