SPI Japan 2013 in 東京 Software Product Line の実践 ~ テスト資産の構築 ~ 住友電工情報システム株式会社 QCD 改善推進部品質改善推進グループ服部悦子 2013.10.17 P.1/24
目次 1. テスト資産構築に至る背景 2. テスト資産の構築 ~ 自動テストの実現 ~ 3. 結果と評価 P.2/24
テスト資産構築に至る 背景 P.3/24
背景 品質改善活動 継続して行っている 生産性向上活動 ( 特にコーディング生産性 ) 開発フレームワークのバージョンアップ ソフトウェアプロダクトライン <テスト資産の提供 > 何を提供できるか? 何を提供できる可能性があるか? P.4/24
ソフトウェアプロダクトラインエンジニアリング より 製品管理 ドメイン要求開発 ドメイン設計 ドメイン実現 ドメイン試験 ドメイン資産 ( ドメイン成果物 ) 要求アーキテクチャコンポーネント試験 アプリケーション要求開発 アプリケーション設計 アプリケーション実現 アプリケーション試験 アプリケーション 1 引用元 : ソフトウェアプロダクトラインエンジニアリング ソフトウェア製品系列開発の基礎と概念から技法まで クラウス ポール ( 著 ), ギュンター ベックレ ( 著 ), フランク ヴァン デル リンデン ( 著 ), 林好一 ( 翻訳 ), 吉村健太郎 ( 翻訳 ), 今関剛 ( 翻訳 ) P.5/24
単体テストの問題 十分なテスト資産を提供できていない! ドメイン資産 ( 試験 ) AsIs ToBe PG 仕様書を基準にしたチェックシート 自動テスト? I/P プログラム開発プロセス O/P 外部仕様書 PG 仕様書 コーディング単体テストプログラム P.6/24
テストに関するあるべき姿 デグレを防止できる QCD ToBe 実現すべき仕様がテストとして実装されている 自動テスト AsIs IT ST 保守コストを低減できる QCD ToBe 実現すべき仕様を全て理解できないので関係しそうな部分だけをテストする テストが実装されているので実行するだけでよい テストをする為にテストデータを用意しないといけないテストの実行手順を理解しないといけない AsIs P.7/24
自動テスト導入の課題 ~ 何故今までできなかった?~ コスト 自動テスト開発のコストが増加してもライフサイクルのどこかで元をとれるかもしれない 手動テスト でもコスト増は受け入れにくい 自動テスト 自動テスト ( 理想 ) できればこう実現したい 外部設計 PG 設計 開発 IT ST 保守 改善 t P.8/24
目指す姿と課題 目指す姿 全プロジェクトが自動テストを開発し 保守業務が改善される 従来のコストで開発したい 保守業務の改善 開発者修正時テスト工数減デグレ検出率向上 利用者トラブル減保守コスト減 課題 1. テストプログラム開発工数の捻出 課題 2. 教育コストを抑えたい 全プログラマーが自動テストを開発できる P.9/24
テスト資産の構築 ~ 自動テストの実現に向けて ~ P.10/24
課題 1. テストプログラム開発工数の捻出 コスト etester UT が終わってからしか開発できない UT UT JUnit UT UT 工数を削減し従来工数に納めたい 対策 コーディング コーディング コーディング 従来 etester ( 操作記録型 ) JUnit ( コーディング型 ) 採用 テストファーストによる自動テスト実現 UT 項目の削減 P.11/24
課題 1. テストプログラム開発工数の捻出 対策. テストファーストによる自動テスト実現 従来 アプリケーションプログラム 新 アプリケーションプログラム 従来フレームワーク エラーチェックメソッド チェック A チェック B 新フレームワーク エラーチェックメソッド A エラーチェックメソッド B チェック C エラーチェックメソッド C テストケース チェックA 事象 A1 YYYY 事象 A2 ---- チェックB 事象 B1 YY-- 事象 B2 --YY チェックC 事象 C1 Y-Y- 事象 C2 -Y-Y メソッド AのテストケースチェックA 事象 A1 Y- 事象 A2 -Y メソッド BのテストケースチェックB 事象 B1 Y- 事象 B2 -Y メソッド Cのテストケース チェックC 事象 C1 Y- 事象 C2 -Y P.12/24
課題 1. テストプログラム開発工数の捻出 対策. テストファーストによる自動テスト実現 従来 コーディング テスト設計 テスト テストファースト テスト設計テストプログラムコーディング コーディング テスト 実現した方法 テスト設計 コ ディング テスト テスト設計 コ ディング テスト テスト設計 コ ディング テスト テスト設計とコーディングが密接な開発プロセス ( メソッド毎 ) P.13/24
課題 1. テストプログラム開発工数の捻出 対策.UT 項目の削減 単体テスト抽出基準を作成テストをする しないを明確に設定 例 画面のタイトルが正しいか 外部設計レビュー PG はテスト不要 画面遷移が正しいか 手動テスト 標準テスト 82 項目中 40 項目は UT 不要と決めた 管理者の場合は XXX 管理者以外の場合は 自動テスト 単体テスト WG SE(PL クラス )2 名 PG 3 名改善 2 名 P.14/24
課題 2. 教育コストを抑えたい 学習度 実現したい学習曲線 2 自分で習熟度を上げられる 1 初めてでもある程度開発できる 従来フレームワークの学習曲線 対策. 自動生成 対策. マニュアル整備 3 ヶ月 開発時間 目標 :1 ヶ月 P.15/24
課題 2. 教育コストを抑えたい テストプログラムの自動生成 機能の設計情報をデータベース化 ( リポジトリ ) プログラムのインタフェース ( メソッド名 引数 ) も保持 インタフェースは15 種類種類に応じたテストプログラムの雛形を自動生成することが可能プログラマーは自動生成された雛形に必要なロジック ( テストケース ) を追加することでテストプログラムを開発できる テストデータの自動生成 対策. 自動生成 リポジトリに画面項目を保持データの雛形を生成 テストデータはテストプログラムから切り出しCSVファイルテストケースに応じて簡単にコピーして作成することが可能 改善担当 ( 私 ) FW 開発者 P.16/24
課題 2. 教育コストを抑えたい 対策. マニュアル整備 1 章立ての工夫 PG 開発手順 仕様の理解 開発手順決定 メソッド開発メソッド開発 手動テスト 完了判定 メソッド開発マニュアル テスト設計 テストコーディング ロジックコーディング 自動テスト メソッド完了判定 章立て ~ テストファースト 種類 2 種類の工夫 15 のパターンに分類しそれぞれにマニュアル作成 エラーチェック 更新項目値の加工 画面表示属性の設定など 3 参照の工夫 必要な時に必要な種類を参照できるコーディング中 (Eclipse) Eclipse public int checkvalue_bookcase(x_iv, x_fv) { int p_count = 0; databookcase p_bookcase; if ( isexistsbookcase( ) ) { p_count++; } return p_count; } ブラウザ マニュアル ( エラーチェック ) 1. テスト設計 2. テストコーディング 3. プラグインコーディング : P.17/24
課題と対策まとめ 課題 1. テストプログラム開発工数の捻出 対策. テストファーストによる自動テスト実現 対策.UT 項目の削減 課題 2. 教育コストを抑えたい 対策. 自動生成 対策. マニュアル整備 P.18/24
結果と評価 P.19/24
構築したテスト資産 製品管理 ドメイン要求開発 ドメイン設計 ドメイン実現 ドメイン試験 ドメイン資産 ( ドメイン成果物 ) 要求アーキテクチャコンポーネント試験 JUnit で自動テストが開発できるフレームワーク テスト PG 初期コードの自動生成 マニュアルアプリケーション ( テストファーストアプリケーション ) 要求開発 単体テスト項目抽出基準 設計 アプリケーション 1 アプリケーション実現 アプリケーション試験 引用元 : ソフトウェアプロダクトラインエンジニアリング ソフトウェア製品系列開発の基礎と概念から技法まで クラウス ポール ( 著 ), ギュンター ベックレ ( 著 ), フランク ヴァン デル リンデン ( 著 ), 林好一 ( 翻訳 ), 吉村健太郎 ( 翻訳 ), 今関剛 ( 翻訳 ) P.20/24
試行プロジェクト開発結果 開発結果 本体コード A テストコード B テスト実装率 B/A 自動テストカバレッジ (C0) 平均 116 348 2.99 96.3% 最小 65 135 2.01 82.3% 最大 224 488 4.73 100% UT 実施時のクリック回数 約 96% が自動テストできている 従来 今回 1.99 回 /JaX 1.03 回 /JaX 半分以下 UT 工数減 (*)JaX 弊社の規模指標 ( ライン数 ) P.21/24
課題 対策の評価 課題 1. テストプログラム開発工数の捻出 対策. テストファーストによる自動テスト実現対策.UT 項目の削減 課題 2. 教育コストを抑えたい 対策. 自動生成対策. マニュアル整備 実装したコードの 96% が自動テストできている UT クリック数が従来と比べて半減している 開発者の大半は予定工数内でテストファーストできている 若手プログラマーの一部は予定工数を超過している P.22/24
今後の課題 習熟スピードの向上 プログラム初心者でも 1 ヶ月習得を実現したい 自動テスト範囲の拡大 Selenium の活用 画面遷移 JavaScript 1 機能の中の業務シナリオ業務機能はサブメニューが多く 標準シナリオが活用できない リポジトリに個別シナリオを登録することで実現できるのでは? テストデータ自動生成 ( 特にデータベース ) テストデータまで構成管理していないいつでも同じ自動テストができる P.23/24
終わり ご清聴ありがとうございました P.24/24