索的テスト特有の不透明さが受け入れられ難いこのような探索的テストにおけるテスト管理の問題を JSTQB Foundation Level のシラバスに従いテスト管理のカテゴリごとに整理すると表 88-1 のようになる [2] 表 88-1 探索的テストにおけるテスト管理の現状テスト管理のカテゴリ

Size: px

Start display at page:

Download "索的テスト特有の不透明さが受け入れられ難いこのような探索的テストにおけるテスト管理の問題を JSTQB Foundation Level のシラバスに従いテスト管理のカテゴリごとに整理すると表 88-1 のようになる [2] 表 88-1 探索的テストにおけるテスト管理の現状テスト管理のカテゴリ"

さゆりおとじま
5 years ago
Views:

1 先進的な設計検証技術の適用事例報告書 2017 年度版 SEC Session Based Test Management による探索的テストの実践 1 ~ 受託開発でも探索的テストを管理し活用できる ~ 1. 概要当社はシステムインテグレーターとして多くの顧客に対してシステムの受託開発を行っている昨今はビジネス環境の変化に伴いシステム開発に対して開発スピードの向上とコストの低減がこれまでより強く求められるようになっている [1] 当社は顧客のニーズにこたえるためソフトウェア開発における生産性向上を目指し多くの取組みを実施している特にソフトウェアテストについてはバグの摘出効率が優れている探索的テストの活用を目指している具体的には従来から実施しているテストケース表を用いた記述式テストに対し探索的テストを補完的に用いることでバグの摘出工程を早め手戻りを抑止することを推進している一般的には探索的テストは品質向上や生産性向上を目指す多くの組織に注目活用されているしかし当社のようなシステムの受託開発を行う業者における探索的テストの採用事例は少ない探索的テストは記述式テストとは異なり事前にテストケースを作成しないためテストの総量や実施範囲が不透明でありテスト管理が難しいことが原因の 1 つと考えられる本事例では探索的テストに管理単位を与えるため Session Based Test Management [3] と呼ばれるテスト管理の考え方を用いて受託開発の中で探索的テストを活用できるようにした事例を紹介する 2. 取組みの目的 2.1. 解決すべき課題と目標記述式テストでは多くの場合事前に作成したテストケースの数を用いてテストの進捗や実施度合いを管理している当社においてもプロジェクトマネージャーや開発の委託元である顧客に対してテストケース数を用いた進捗報告やテスト結果報告を行うことが多い一方探索的テストでは事前にテストケースを作成しないためテストの総量や実施範囲が不透明となってしまい前述のような報告を実施しにくい特に受託開発においてはプロジェクトマネージャーや顧客が適時にテストの進捗状況や結果を把握することで開発しているシステムの全体計画や開発に関与する多数のチームメンバーと調整を行うことが多く探 1 事例提供 : 株式会社 NTT データ熊川一平氏 1

2 索的テスト特有の不透明さが受け入れられ難いこのような探索的テストにおけるテスト管理の問題を JSTQB Foundation Level のシラバスに従いテスト管理のカテゴリごとに整理すると表 88-1 のようになる [2] 表 88-1 探索的テストにおけるテスト管理の現状テスト管理のカテゴリ探索的テスト実施時のテスト管理上の問題点 (JSTQB Foundation Level シラバスより ) テスト計画作業と見積もりテストの内容や作業量はテスターに依存しておりテストの総量がわからないテスト進捗のモニタリングとコントロール総量が不明確なためテストの進捗状況を把握することができないテストの実施内容がテスターに依存しており不透明になっているテスト組織明確な役割 ( ロール ) が存在せずテストの管理はテスター任せとなっている構成管理どのバージョンのアプリケーションに対してどの程度テストを行ったかわからないリスクとテストテストの実施順序や優先度はテスター任せであるインシデント管理テストに関する記録がなくインシデントを引き起こした背景が伝わらない軽微なインシデントや改善項目の報告が乱発しており開発者の混乱を産んでいるそこで受託開発においてプロジェクトマネージャーや顧客が探索的テストの導入を前向きに検討できるように記述式テストにおけるアウトプットやテスト管理の方法を参考にテスト管理のカテゴリごとに改善目標を定義し取組みを行うこととした具体的な改善目標は表 88-2 の通り表 88-2 探索的テストにおけるテスト管理の改善目標テスト管理のカテゴリ改善目標 (JSTQB Foundation Level シラバスより ) テスト計画作業と見積もり事前にリソース割り当てを計画できること作業量の見積もりができることテストの開始 / 終了基準が明確にできることテスト進捗のモニタリングとコントロール進捗状況をメトリクスで確認できることテストレポートが残されることテストの結果やレポートによって方向性をコントロールできることテスト組織テストに関わる担当者の役割 ( ロール ) が明確とできること構成管理テスト対象アプリケーションのバージョンごとにテストを行った総量が確認できることリスクとテストテストの優先度が設定できることリスクの再評価が可能であることインシデント管理開発担当者や関係者に必要に応じて問題の特定抽出解決に向けたフィードバックができること 2

テストをセッションと呼ばれる時間枠に分割し管理単位としているセッションは 30 分 ~2 時間程度の時間枠でありセッションごとにテストの目的を定義するまた探索的テストではテストチャーターと呼ばれるテストの範囲や目的観点などを整理したドキュメントを用いることがある Session Based Test Management ではセッションごとにテストチャーターを設定することで

3 88 Session Based Test Management による探索的テストの実践 3. 取組みの対象適用技術手法評価計測 3.1. 方法論 ( どんな技術手法を用いて実施したか ) 表 88-1 および表 88-2 を俯瞰するとテストの実行単位を持たないことが探索的テストにおけるテスト管理の難しさであることがわかるそこで探索的テストに管理単位を与えるため Session Based Test Management と呼ばれる手法に着目した [3] Session Based Test Management ではテストをセッションと呼ばれる時間枠に分割し管理単位としているセッションは 30 分 ~2 時間程度の時間枠でありセッションごとにテストの目的を定義するまた探索的テストではテストチャーターと呼ばれるテストの範囲や目的観点などを整理したドキュメントを用いることがある Session Based Test Management ではセッションごとにテストチャーターを設定することで探索的テストであってもテストを実施した範囲や総量観点などを後から把握することができるそこで我々は Session Based Test Management の概念を取り入れ時間枠 ( セッション ) ごとにテストチャーターとレポート様式を兼ねたセッションシートを準備することで図 88-1 のようにテストの実施前にテスト管理者がある程度テストの内容を指示することやテストの実施後に内容を振り返れる状態を目指した図 88-1 セッションシートを用いたテスト管理またテスター 1 人あたりの 1 日に実施するセッション数の目標値を定めることでテスト期間内に実施可能な目標セッション数を割り出すことができる目標セッション数に対するセッションシートの消化率を管理することでテストの進み具合を把握することも目指した具体的には図 88-2 のようにテスターが 1 日に実施する最大セッション数を 3 セッションと定めテスターの人数とテスト期間から目標セッション数を設定した最大セッション数を 3 3

セッションとしたのは Session Based Test Management の考え方において 1 セッションの最大時間を 2 時間とおいているため業務時間内で無理なく実施できるように考慮したこととテスターの集中力が持続できる限界値を考慮したためである探索的テストのようにヒューリスティックなテストではテスターは機械的な作業を行うわけではなくテストに集中し

4 セッションとしたのは Session Based Test Management の考え方において 1 セッションの最大時間を 2 時間とおいているため業務時間内で無理なく実施できるように考慮したこととテスターの集中力が持続できる限界値を考慮したためである探索的テストのようにヒューリスティックなテストではテスターは機械的な作業を行うわけではなくテストに集中しより多くのバグを見つけるために思考を巡らせる必要があるこれまでに探索的テストを実施したテスターにヒヤリングを行い集中力の持続できる限界を検討した結果 1 日 3 セッション程度までが妥当だと判断した図 88-2 セッションによるテストの予実管理記述式のテストではテスト対象ごとに実施したテストケースの数や見つかったバグの数バグの原因分類などによる分析を行い弱点と思われる箇所に対して品質を強化するために追加のテストを検討することが多い一般的にはバグは偏在していると考えられるためより効率的にテストを進めるためにはテストの実施状況や発見されたバグの原因の偏りを見てテストを実施する対象やテストの実行回数などを柔軟に変更できたほうが望ましいまた重大なバグが見つかった場合に他の機能でも同様のバグがないか確認できるのも重要である探索的テストにおいてもこういった状況にあわせたテストの方向性の制御が実現できることを目指した具体的にはテスターにセッション中に見つかったバグや思いついたバグのヒントになりそうな点をセッションシートに記入してもらうようにしたテスト管理者は図 88-3 のように日々セッションシートのレポートを確認しテスターのレポートから気づきを得ることで新たなセッションシートを作成し随時テストの方向性を制御できる例えば類似した機能間で見つかったバグの傾向を見てセッションシートを追加することでより効率的にバグを見つけられるように方向性を制御することができるまたテスト対象ごとの 4

88 Session Based Test Management による探索的テストの実践実施セッション数の偏りや 1セッションあたりのバグ数などを確認することでバグのありそうなことを類推してテストの追加を検討できるこのようなテストの実施状況の確認やバグの摘出傾向からの分析方向性の制御はテスト管理者とテスターの間で日次の情報共有会を行い

1 で示した方法論を用いて以下の 2 つのシステム開発プロジェクトにおいて探索的テストの導入を試みた我々はプロジェクトにおけるテスト方針の検討支援メンバとして参画し探索的テストの導入を推進した具体的にはいずれのプロジェクトにおいてもあらかじめテスト管理者テスターの両者に対して探索的テスト自体の考え方の研修を開催すると共に Session

5 88 Session Based Test Management による探索的テストの実践実施セッション数の偏りや 1セッションあたりのバグ数などを確認することでバグのありそうなことを類推してテストの追加を検討できるこのようなテストの実施状況の確認やバグの摘出傾向からの分析方向性の制御はテスト管理者とテスターの間で日次の情報共有会を行いその中で情報を収集することで実現した図 88-3 セッションシートによるテストの方向性制御 3.2. 対象プロジェクト 3.1 で示した方法論を用いて以下の 2 つのシステム開発プロジェクトにおいて探索的テストの導入を試みた我々はプロジェクトにおけるテスト方針の検討支援メンバとして参画し探索的テストの導入を推進した具体的にはいずれのプロジェクトにおいてもあらかじめテスト管理者テスターの両者に対して探索的テスト自体の考え方の研修を開催すると共に Session Based Test Management の考え方を整理し当社の開発標準に組み込むためのガイドラインドキュメントを作成の上提供した (1) 金融機関向け審査システムの保守開発当社にて保守を行っている Web システムに対しての機能追加を行うプロジェクトでありリリース後のバグや仕様不備に対する品質強化施策として探索的テストを導入した (2) 教育機関向け学生管理システムのシステム更改クライアント-サーバ型の現行システムからパッケージソフトを利用した Web システムへと更改するプロジェクトであり早期バグ摘出による後続のテスト工程の安定化を目指して探索的テストを導入した 5

6 3.3. 取組みの評価取組みの評価にあたってはテスト実施期間中の日次の情報共有会やプロジェクトの進捗会議模様を確認すると共にテスト実施期間終了後にアンケートやインタビューを行うことで情報を収集したここでは 3.2 で示したプロジェクトのうち (2) 教育機関向け学生管理システムのシステム更改での事例を取り上げる当プロジェクトではテスト全体の計画を行う際に事前にアサインできるテスターの人数テスト実施できる日数を定め探索的テストを行う目標セッション数を導出したテストの進捗管理は目標セッション数に対しての差分を管理することで進み具合遅れ具合を評価した具体的には図 88-4 のように残存セッション数を週次単位でグラフによって図示することを試みて進捗の遅れ具合を素早く察知できるようにした当該プロジェクトではテスターの繁忙によりセッション数の消化に若干の遅延が見られたためプロジェクトマネージャーによりテスターの追加や期間の見直しなどの対処が指示され進捗管理モニタリングの観点から適切なマネジメントが行われていることが確認できた図 88-4 試行プロジェクトでのテスト進捗管理グラフまたテストの実施状況とバグの摘出状況の確認として 1 セッションあたりの摘出バグ数を機能ごとに図 88-5 のようにグラフで整理したこの結果特定の機能でのバグが多く摘出されていることや重大バグの発生状況の偏りを把握することができ後続のセッションで実施するテストの内容を変更したり前工程で実施していた記述式のテストや設計工程の内容の見直しを行ったりと状況に合わせた柔軟な対応を行うことができた 6

7 88 Session Based Test Management による探索的テストの実践図 88-5 試行プロジェクトでのバグ摘出状況管理グラフ ( 一部情報をマスク ) このように観察されたテスト管理の改善状況に加えテスト実施後のアンケートやインタビューの結果を踏まえて表 88-2 に示した改善目標に対しての改善状況を表 88-3 の通り整理した表 88-3 目標に対しての改善状況 7

8 いずれの改善目標に対しても本取組みの成果が発揮されていることがわかるまたインタビューで得たテスト管理者テスターの意見を下記に示す特にセッションという管理単位が導入されたことでテスト全体に統制がもたらされたといった意見やテスト管理者テスターだけでなくプロジェクト全体を統括するプロジェクトマネージャーなどの理解を得やすくなったという意見が目立ったここでは取り上げていないが 3.2 で示したもう1つのプロジェクトでも同様の状況が観察されており本取組みの成果が狙い通りかつ十分に発揮できたと考えているインタビューで得た意見テスト管理者セッションという定量的な見方ができることでその日のノルマが見えるようになり 1 日のテスト実施量をキープできたプロジェクトマネージャーや顧客に報告する立場としてセッション数という区切りがあったのがよかった見つかったバグから記述式のテストに新たな観点を追加するなどの改善を行うことができシステムの品質向上に寄与できたテスターセッションごとに指示が明確であり迷わずにテストを行うことができたセッションごとに報告を行うためテストの内容が多様になりがちな探索的テストであっても報告が容易であったまたテスト管理者テスター間で行う日次の情報共有会において各テスターが実施したテストの内容や見つかったバグ気になった箇所などの報告を行うことでテスター間でノウハウの共有が行われたこれによりバグの摘出効率を更に引き上げるという副次的な効果が得られたと推測している本取組みの施策を適用しなかった探索的テストに比べ取組みを適用したいずれのプロジェクトでも時間あたりのバグ摘出数が改善されていることが確認できた 4. 取組み実施上の問題対策工夫 Session Based Test Management の考え方ではテストの管理単位となるセッションの定義や内容が統制された状態となることが重要である例えば同じ 1 時間のセッションであってもテスト実施のための準備 ( テストデータの作成や環境の変更など ) を行う時間が長いセッションと短いセッションでは実施できたテストの濃度が異なるまた探索的テストではテストチャーターによる指示があるとはいえテスターがバグを探索しているうちに予めテストチャーターで指定されたテストのスコープをはずれてしまうことがあるこのようにセッションごとの内容にブレが生じてしまうとセッションあたりのバグ数などの情報が 8

9 88 Session Based Test Management による探索的テストの実践実際の状況とかい離してしまう可能性があるそこで当社では Session Based Test Management の導入時に予め以下のようなルールを策定している (1) テスターがバグの探索を進めるうちに 1 つのセッションに 2 時間以上必要なことが分かった場合テスターはその旨をテスト管理者に報告すること報告を受けたテスト管理者はセッションの分割を行うこと (2) 原則としてセッション中は探索的テスト以外の業務を行わないこと (3) セッション中にテスト実施にどの程度の時間をかけたか概算で報告を行うことテスト管理者は報告された時間を確認し当該セッションの取り扱いの濃淡を定めることまた必要に応じてテスト実施の時間ができるだけ多く確保できるようにテスターの困りごとを解決すること (4) テスターはバグが見つけられそうであればテストチャーターにて指示されたスコープを外れたテストを行ってよい但しセッションごとにテストチャーターにどの程度したがってテストを行ったかを % で示す概算で報告を行うことテスト管理者は報告された数値を確認し必要に応じてセッションシートの内容をテスターが実際に行ったテストに合わせるように書き換えることこのようなルールを定めることで実際に行われたテストの内容とテスト管理のために事後に収集する情報との間でかい離が起きないように努めている 5. 今後の取組み本取組みでは探索的テストにおけるテスト管理の改善に着目し受託開発において要求されるテストの客観性を担保することを試み一定の成果を出すことができた本書を参考に探索的テストが管理できないテストであるという誤解が解決されシステムの受託開発における受発注者間で探索的テストの価値が認められ探索的テストの採用が進むことを期待したいまたシステム開発のスタイルや方法は今後も大きく変化していくことが予想される技術の進化に伴いシステムに求める要件を記載すれば自動で対応するソフトウェアを作成するような未来もあるかもしれないしかしどれだけ開発技術が進化しようともシステムやソフトウェアが期待していたものと違いないことを確認するためにはその要求の出元である人間に依存せざるを得ない探索的テストのようなヒューリスティックなテストはそのような状況でも非常に有効な技術であると予想する今後は探索的テストの管理面だけでなくヒューリスティックな側面に着目しその人のシステムソフトウェアに対する潜在的なニーズや要求をより効果的に引き出す方法などの改善を進めていくことを検討している 9

10 参考文献 [1] 経済産業省, 平成 22 年度企業の IT 投資動向に関する調査報告書 ( 企業 IT 動向調査 ), 経済産業省商務情報政策課, 日本,2011 年. [2] International Software Testing Qualifications Board, テスト技術者資格制度 Foundation Level シラバス日本語版 Version 2011.J02, Japan Software Testing Qualifications Board,2012 年. [3] Bach James, Session-Based Test Management, 掲載されている会社名製品名などは各社の登録商標または商標です独立行政法人情報処理推進機構技術本部ソフトウェア高信頼化センター (IPA/SEC) 10

目次取組み概要取組みの背景取組みの成果物適用事例の特徴適用分析の特徴適用事例の分析結果から見えたこと JISAによる調査結果どうやって実践のヒントをみつけるか書籍発行について紹介今後に向けて 2

目次取組み概要取組みの背景取組みの成果物適用事例の特徴適用分析の特徴適用事例の分析結果から見えたこと JISAによる調査結果どうやって実践のヒントをみつけるか書籍発行について紹介今後に向けて 2 品質改善に取り組めば生産性もアップ ~ ソフトウェア開発技術適用事例のデータ分析から見えてきたこと ~ 2016 年 5 月 12 日独立行政法人情報処理推進機構技術本部ソフトウェア高信頼化センターソフトウェアグループ連携委員春山浩行 1 目次取組み概要取組みの背景取組みの成果物適用事例の特徴適用分析の特徴適用事例の分析結果から見えたこと JISAによる調査結果どうやって実践のヒント