「Borland ソリューションカンファレンス」のつづき

昨日（１１／６）の

Micro Focus Borland ソリューションカンファレンス
テスト自動化とALMで実現する品質向上・効率化の事例を紹介

つづき。後半の内容をメモメモ



■【事例講演３】CTCの負荷テストツールの導入事例とDevOpsへの取り組み

・会社紹介
　伊藤忠テクノソリューションンズ株式会社
　ITサービス事業グループ

・テストツールの導入事例に基づく、負荷テスト実施のポイントとツールの有効性
　負荷テストの重要性と意義
　負荷テストの目的：システムが耐えられるかどうか
　　従来：CPU性能、不良コード
　　現在：大量トランザクション
　　　→スケールできる：どれくらい？
　・CTCの負荷テストへの取り組み
　　①開発品質向上の取り組み
　　　　CTC SI標準　SINAVI　WBS標準
　　　　開発標準
　　　　開発基準（ガイドライン）
　　②負荷テストツールの提供
　　　　Silk Performer
　　③横断組織による負荷テスト支援
　　　専門性のあるスキル
　　　　　テスト計画・仕様定義が難しい
　　　　　幅広い技術スキルが必要
　・負荷テストの支援実績例
　・プロジェクトの進め方
　　　１．テスト計画
　　　２．テスト仕様書作成
　　　３。スクリプト・データ
　　　４．環境構築
　　　５．試行・調整
　　　６．実施
　　　７．結果分析
　　　８．報告
　　ポイント
　　　・「テスト計画・仕様」の作成
　　　　「試行・調整」
　　　　　　・不用意に厳しいテスト条件・目標値の設定
　　　　効率的な「結果分析・再計測」
　　　　　　・ユーザーに近いところ、粒度の大きいところから
　　　　　　・ツールを効果的に活用
　　ツールの有効性
　　　　１．スクリプト作成の容易性
　　　　　　Silk Performerの支援機能
　　　　２．テスト結果分析の容易性

・次世代開発スタイルとしてのDevOpsの取り組み
　開発スタイルの変化
　　　従来：Water fall
　　　　　負荷テスト
　　　これから：DevOps
　お客様の要求の変化
　　　いち早くサービスを提供
　　　ビジネス・スピード重視
　変化への対応を誘うキーワード
　　　①アジャイル
　　　②統合開発環境→自動化を支援するプロジェクト支援ツール
　昨今の開発プロジェクト例
　プロジェクト管理が複雑に
　発生しうる課題
　　　コードの衝突
　　　タスクとの関連性
　　　再テストに時間がかかる（環境設定漏れ）
　対応のポイント
　　　ソース更新手順の規格化
　　　ツールによるプロジェクトの見えるか
　　　ビルド・テスト・リリースの自動化
　　　非機能要件のプラットフォーム化
　ビルド・テスト・リリースの自動化
　　　ユニットテスト
　　　ソース品質チェック
　　　画面テスト
　　　ソースコードレビュー
　テスト観点の漏れがないように
　メトリクスの活用
　　　ユニットテスト数とコード量の相関
　　　ソースコードの複雑化
・CTCの考える次世代開発環境

■【事例講演４】　「開発プロセスの効率化を図る　Star　Team導入事例紹介」

・会社概要
　スミセイ情報システム
　　ゆうゆう生保→Star Team 導入

・業務内容
　メディケア生命のシステム開発

・案件管理
　Excel,RedMine→管理ツール→VSS

・５つの課題
　人的作業リスク
　変更管理のトレース
　内部統制
　VSSのリスク
　テストの効率化

・３つのキーワード
　　機械化の促進
　　内部統制の強化
　　検証の強化

・機械化の促進
　　ソースとドキュメントの集中管理
　　変更ログの自動取得
　　ビルドの自動化

・内部統制の強化
　　ソースコードアクセス
　　ワークフロー（承認ログ）管理

・検証の強化
　　単体テスト効率化
　　GUIテストの自動化

・最適なツールの検討
　　オープンソースから検討を始める
　　　　ライセンス無償
　　　　機能要件は満たせる
　　　　連携は作りこみ必要
　　　　内部統制

・Star Teamを選択した理由
　　機械化できる
　　内部統制
　　すべての要件を１つのツールで
　　特定の方法論でない（うつわ）
　　通信の暗号化レベル

・まとめ
　Star team選択により、さらなる開発効率化を推進

組み込みでは
・要件管理のかりばーが使える

Star Teamは部分売りしないの？
・バージョンがある