開発ワークフロー
- 1.
- 2. ワークフロー 開発フロー テスト手法 BTS の活用
- 3. 開発フロー 開発から単体テストまでのワークフローは次の通り。 1. 単体機能 ( ページ単位 ) を開発 最低限動作する状態まで完成させる。単体テストはこの時点では不要 ( レビューで機能実装の差し戻しが発生する可能性があるため ) 2. 1 が完了したら次の機能を開発 3. 2 が完了したら次の機能を開発 (1 〜 3 の繰り返し ) 4. SETA 側でのレビュー 認識違いや実装内容に問題がある場合は差し戻しを行なう ( 開発者は優先対応すること ) レビュー期間中に開発者 ( または試験者 ) が単体仕様書を作成 レビュー手法は後述 5. レビュー通過後は開発者が単体テストを行なう
- 4. 開発フロー 結合テスト、総合テストを含めたワークフローは次の通り。 1. 全ての単体テスト完了後、結合テストを行なう 開発進行中に試験者はテスト仕様書を作成しておく 2. 結合テスト通過後、統合テストを行なう 結合試験進行中に 試験担当者がテスト仕様書を作成しておく 3. 総合テスト通過後、システムのリリースを行なう
- 5. テスト方法 システムを開発する上で必要となるテストフェーズは次のように分類される。 テストフェーズ担当区分 概要 顧客 SETA 単体テスト ○ 個々のプログラムモジュールが仕様通り機能しているかを確認する 結合テスト ○ ○ モジュールを組み合わせてうまく動作しているかを検証する 統合テスト ○ ○ システムとして全ての機能が正常に動作しているかを検証する セキュリティテスト ○ ○ XSS 等によるセキュリティホールがないか検証する 負荷テスト ○ ○ 想定されている以上のデータを投入し、システムに影響が起こらないか検証する
- 6. BTS の活用 コードレビューや仕様変更については全て mantis で一元管理する。 簡単な仕様変更が生じた場合でも、口頭レベル (Skype 等のチャット ) で 伝えるのだけではなく、必ず mantis に変更内容を残すこと スペシャルアカウント「 SPECIFICATION_NOTICE 」について ・ SPECIFICATION_NOTICE アカウントは全てのプロジェクトに参加する ・チケット内容をプロジェクト参加者全員に通知したい場合に使用する ・メールアドレスはプロジェクトにより作成 ( メーリングリスト ) 仕様の追加、及び変更 ( カテゴリ ) はプロジェクト参加者全員の認識が必要となるため、担当者は「 SPECIFICATION_NOTICE 」にアサインする。但し、実際にチケットの編集や 更新を行なう場合は各個人のアカウントで行なうこと。 (SPECIFICATION_NOTICE アカウントでログインする必要はない )