こんにちは！ アプリケーションサービス本部の根岸です。
今回はテストプロセスというものの考え方や概念に関しまして少しお話したいと思います。
今期、検討チームにて研究を進めております。
はじめに
一般的にテストについては以下のようなことが言われております。
- テストプロセスが標準化されていない。
- テスト計画やテストケースに関して考慮漏れや対処漏れが発生する。
- テスト工程におけるバランスが悪い。
- テストに必要な工数は、システム開発の全工数の半数を占める（テスト工数の比重）
- テストに関する研修やガイドの整備ができていない。
- テストに関するノウハウの蓄積がされていない。
- テストスキルが属人化している。
また最近の調査では、「システム開発プロセスの中で、注力されている効率化や改善したい工程」として、
「テスト工程」や「要件定義工程」が挙がっており、ユーザーが満足する高い品質でシステムを提供するためには、
これらに注力することが肝要であると考えられている傾向かと思います。
現場での課題認識
私達の現場では、以下の課題認識があります。
- テスト計画の立案やケース作成を行っているが、自己流なやり方となっている。
- 漏れなくテストするようにはしているが、品質を担保する為の効率的なやり方が確立できていない。
- テストに関する品質管理は行っているが、指標の分析や改善へのアプローチができていない。
これらの課題を解消する為に、テストに関する改善の取組みを行うこととしました。
私たちが目指したいゴール
大きく2つございます。
-
あるべきテストプロセスの構築
過去の経験、現状を踏襲するのではなく、世間一般のスタンダードな考え方を研究することで
「あるべきテスティング」のやり方を検討する。これにより無手勝流ではない、外で通用するテスト
プロセスを構築し、テストに関する品質向上や効率化を図る。 -
テストプロセスにおけるPDCAサイクルの確立
テストプロセスの結果分析や改善ができるようなスキームを確立することで、品質改善の取組みを
継続的にできるようにする。
テストプロセス構築を進める上で取り入れる観点・ポイント
テストプロセスを構築・改善するにあたり、全体の考え方や観点として以下を意識して進めることとした。
-
Wモデルへの考え方のシフト
〇 Wモデルとは・・・
テスト設計を上流工程から開始し、開発プロセスとテストプロセスを同時並行に進めるプロセスモデル。〇 Wモデルの様々な定義
- テストのアクティビティを前倒しで実行すること
- テスト仕様書を設計書とほぼ同時に作成すること
- テスト技術者を上流工程から参画させること
- テストチーム、或いは第三者検証会社を上流工程から参画させること
- テスト技術を上流工程に適用すること
- テストの知見を早い段階から開発にフィードバックさせること
〇 Wモデルで想定される効果
-
開発工程
早期段階からテストエンジニアのレビューをすることで、客観的に検証の可能性が確認される為、
設計の漏れを発見する確率が上がり、品質リスクが減少する。 -
テスト工程
テストエンジニアにとっては早期段階から仕様を把握できる為、テストの難易度や注意点を把握でき、
テスト準備が進めやすくなる。また要求項目とテスト項目のトレーサビリティ確保も期待できる。
結果として後工程の前倒しによって、前工程に潜む問題を早期に明らかにし、後工程での手戻りを未然に防止できる。
★ Wモデルを意識した、上流工程からのテストプロセスの導入を検討する。
-
IEEE29119（※）に準拠したテストプロセスの考え方
※ソフトウエアテストに関する国際基準（プロセスの考え方・ドキュメント等を定義）
IEEE29119では3つのグループ層に分けて8つのプロセスを定義している。
また各プロセスにおける成果物（ドキュメント）としては、以下のものを整理することとしている。
★テストプロセスに関する全体像を考慮した各プロセスの構築とドキュメントを整理する。
-
ISTQB（※）が推奨するテストプロセスの踏襲
※International Software Testing Qualifications Boardの略。
ソフトウェアテストに関する国際的な資格認定団体。ISTQBのテストプロセスにおける定義は、以下の5つの活動で構成されている。
- テスト計画作業とコントロール
- テストの分析と設計
- テストの実装と実行
- 終了基準の評価とレポート
- 終了作業
上記プロセスを詳細に崩すと以下のような動きとなる。
★上記プロセスを踏襲し、テストプロセスの前半部分であるテスト計画やテスト分析・設計の部分に着目した検討を進め、各テストフェーズを効率的に行えるようにする。
-
TPINEXT（※）によるテストプロセスの成熟度把握
※オランダSogeti社で策定されたテストプロセス改善に特化した成熟度モデル
内容としては、3つのグループに分けて16のキーエリアがあり、各キーエリア毎のチェックポイントに
答えることにより、到達レベル（成熟度）を確認することができるというもの。全体像は下記のような体系です。
16のキーエリア項目は以下となります。
★テストプロセスの成熟度（品質や効率化）が安定しているか、向上できているかを組織内や第3者的に評価できるようにすることが重要。
-
品質管理指標
一般的には品質検証の為のメトリクスとして以下のような指標が挙げられている。- レビュー指摘件数、密度
- テストケース数
- テスト工程別不良件数、密度
- テスト項目件数、密度
- テストカバレージ率
- 仕様変更件数
- 未解決不良件数
★テストプロセスの改善や評価していく上で必要な各メトリクスを取得し、ベンチマークとして機能させることが重要。
現在、取り組んでいること
-
全体テスト計画の立案（※IEEE829の導入）
※IEEE829：IEEE Standard for Software and System Test Documentation の略で、
ソフトウェア開発におけるテスト工程で作成されるべきドキュメントの構成と用語を
標準規格として定めたもの。最新版は2008年に発行。全体テスト計画の定義項目として以下が定義されています。
- テスト計画書識別番号
- 概要
- テストアイテム
- テスト対象となる機能
- テスト対象外となる機能
- テストアプローチ
- 合否判定基準
- 停止再開要件
- テスト成果物
- テストタスク
- テスト環境条件
- 責任範囲
- 人員計画とトレーニング
- スケジュール
- リスク分析
- 承認
- 用語集
またテスト計画を策定する際のアプローチとして、案件特性に応じた最適なQCD方針を検討し、
それを元にテスト方針を定めるという考え方も重要なポイントであると考えております。★現在、上記を定めるための記載ガイド作成や、試行に着手しております。
-
テスト分析・設計に関して
テスト計画を受けて、どのようなテスト分析・設計をしていくかという部分においては、
以下の観点を整理することが重要視されております。- テストで確認する範囲や観点、判断基準（期待値）の可視化
- テストで確認を実行する為の具体的な条件や組み合わせの可視化
テストすべきだと判断した項目について、テストの目的が達成されるようなテスト項目の組合せを
網羅的に整理できるツールやプロセスが重要と考えています。★現在、上記を可視化する為のツールや作業プロセスの整理を進めながら、試行に着手しております。
最後に・・・
チームでの研究はまだ半ばではございますが、まずはテスト計画、テスト設計におけるプロセスの検討や成果物の試行をし、
テストプロセスの構築や全体像の把握、それを評価・改善ができるスキーム作りを進めていきたいと思います。
定型的なテストプロセスを構築することで、組織として統一した手法に則った作業が出来るようになり、
IT組織としての成熟度の安定・向上や、顧客価値を高められるきっかけになればと考えております。
また昨年度のBABOKを考慮したプロセスと、テストプロセスとのトレーサビリティ連携等についても
今後は研究ができればと考えております。
このような研究を通して、現状プロセスの問題やGAPの把握、見直しを行い、
開発プロセスにおけるテストというものの存在意義をチームで改めて考え直すことがことができております。
引き続きチームで研究を進めていきます。
最後までお読みいただきましてありがとうございました。
