投稿者: takuminoblog

このページでは、私が実務で経験してきた結合テストの進め方について書いていきます。

結合テストは追加案件の対応時に実施しました。
システム間の連携やデータの受け渡しに注目しながら進めていきました。
実際に体験した中で感じたことや学びも含めてご紹介します。

●結合テスト実施時の確認

・２つ以上のシステムが想定している動きであるかを確認します。

・初めに想定する動きがシステム間を超えても問題なく動作し、想定した結果が問題なければ結合テスト完了の形で進めていきました。

●不具合を発見した際の対応

・システム間で渡す項目が足りない場合に不具合が発生する場合は流れを止めて不具合個所を修正してから結合テストを再開するようにしていました。

・想定した動きで表示されるべき項目に値が入っていない場合も流れを止めることになっていました。

●印象に残ったこと・苦労したこと

・不具合が発生する事例として多かったのが、単体テストが上手く仕様通りに動いていない場合が多かったです。

・単体テストが安定していれば、結合テストでも大きな問題は起きにくいと実感しました。
そのため、単体テスト段階での精度の高さが、全体の品質に大きく影響すると学びました。

このページでは、私が実務で経験してきた単体テストの進め方について書いていきます。
実際に体験した中で感じたことや学びも含めてご紹介します。

●単体テスト実施時の確認

・項目の最大桁数は設定どおりに入るかを確認します。

・画面上には表示されない処理が、流れ仕様通りの動きを行い結果が想定したものと同じかを確認します。

　画面上に表示されない仕様に関してはログを確認して対応しました。

●不具合を発見した際の対応

・デザイン自体で項目の名前や非表示の項目が表示されているなどその場合はデザインを張り付けてエビデンスを作成します。

・システムを動かし想定した動きでない場合、想定した動きと不具合の動きを比較したものをエビデンスとして作成します。

●開発依頼

・仕様が足りない場合は仕様書のverを上げて対応し、発見した不具合についてはエビデンスを添えて開発に依頼しました。開発とは部門が分かれているため、依頼を行っています。

　開発側からも質問が来るためQA表に答える形で作業をおこなっていました。

●印象に残ったこと・苦労したこと

・ログを確認して対応すると、開発側としてはどこが悪いのかが分かりやすくなると感じました。

・バッチ処理など画面上では見えない動きもログで確認するため、慣れないうちは処理がどのように動いているかがイメージしずらかったです。

・テストは70本以上対応しましたが、自分が書いていないものもあるため想定通りの動きかどうか判断しづらいときもありました。その場合はテスト仕様書作成者に質問する形にはなります。

このページでは、私が実務で経験してきた仕様書・テスト仕様書の作成をどのように進めていたかを書いていきます。
実際に体験した中で感じたことや学びも含めてご紹介します。

●仕様書作成

要件定義フェーズで作成した要件定義書を元に、仕様書の作成を行います。

既存のシステムを元に作成する場合

・新規項目や削除する項目には修正箇所を分かるようにしました。
　(赤色で目立たせるイメージ)

・既存のシステムはどこから参照し要件定義書を作成したかを分かるようにしました。

・デザインも新規に変わる場合は対応しました。

新規作成するシステムの場合

・システム自体が新規作成だとしても似ている仕様のものはあることが多いため、似ている仕様書を参考にしました。

・新規のシステムのため今までにない動きを入れることがあるため、開発側とも連携し確認する必要がありました。

●テスト仕様書作成

・仕様書を参考に作成し、システムの項目や仕様を確認するように記載していきました。

・特に既存システムをベースにする場合は「変更箇所だけでなく、影響範囲全体を意識して抜けがないか」を確認する必要がありました。

●印象に残ったこと・苦労したこと

・仕様書を作成できれば、テスト仕様書も流れに沿って作成できるため、複雑に考えなくてもいいと感じました。

・ただし、SQLでデータ確認を行う際には、新規項目のDB構成が未登録のケースも多く、設計とDBの整合性に注意が必要でした。

このページでは、私が実務で経験してきた要件定義の流れや、顧客とのやりとり、工夫したことなどをまとめています。
実際に体験した中で感じたことや学びも含めてご紹介します。

イメージを持ちやすくするためにデザインも記載しています。

・議事録の作成

１年目に議事録の作成を行いました。

新規のシステムだけでなく、既存のシステムも改善する必要があり全てのシステムを一通り確認する流れでした。

既存のシステムを改善する際は、項目の不明点や項目が不要であれば非表示にすることを決める形が多かったです。

・要件定義書の作成

１年目にも議事録の作成後、各リーダークラスの方の指示があれば議事録を元に不要な項目や追加項目を記載する形で行いました。

追加案件の際は顧客対応時に対面で会議に参加し、

顧客が欲しい項目があればそちらをイメージとしてデザインに反映し、次の会議の際にイメージとして認識の間違いがお互いにないかを確認していきました。

・印象に残ったこと・苦労したこと

要件定義自体がシステムの始まりの部分のため、ここで項目や仕様を固めておくと次のフェーズ以降がやりやすくなると感じました。

会議はどうしても詰まることもあるため、会議で話し合ってもすぐに仕様が固まらないことも多く、何度も調整を重ねる必要がありました。

新規で作成するシステムはデザインがあると進みやすくなる印象を持ちました。

このページでは、私自身が実務で経験してきた仕事を振り返りながらまとめていきます。
イメージしやすいように、フェーズごとに記事を分けて紹介していきます。

●現在の経験

・SESで3年経験(現在4年目)

→SESとして4年目に入りましたが、複数案件を転々とするのではなく、一つの現場で継続的に要件定義からテストまで関わっています。(最終的にはリリースまで入る予定です)

・現場ではSQLを使用

・単体テスト70本以上担当

・追加案件もお客様先と合わせながら対応

・主に資料はエクセルで管理する現場

●実務で関わった主な業務

・要件定義

一年目の初めに経験した際は、主に議事録の作成を行い、

三年目以降には追加案件で顧客に出す資料の作成も行いました。

→詳しくはこちら(要件定義の実務で関わった詳細記事)

・仕様書作成、テスト仕様書作成

要件定義のフェーズが完了後、

要件定義書をベースに作成しました。

基本的には既存のシステムを顧客に合わせて修正を行いました。

→詳しくはこちら(仕様書作成、テスト仕様書の実務で関わった詳細記事)

・単体テスト

70本以上対応を行いました。

仕様書ベースで作成・実行し、バグ報告も行いました。

→詳しくはこちら(単体テストの実務で関わった詳細記事)

・結合テスト

追加案件の際に対応を行いました。

顧客とチーム間との連携もしつつ仕様の食い違いも確認しました。

→詳しくはこちら(結合テストの実務で関わった詳細記事)