【エンジニア】テスターから要件定義を任されるエンジニアに這い上がった話②【3年目】

今回は「テスターから要件定義を任されるエンジニアに這い上がった話」というテーマで３回に分けてお話ししています。
今回はその第二弾。入社３年目「テスター時代」のお話です。

第一弾は下記記事をご覧ください。

【ITエンジニア】テスターから要件定義を任されるエンジニアに這い上がった話①

この記事では、新卒１年目で信じられないミスを繰り返し、テスターの仕事しか任されなくなった私が、要件定義を任されるまで這い上がった話を書いていきたいと思います。

今回は新卒３年目のテスター時代の話を書いていきます。

テスターとして売り飛ばされたエンジニア３年目

１年目～２年目にかけて数々の失敗を重ねた私。そんな私に渡された仕事は、SES案件でテスターの仕事でした。

私が派遣された案件は、プログラミングが丁度終わった所で、単体試験工程に入る段階でした。着任した案件は炎上していて、数か月リスケして進められていました。

エンジニア３年目で単体試験のテスターとかいう最底辺の仕事

IT業界は図のようなピラミッド構造になっています。超ざっくり言うと、開発工程では、上流の要件定義から、下流の単体試験の仕事まであります。

一般的には、上流になればなるほど、地位が高くなり、給料も高くなると言われています。
私が任されたのは単体試験のテスター。一番底辺のお仕事ということです。
※一般論で、個人的にはどの仕事も大事だと思っています。

 

単体テストのメンバーは、複数の派遣会社からかき集められたようでした。
私の会社からは4名（若手中心）。
A社から4名（ご年配中心）。
B社から2名（中堅中心）。
といった感じです。

A社のメンバーは、全員ご年配の方で孫がいる方もいました。
また、向上心がなさそうな方ばかりで、中には仕事をさぼっている方もいたと思います。

単体テストケースは全部で8000件ほどあり、私たち単体テストメンバー10名でこなすことになりました。

同期が要件定義工程や、設計工程のような上流工程をこなす中、単体試験のテスターの仕事をしている時は絶望しかなかったです。。

ソースコードの品質が悪くてテストが進められない！

単体テストを始めてみると、ソースコードの品質が劣悪であることが分かってきました。
全部で20ケースぐらいある試験の最初の1ケース目で問題が見つかり、その後の単体試験ができなくなるプログラムもざらでした。

問題を報告しても、プログラマーに数日放置されてそれ以降の単体試験を進めることができなくなり、単体試験がスケジュール通りに進まなくなってきました。

このままプログラマに任せていても遅れるだけだと思い、対策を練ることにしました。

単体テストの改善策に乗り出す

どうやったら、プログラマにすんなりバグを解消してもらえるか。考えた私は以下のことをはじめました。

ソースコードを点検してプログラマの負担を軽減

まず始めたのが、発生したエラーから、ソースコードのおかしい場所を探す作業です。

それまでは、ソースコードの問題箇所を探す作業はプログラマの役割でしたが、テスターの私がその役割を担うことによって、プログラマがバグ修正に専念できると考えました。

エラーログには、エラーメッセージとともにエラーが発生した箇所が記載されているので、そこからこれが原因なんじゃないですか？というところまで、障害票に記載するようにしたのです。

障害票を具体的に書いて、バグ修正を楽に

また、障害票の書き方も気を付けました。気を付けたのは以下の点。

これをできる限り具体的に書いていきました。

とにかく、障害票を見れば、ソースコードのどこを直したらよいかが一発で分かるような
障害票になるように心がけました。

また、テストケースに表れていなくても、「これおかしいんじゃない？」って思ったことも案件のリーダーに報告して障害票に起票するようにしました。

その結果、他の作業者よりも多くバグの発見ができ、かつスケジュール通りに単体試験を完了させることができました。

案件のリーダーに褒められる

そんな感じですごしていると、ある日案件のリーダーから

 

と直接褒められました。

自分の役割は、プロジェクトでは超末端だったので、案件のリーダーが自分の働きぶりをみてくれているとは思ってもいませんでした。
とっても嬉しかったのを覚えています。

契約の継続を勝ち取る

当初は単体テスト期間だけのSES契約だったのですが、私は次の結合テスト工程も契約してもらえることになりました。

ちなみに、契約の延長を勝ち取れたのは、10人いた単体テストメンバーのうち、私含めて3人だけでした。

主体的に動いたことが、評価につながった

私が契約を勝ち取れた理由ですが、

主体的に動いて、作業を改善できたこと

が一番大きかったかと思います。

前述の単体テストで改善した以下のことは、誰かに言われて改善したことではありません。

「単体テストをスケジュール通りに終わらせ、ソースコードの品質も確保する」という目的に沿って、私が改善すべきことを考えて実施したことです。

 

逆に言うと、契約を勝ち取れなかった人は、そのような改善をしておらず、言われたことだけを淡々と作業していたように思います。

作業の目的に沿って主体的に動いたことが契約継続可否の別れ道になりました。

この経験から得たこと

この経験から、以下２点の収穫がありました。

つまんなそうな仕事でも、工夫すれば、評価してくれる人がいる

今回の案件で私が任されたのは、「単体テストの実施」という単純作業でした。要件定義を任せてもらっている同期がいる中で焦りもありました。

しかし、そこで腐ることなく自分なりに工夫してベストを尽くせたのが良かったと思います。同じように悩んでいる方がいれば是非諦めることなく今の仕事を全うしてみてください。

必ず評価してくれる人が現れるはずです。

品質へこだわり抜けるのは自分の長所

２点目の収穫は、自分の長所に気付けたことです。単体テストで、バグが出たりスケジュール通りいかなくなっても、作業品質には妥協せずに仕事をしました。

結果として、後続工程では、自分の担当した機能で単体テストから流出したバグは見つかりませんでした。

品質向上に貢献できたことは大きな自信になりました。

コミュニケーション能力や、作業のスピードには課題がありますが、「プログラムの品質にこだわる」という点については、他の人にも負けない能力があると気付けたからです。

もし悩んでいる方がいたら、まずは自分の長所を一つ見つけて自信を持ってください。

その自信が、他の仕事にも良い影響を及ぼします。

自信を得た私は、次回、転職活動に乗り出すのです・・・！

では！今回はこの辺で！