またプロジェクトの途中ではありますが、自分の中で要件定義〜外部結合の始まりまでのフェーズを経験して思ったことなど
全般
- 文字や口頭だけで仕様のやりとりをすると認識の齟齬や問題点がでやすいため(人によって認識の差が出てしまう)、基本的にはデータとケース(あるいは図)によるコミニケーションを取るようにする。
- それぞれのフェーズで完璧に要件が絞りきれる、設計が完了することは少ないため、必ずバッファや対応策を考えておく。(今回では詳細設計以降に発覚した仕様が全体の３〜４割)
- ドキュメントの重複を極力避けるようにし、１つの情報を複数の箇所に書かないようにする(例えばAPI仕様書と詳細設計書で複数の情報が同じ箇所に書かれているなどがないように)。
- コードとドキュメントを連動させることができるようにし、変更の未反映などが残りにくいようにする。(プロジェクトによっては理想論かも・・・マクロ使えればある程度実現は可能か・・)
- 自動化ツール(API仕様書からサンプルを出す、テーブル定義書からDDL作成、Excelからinsert文やupdate文を作る)を時間の余裕のある時に作っておく。コードと設計書の乖離を防ぐ手段。
- 変更を前提としたドキュメント作成や告知方法、運用フローをとるようにする。変更の検知をどのように行うか。定期の告知などが一般的。
- ルールを極力少なくして、漏れや作業側の疲弊をさせないようにする。
- 設計と製造の完全な分離は難しいと思う(ドキュメントだけで完全な意思疎通は難しいため。)
- パフォーマンスは後回しにされがちだが、考慮していないと外結自体がすすまないことが多いため、単体時にある程度のデータ量を考慮して進めておくことが大事。(パフォーマンスを考慮して、データ量により、PG修正発生することが多い)
要件定義
やりたいことを文言だけでやると認識の齟齬が出やすいので、画面(簡単なモックがあればベスト)とケースごとのサンプルデータのやり取りをすること、いかにデータのコミュニケーションを取れるかが鍵だと思う。
テーブル定義書がなくともデータのコミニケーションは取れるはず。
特に現場担当者などの人に入ってもらい、「生きたデータ」を提供してもらえると良い(仕様的にOKでも、現実的にあり得ないデータだと状況が想定しにくい。)
基本設計
画面設計、テーブル定義書とIFの作成がメイン。
要件定義に引き続き、データのコミュニケーションを中心に行う。
また技術的に新規技術はこの段階で調べておく(ある程度実機での調査が必要。)
IFの細かいルールについてはAPI仕様書に関する注意事項を参考に。
詳細設計
要件定義、基本設計書に引き続きデータのコミュニケーションを中心に行う。
- 作るドキュメントはAPIのシーケンス図のみでOK(文だとわかりにくい・・、ログはこの中に入れてしまう)。
- 変更や修正があることを前提に設計する。
- ドキュメント間のルールやフォーマットのテンプレートなどを作っておき、人での作業差分を減らす
- 複数入力を避けるドキュメントにする。
- この時点でテストデータを作っておき、製造側の負担を減らせるようにする。(できればユーザーに近い人に意見をもらえるとベスト)
製造
- 規約ツールを入れて人チェックを減らす
- 状態確認を迅速に行えるようにする(主にマイグレーションも含むデータ確認や設定ファイルのテンプレート化)
- 設定ファイルやIFの活用などでローカル用と開発環境、ステージング用を分けるようにしておく。実際に試験が始まってから環境切り替えの確認コストがバカにならない。
- 仕様がわかる人間によるテストデータ作成に重きをおく(プログラムを書くよりもデータを作るのと確認のほうが時間がかかるため)。
- 仕様変更があることを前提にプログラムを組む、体制の変更をとる。
- できればxUnitテストを入れて、Excelからデータを読み込めるようにしておく。(難しければ一部でもOK。あくまで作業軽減が主目的。)
- 単体テストまえに環境構築&正常系や稼働確認をしておく(環境構築コストを考慮に入れてないようなケースが結構あり、最初の疎通確認で時間がかかる・・ってケースが多々ある)。
- 認証ロジックや制限などはテスト用のものを考える(テスト時は認証処理を不要にする、ゆるくする、有効期間を長くするなど。)
単体テスト〜内部結合
項目整備に関してはテスト項目の作り方(縦項目について)、テスト仕様書の必要な項目の定義など(横項目の定義)を参照。
- 製造段階でデータを用意しておき、すぐにはじめられるようにしておく
- できれば人でなく、機械的にできる手段も採用する。(特にバリデーションや単体モジュールのInOutの検査など組み合わせが非常に多いケースで有効。完全な自動化はケースによっては逆に効率が落ちるのでやめる)
- 異常系を発生させるコードやデータ投入SQLをあらかじめ用意しておく。(あるいは手順をしっかり書いて置く)
- できればサンプルではなく、開発段階で良いので外部とつながるようにしておくのが望ましい。(いきなりブロック項目があって進まない・・・ということが起こりがち。なかなか難しいかもですが・・・)
- 仕様的なデータ投入もそうだが、生きたデータ(実際のケースに近いデータ)のレビューができたほうが良い
- プレ的な環境での結合を用意しておく(いきなり外部結合で繋がらない、始められない・・というケースが現実的に多い)
- できれば文字だけでなく、通話ツールで担当者間で連絡を取れるようにしておくのがベター
- データ作成ツール(技術的な面でも、仕様的な面でも)を余裕のある段階で作って置くべき。欲しいデータをすぐに投入できるように。
- 外結が始まる前にできるだけ大量データのテストかつ生きたデータを作れるようにしておく。想定されているテストデータの量が全然違って、テスト初日に全く動かない・・・ということが起こりがち。
一覧系であればSQLやロジックを根本から変えることになるし、過去にはプルダウンの項目が万単位でフリーズなんてこともありました。また地図のSQLとか特別なものの場合も技術調査しておいたほうが良いかも・・・ - 外結の初期段階でブロック(そのせいで他の試験項目に移れない)を出さないことが大切。
外部結合
- 仕様不備が発覚することも多々あるが、仕様変更対応期間をずらす、必須でなければ次フェーズに回すなどできればベター。
- 単体テスト〜内部結合に引き続き、できれば文字だけでなく、通話ツールで担当者間で連絡を取れるようにしておくのがベター(コミニケーションロスが大きい)
- 見たいログを見る技術をこの段階で調査しておくこと(特定しやすい情報が入っているか。大人数で繋ぐとログの発見だけでも困難になる。)
- サーバーダウンが結構あるため、回避策を要検討。
- できればベンダーごとに複数の環境があることが望ましい・・・テストする際初期化を行う必要があるため
- デプロイ時の手順を単純にし、できるだけこまめなデプロイが簡単にできるようにしておく。(CD系のツールがあればベスト)
- ロジックの大規模な変更は無理だが、エラーコードやログ文言など微調整したいものは変更を容易にしておく(できれば外部ファイル化しておくと融通がきく)
テスト期間中、原因の特定などに時間がかかることが多いため、エラーメッセージを明確化して置くことはかなり大切。
総合試験
- 一般的にはシナリオテスト(ユーザーの想定の使用ですすめる)、負荷テスト、セキュリティテストが一般的
- この段階でPG見直しになることが結構ある。(パフォーマンス、負荷にからむもので見直しになることが多い。多い点としてはSQLをGroupByするもの。chunkメソッドでメモリ節約をするなど)
- 特にデータ量が想定と違うと最悪テーブル設計の見直しになることがあるため、最低限データの桁程度は押さえておく
- コードレビュー時にセキュリティテストを見込んだチェックをしておく(SQLインジェクション対策など)
- JMeterなどで負荷を加えたときにどのような事態になるかを確認しておく
