10月まで勤務していた現場での業務が終了しました。

今回のレポートでは、実際に現場でどのような業務を行っていたのかをお伝えします。

今回の業務では、主に小売業の受発注システム改修のテスト工程に携わりました。

テスト工程では、テスト仕様書作成→テスト実施→不具合改修という流れとなります。

私が案件に参加したのはテスト工程からでしたので、まずはシステムを動かしたり、設計書やソースコードを見たりして、そのシステムがどのように動作するのかを理解するところから始まりました。

前回の現場でも今回の現場でも、同じ言語（VB）を使っていたので、言語からさっぱり・・ということはなく、理解しやすかったです。

ある程度理解したら、テスト仕様書の作成に入ります。

改修がメインでしたので、基本的には設計書を見て、改修されている部分をテスト項目に加えていきますが、それに伴い修正したソースコードがあればその部分のテストも必要です。

また、改修したことによって、改修点以外の箇所でおかしな挙動がないかをみるモンキーテストなども含めて作成しました。

実際にテスト実施の段階に入ると、テストする為のデータが存在しないこともあり、データ作成から始めることも多かったです。

さらにそのデータを作成するには、ＤＢ上、色々なテーブルが関わっている為、どこのテーブルのどの項目にどんなデータを入れないといけないかをソースや設計書から探す作業が複雑でした。

そのため、実際のテスト実施よりもデータ作成の方が大変だな・・と感じる時もありました。

また、ある実装部分のテストをしていても、その過程で別の不具合を発見することもありました。それが元々の仕様なのか不具合なのかを確認し、不具合の場合は、改修することになります。

テスト観点とは違う部分でも、「あれ、なんかおかしいな・・この仕様であっているのかな？」というアンテナを張りながらテストすることは、とても大事だと思いました。

不具合の改修作業では、コーディングの実装担当者が対応したり、テスト担当の私もプログラムを見て原因を把握し、ソースコードの修正を行うこともありました。

テスト工程が終わると、お客様に納品し、指摘がなければ終了となります。納品の直前のテスト工程はとても大切な作業なので、設計書作成、製造工程よりも、テスト工程が一番時間をかけている現場も多いみたいです。

今回現場のテスト作業で学んだことは、システムの挙動に何か違和感を感じたり、本当にこの仕様であっているのかな？と少しでも疑問を持ったりした場合は、しっかりと確認し、不具合を取りこぼさないようにアンテナを張ってテストに臨むことが大切だと感じました。

早々に発見することで、後々大きな改修を避けることができるかもしれません。

今回のレポートではテスト工程から携わった現場での業務の流れをお伝えしました。

最後まで読んでいただき、ありがとうございました！