ID:27686さん

【概要】 5月 ~ 9月 基本設計、詳細設計を行なった。 9月 ~ 2月 QAエンジニアとして、結合テストと負荷テストの責任者として担当した。結合テストに関しては、会社として初の試みとなるオフショア開発を利用してのテストになった。また負荷テストに関しても社内で実績は少なかったため、次に繋がるためのドキュメントの作成も行なった。 【内容】 （5月 ~ 9月） 設計に関しては、OpenAPiを使ってAPI設計書を作り、さらにCacooを用いて詳細設計を行なった。 大きなプロジェクトだったのもあり、ウォーターフォールに近い手法で進めていたため、比較的SIerが行うような設計を行なった。 そういった設計に関する経験は、全く持っていなかったので、経験豊富なエンジニアに尋ねたり、上流工程に関する書籍を読んだりして徐々に慣れていった。結果的に担当部分に関しては予定工数より早く終わらせることができた。 （9月 ~ 2月） テストに関しては、9月からベトナムに出向することになりQAエンジニアとしてテストの責任者となった。 方針として、複雑な仕様は理解させるのが難しいと予想し、簡単なところをテストしてもらうことにした。なので、テストケースに関しては、簡単な部分は詳細にテスト内容を記し、翻訳しやすいように誤字脱字なく、さらにカタカナ言葉は減らすようにした。複雑な部分に関しては、自身で行う予定だったため、ざっくりと書き、作成工数を減らした 結局全体で2000ケースほどのかなり膨大な量になったためベトナム人エンジニア5名に参加してもらった。 ベトナムについてからは、以下2点を行ない案件を進めた。 ・案件内容の説明 ・テスト方法説明 案件内容に関しては、そもそもの自社のプロダクトの説明をする必要があったので、そこから説明を行なった。また予約に関してはベトナムとの文化的な違いがないか都度確認しながら説明した。例えば、ベトナムでは24時間表記というものの考えがなかったので、その説明を行なったりした。 テスト方法に関しては、とにかく見つけたら動画や写真をつけて送ってくださいと言った。わからない箇所や疑問点はなんでも報告して欲しいことを事前に伝えていたのもあり、かなりの報告が上がってきた。 結果的に2000ケースのテストケースを叩ききり、バグの報告数としては、100件を超える報告ができた。 報告に関しては、自身で行なっていたが、ベトナム人が出したバグの再現を再度自分自身で行なっていたため、かなりの時間がかかっていたので、途中からより詳しく書いてもらうようにフォーマットを決めてから負担を減らすことができた。 結果的に、プロジェクトとしては無事納期通りのリリースができた。 バグの発生率としては、既存の異常なデータに対応できていないくらいで3件ほど出ただけで、致命的なバグが出ることはなかった。 会社としてオフショア開発にどのようなテストが行えるかの実績ができ、ノウハウの蓄積を行うことができたため、今後の標準を作成することができた。 負荷試験に関しては、GatlingとJmeterのどちらかを使う話になり、よりGraphicalに結果を表示することができるGatlingを使うことにした。社内でもGatlingを使ったことのあるエンジニアはいなかったため、公式ドキュメントなどの情報を元にテストシナリオを作成した。 結果的に用意していたものより、低いスペックのもので本番サーバを構築することになり、会社のコストを下げることができた。 また、会社として負荷試験の実績がそこまでなかったので、ドキュメント化して再度利用できるようにした。