客先常駐SEのテスターの仕事はスキルがつきにくい理由【徹底解説】

2017年11月13日2019年7月5日

管理人おすすめIT転職エージェント

① レバテックキャリア
　 ⇒ 業界最大級のIT・Web業界エンジニア転職情報多数！

② マイナビエージェント ✕ IT
　 ⇒ マイナビエージェントだからできる人気・おすすめの豊富な求人情報！

③ リクルートエージェント
　 ⇒ 転職支援実績No.1・エンジニアからの異業種転職に強み！

こんにちは、元独立系SIer【 Fグループ】で働いていたYaemonです。
SIerでテスターとして検証作業をしている方の中には、

私の仕事はシステムを操作してスクリーンショットのキャプチャーをExcelに貼るだけの誰にでもできる仕事ばかり…エビデンスが大事だと言うけど、スキルを身につけるほうが大事なのに…

と深刻に悩んでいる方もいらっしゃるかと多います。

そこで、このページでは、

▶　常駐先のSIerでテスターを担当する予定のSE
▶　実際にテスターを担当しているSE

に向けて、

▶　テスターの仕事全体の説明と、
▶　客先常駐のテスターの仕事は技術が身につきにくいため、 スキルアップができる仕事へ転職をしたほうが良い

という理由について、客先常駐のテスターとして働いていたフリーランスエンジニアの管理人の経験から説明をしていきます。

1. 客先常駐SEのテスターの仕事はスキルがつきにくい理由（結論）
2. テストエンジニアの仕事内容
3. 参考：検証でよく発生するバグ
4. テスト時の注意点について
5. テスターとして伸ばすことができる能力
6. 転職を考えるべきテスターの仕事
7. 独立系SIer時代に管理人が担当したスキルが身につかない検証の仕事
8. まとめ
9. ステップアップ転職するためのエージェントの効率的な使い方

客先常駐SEのテスターの仕事はスキルがつきにくい理由（結論）

客先常駐のテスターは、担当する製品のハードウェアやソフトウェアに関する知識は身につきますが、
システムを開発する機会がなく、試験仕様書に沿った試験をするといった単調な仕事になりがちなので、キャリアを積んでいきたいのであれば、転職を検討した方が良いです。

転職活動を始めると、エージェントと話すと将来のキャリアに必要なことが逆算で見えてきます。今すぐ転職できなくても、転職を見据えた動きができるようになり、必要な技術を取得して将来的に希望の仕事ができるようになります。

また、評判の良い転職エージェントをまとめしたので参考にしてみてください。

IT業界専門（Web系・SIer）の転職エージェントは　

▶レバテックキャリア
▶マイナビエージェント×ＩＴ　★オススメ

案件数が多く異業種転職もできる大手転職エージェントは、

▶マイナビエージェント（転職全般）
▶リクルートエージェント 　★オススメ
▶DODAエージェントサービス　

の順にオススメです。

まずはIT専門のエージェント1社と面談をして自身の市場価値を知ることが大事です。
詳細は、以下のページを参考にしてみてください。

管理人厳選！転職エージェントおすすめ比較ランキング！

ただし、テストツールのJUnitの使用方法、負荷テストツールのJMeterなど、検証作業を効率化するためのツールの使い方を学習できる機会があれば、テストツールの使い方を習得したほうがエンジニアとしての価値は上がるため、そのスキルを習得した方が良いです。

また、サーバー監視やヘルプデスクの仕事についても同様に記事にまとめているので確認してほしいです。

SIer（客先常駐先）のサーバー監視はスキルがつきにくい話

SIer（客先常駐先）のヘルプデスクの仕事はスキルがつきにくい話

テスターの業務内容は、業務系システムの申請ワークフローシステムを例に説明をしていきます。

テストエンジニアの仕事内容

試験計画書と試験仕様書の作成

*Wikipedia:ガントチャートより

テスト計画書では、テストを実施するにあたり、テストデータの準備、テストするサーバーのリソース、テストするサーバーと連携するサーバーの準備など考えることがたくさんあります。

新規にシステムを開発したり、既存システムを改修するときも、必ず試験仕様書を作成します。試験仕様書の作成では、試験項目だけではなく、全体の項目数と終了までのスケジュールを作成しておきます。

そうして、日々の消化した項目数を記録していくことで、定例のミーティングで定量的な数値にもとづいて進捗報告を行います。また、将来の出荷判定や障害分析のために、別途障害対応表を作成しておきます。

試験仕様書の作成とレビュー

この作業は会社によって異なりますが、テスト項目書をテスターが作成したら、有識者が試験仕様書のレビューを行います。

よくあるレビューとしては、

・今回は、この修正をするんだから、このテスト項目は入れないといけないよね？
・どうしてこのテスト項目を入れなかったの？修正の仕様書をちゃんと読んだ？

と突っ込まれるので注意して欲しいです。

テスターはつまらない作業だと思う人もいますが、技術力がないとテスト項目に漏れがでるので技術力は必要です。特にこのレビューでは、異常系の視点が抜けていることが多いため、レビュー前に異常系で追加する観点がないか自己レビューしてみるといいですね。

参考まで異常系でテストするケースを２つ紹介します。
・入力項目に機種依存文字を入力して申請すると、正規表現によるチェック処理が走らずに最終承認までできてしまう。最終承認画面では、機種依存文字が文字化けをしている。DBには文字化けした文字が登録されている。

・項目に入力文字数制限がかかってない状況で、指定文字数以上を入力して申請ボタンを押すと、DB投入時にエラーになる。

などがあります。異常系はテストでは大事です。

単体テスト

単体テストでは、プログラムが関数レベルで動作するか、入力値単位で動作するかなど、粒度の高い試験項目を作成していきます。Twitterの仕様変更を例にあげて紹介しますね。

最近のTwitterの仕様が140字の制限が280バイトまでと変更されましたが、単体テストをするのであれば、以下の試験項目が考えられます。

【試験項目 / 確認すること】
・全角140文字（280バイト）でツイート / ツイートできること
・全角・半角英数140文字以上（280バイト）でツイート / ツイートできること
・全角141文字以上（282バイト以上）でツイートツイートできないこと / エラー画面が表示されること
・全角・半角英数141文字以上（281バイト以上）でツイート / ツイートできないこと、エラー画面が表示されること

この単体テストでは、JUnitというテスト用のツールを使うとテストで効率化できます。テストツールを使用する環境では、テストエンジニアとしてのスキルが上がり、転職でアピールできるため、すぐに転職しないように注意してほしい。

結合テスト

結合テストでは、仕様書通りに各画面の項目ごとに、機能が動くかテストをします。画面の項目と試験観点をかけ合わせたものをテストしていきます。試験項目が冗長的に多くなるときは、削除して影響がないものは削除するなどの対応をします。

例えば、業務ワークフローシステムの場合、ログインユーザーの役職によって、承認ボタン、却下ボタンなど画面に表示される項目が変わるため、異なる役職のログインユーザーで画面機能を確認するテストがあります。非常に大事な作業であるが、似たような作業のため、どうしても単調になりがちですよね。

こちらの作業では、項目数が非常に多くなるため、単純に項目を消化するのではなく、試験の順番をどう効率的にできるかを考えてから始めたほうがいいです。ここでの注意点は、DBの直接の値操作は好ましくないため客先のポリシーに従ってテストを行えるように注意してほしいですね。

総合テスト

総合テストでは、実際の運用を想定した運用テストと、負荷テストを行います。

運用テストの例をあげると、実際の運用を想定して現場の一般社員が申請をして、部長が承認、経理部、総務部まで一連の承認作業の動作確認をします。その後承認データが、会計システムとも最終的に連携されることを確認して、汎用抽出でcsv出力をしてデータが正しいか確認をします。

負荷テストでは、社内の人数をもとに想定ユーザーを算出して、JMeterなど負荷テストツールを使い、負荷がかかったサーバーで画面を開いたり、汎用抽出の重い操作をして機能が低下しないか、また、停止しないかをテストをします。

分析表の作成と納品

全体のテストが終わると、分析表を作成する所もあります。テスト工程ごとのバグ検出率とバグの傾向を分析するわけです。

例えば、単体テストで出てきたバグは、“軽微なミス”、”仕様の理解ミス”、”設定漏れ”など様々なカテゴリーに分けて、どのカテゴリーの件数が多いかの分析をします。この分析が終わると、テストした製品を納品することになります。分析表の作成は、重要な作業となるためプロパー社員が行い、テスターは関連しないことが多いです。大手の製品になると、分析表をもとにしたリリース判定会議を開くところもありますね。

参考：検証でよく発生するバグ

参考までに業務アプリケーションの検証をしていたときに、よく発生していたバグを紹介します。

テスト環境の設定ミス

事象：テスト環境の設定ミスで、バグが発生したように見えること。
例）一般社員が部長の承認ボタンを押せてしまうといった現象。

ラベルの文字列設定ミス

事象：アプリケーションの画面表示をしたとき、ラベルに誤った文字列が表示されてしまうこと。

入力チェックミス

事象：予期しない文字を入力して、申請ボタンを押したときに申請できてしまうこと。
例）機種依存文字を入力して申請したとき、DB内には、文字化けした文字が登録されるといった現象。

限界値の設定ミス

事象：文字数制限100に設定するべきところを、文字数101以上が入力できてしまい、その状態で申請すると、エラーになってしまう現象。

汎用抽出時のエラー

事象：大量のデータを汎用抽出で出力するときに、タイムアウト値の設定が短く設定されているため、汎用抽出がエラーになってしまう現象。

受け入れテスト時の設定ミス

事象：受け入れテストをするときに、前工程のテストで使用していたデータが残っていたため、データの不整合が発生してしまう現象。

テスト時の注意点について

次に、テストをするときの注意点としては、テスト環境のデータを計画通りに使用することが重要です。

具体例をあげると、検証中の環境に誤ったデータを投入してしまうと、予期しない動作が起きてしまうことがあり、作業の検証ができなくなります。テストが複雑になってくるとよくあることなので、しっかりとテスト環境は抑えておきたいです。

テスターとして伸ばすことができる能力

SIerのシステム開発におけるテスト工程について説明してきましたが、テスターが身につけられる能力を説明します。

製品の内部的な動作

ネットワークや各ソフトウェアの検証を行うため、OSのどこの設定箇所を変更すれば、どうソフトウェアが動くのか理解ができるようになります。
　

ネットワークの知識

ネットワークの製品であれば、無線LAN接続、社内ネットワークの設定、VPN接続など、ネットワーク知識、社内のネットワーク構成を知っておかないと検証をすることができないことばかりです。そのため、ネットワークに関する製品の検証であれば間違いなく向上します。

システムの検証スキル

必要な試験項目書を作成して、検証することが必要になります。問題が発覚したときは、外部のベンダーにログを送付したり、状況の説明をしたり、修正版のバッチ適用後の検証作業など、検証に必要なスキルが身につきます。

また、テストツールのJUnit、負荷テストツールのJMeterなどの使い方が身につくため、システムエンジニアとして知っておくべきテストスキルを磨くことができますね。

マネジメントスキル

テスターを続けていると、チームリーダーとして数人を率いて検証を行うこともあります。そのときは、部下のモチベーションをあげる、全体のスケジュール管理といった、マネジメント能力が身についていきます。

転職を考えるべきテスターの仕事

以上、テスターの仕事内容とそこから身につけられるスキルについて伝えてきましたが、スキルを磨けない環境も中にはあります。

例えば、客先常駐のテスターであれば、プロパー社員が作成したテスト項目書に沿って、WEBのアプリケーションの画面でひたすら操作するといった、１つの工程を数ヶ月連続して行うといった成長する機会が少ない仕事もあります。

ここではもちろん、プログラミングを勉強することはない。そういう案件に携わったときは、すぐに異動の相談や、転職を検討したほうが良いです。参考に、管理人がテスターとしてスキルアップできない環境にいたときの話をします。

独立系SIer時代に管理人が担当したスキルが身につかない検証の仕事

客先常駐時代に、テスターとして管理人が担当していた身につけられるスキルが少ない仕事を紹介したいと思います。
私が担当していた作業は、大手複合機メーカーのプリンタードライバーの検証作業です。

当時、Windows XP、 Windows Vista、Windows 7を中心に、Windowsから定められたデータを、指定のプリンタドライバーを選び、指定の設定項目を選択をして印刷をします。そのときの作業は、ひたすら同じことの繰り返しで気が遠くなる作業でした。以下の設定項目を、掛け算したものでテスト項目書を作りテストをしていきます。慣れてしまうと同じ作業の連続なのでやりがいがなくなるわけです。

[要素]
Windows OS：Windows XP、 Windows Vista、Windows 7、 Windows Server 2008*など
枚数：最低枚数1枚〜最高99枚
カラー：モノクロ/カラー
NUP印刷機能：1/2 〜 1/16
印刷向き：縦、横
綴じ機能：ホッチキスの縦とじ、横とじ
Microsoft Officeのアプリケーションを用いた印刷：Word、Power Point、Excelなど

*VMWareで個人のPCにWindows を入れたり、部内のサーバーにHyper-Vで仮想OSを使用して複数台の端末の検証をしていました。