テスト計画
突撃となりのテスト計画
〜こんなときお隣さんはどうしてる?〜
2016/1/9 WACATE実行委員会 福良智明
自己紹介
自己紹介
▪名前:福良 智明(ふくら ともあき)
▪twitter: @kikituki
▪勤務先:SIer
▪普段の業務:
▪社内受託案件の品質向上をミッションとし、PJのテスト
工程担当する部署に所属(以前は開発)
▪テスト計画の立案からテストの実施、管理や炎上案件
の火消しまでテスト・品質に関わることなら何でも行う
▪WACATEとの関わり:
▪2009〜2014 参加者として6回参加
▪2015〜 実行委員として参加
はじめに
セッションの対象者
▪テスト初心者
▪テスト計画という言葉を初めて聞いた人
▪言葉だけ聞いたことがある人
▪テスト担当者
▪テストの設計をされている方
▪テストケースの作成や実施されている方
▪開発者としてテストを実施されている方
▪テスト管理者
▪テスト計画を立案されている方
▪テストの管理をされている方
セッションの目的
▪テスト初心者
▪テスト計画について知る
▪セッションを通じて感じた疑問・悩みを共有して、他の人から
知見を得る
▪テスト担当者
▪テスト計画の意図を知る
▪普段困っていることや課題・悩みを共有して、他の人から知
見を得る
▪テスト管理者
▪より有効なテスト計画を立案する為のヒントを得る
▪普段困っていることや課題・悩みを共有して、他の人から知
見を得る
アジェンダ
1. テスト計画とは
2. テストの課題
3. ワーク1
テストにまつわる疑問・課題・悩みを共有しよう
4. 課題の原因
5. 計画立案時のポイント
6. ワーク2
ポイントを意識してみんなで対策を考えてみよう
7. PFDを用いたテスト計画立案
8. 本日のまとめ
1.テスト計画とは
1-1.テスト計画の定義と目的
SQuBOK Guide V2 – 2.18.1.6
【定義】
テスト計画は、プロジェクトで実施されるテスト活動の目的や
スケジュールの定義など、テストにおける計画活動全般を指す。
テスト活動はこのテスト計画に基づき実施され、管理される。
テスト計画は品質計画の一部である。
【目的】
プロジェクトにおけるテスト活動の指針やプロセス、ゴールとそれに
至る手段を明確にし、実現可能な実施計画を作成し、テスト管
理活動全般への情報を提供する。
1-1.テスト計画の定義と目的
【成果物】
テスト計画書(※ドキュメント化することは必須ではない)
【作成時期】
▪ テストプロセスの最初の計画とコントロールのフェーズで作成
▪ プロセスが進むにつれ新たな仕様の追加や変更、計画に影響に
及ぼすような問題が発生した場合は、テスト計画も忘れずに更
新する
計画
コントロール
分析/設計 実装・実行 評価 終了作業
要件定義 基本設計 詳細設計 実装 テスト
1-2.テスト計画で決めること
▪テスト計画で定義する項目(ISO/IEC/IEEE29119)
1. テストのコンテキスト
2. テストのコミュニケーション
3. テストのリスク
4. テスト戦略
5. テストの活動と見積もり
6. 人材の配置
7. スケジュール
1-2.テスト計画で決めること
1. テストのコンテキスト
プロジェクトやテストアイテム、スコープ、制約や前提条件を定
義する
2. テストのコミュニケーション
テストを実施する上でのコミュニケーションルールを定義する
※コミュニケーションルール:会議体や連絡ルールなど
3. テストのリスク
プロジェクトリスク、プロダクトリスクと対策を定義する
※プロジェクトリスク…PJのマネジメントに関するリスク(リソース不足等)
プロダクトリスク…テスト対象に関するリスク(機能が動かない)
1-2.テスト計画で決めること
4. テスト戦略
テストのプロセスや成果物、使用するテスト設計技法、
開始・完了基準などを定義する
5. テストの活動と見積もり
タスクの洗い出しと工数の見積もりを定義する
6. 人材の配置
タスクに対して、人材の割り当てを定義する
7. スケジュール
スケジュールやマイルストーンを定義する
1-2.テスト計画で決めること
▪ 注意点
▪ISO/IEC/IEEE29119、IEEE829などの国際的な規格をそのま
ま使えばOKではなく、各組織やPJごとにテーラリングし、最適化して
利用する
▪国際的な規格と違っても、組織にあった社内規格があって上手く
回っているのであれば問題ない
▪テスト計画は立派な体裁のドキュメント作成することが大切なのでは
なく、必要な事項について十分に検討して計画することが大切
1-3.テスト計画書の例
項番号 項目名
1 概要(範囲)
2 リスク
3 実施するテストレベル
4 テスト対象機能・テスト非対象機能
5 アプローチ(テスト戦略)
テストレベルごとの観点・合否基準など
6 成果物
7 体制
8 スケジュール
記載項目
1-3.テスト計画書の例
テスト対象
の定義
1-3.テスト計画書の例
テスト対象
外の定義
1-3.テスト計画書の例
全体とテストレベル
ごとの戦略
1-3.テスト計画書の例
テストレベルごとに
観点などを定義
1-3.テスト計画書の例
テストレベル
ごとに成果物
を定義
1-4.テスト計画を立案する効果
【効果】
実施すべき作業とスケジュール、ゴールが明確になることでテスト
活動を円滑に実施し、管理を行うことができる。
▪ テストに関する行動の指針(判断の拠り所)である
▪ 効果的かつ効率的なテストを実施できるかどうかは
このテスト計画にかかっているといっても過言ではない
【テスト計画(書)とは】
ここまでで、テスト計画は大事なんだなというこ
とが分かって頂けたと思います
テストプロセスの中に計画フェーズもあるし、みなさ
んはテスト計画を活用できていますよね?
また、テスト計画に従って実施しているので、テスト
は万事上手くいってますよね?
1-5.理想と現実
1-5.理想と現実
しかし、現実は・・・
なかなか厳しい
ですよね?
(もちろん上手くいっている方もいると思います)
実際のPJでは、どんな問題が起こっているのでしょうか?
2.テストの課題
2-1.テストあるある
こんなシーンって身近に
ありませんか?
2-1.テストあるある
【シーン1】
テスト初心者なんですが…
▪これテストしといてって指示されたんだけど、何からすれば
良いか分からない(自信がない)
▪そもそもテストって何を確認すれば良いのか分からない
(自信がない)
こんなシーンを経験したことのある方?
2-1.テストあるある
【シーン2】
テスト管理者なんですが…
▪テスト計画を立ててと言われたけれど、どう考えたら良い
か分からない
▪品質を評価する為に、どんなメトリクス、指標をみれば
良いのか分からない
こんなシーンを経験したことのある方?
2-1.テストあるある
【シーン3】
テスト担当者としてPJにアサインされたんだけど…
▪必要な作業が明確になっておらず、何をすれば良いか
分からない
▪テスト仕様書に不明点があるのだけれど、誰に聞けば
(どこの設計資料を見れば)良いか分からない
▪必要なデータ(機材)が準備されておらず、テストを始め
られない
こんなシーンを経験したことのある方?
2-1.テストあるある
【シーン4】
テスト仕様書を渡されたので、内容を見てみると…
▪何を確認したいのか意図が良くわからない
▪同じような観点のテストを重複して実施されたり、必要
だと思われる観点が抜けている気がする
▪テスト観点がテスト対象やPJの特性にマッチしていない
(影響がない機能もテスト範囲に含まれているなど)
こんなシーンを経験したことのある方?
2-1.テストあるある
【シーン5】
テスト仕様書に従ってテストを実施してみると…
▪実施結果やエビデンスをどのような形式で残せば良いの
か分からない
▪不具合を発見したので、バグ票を作成しようと思ったが、
何をどのように記載すれば良いか分からない
こんなシーンを経験したことのある方?
2-1.テストあるある
【シーン6】
テスト実施完了!ようやく休める…と思った矢先
▪受入テスト初日でクリティカルな不具合が発生!検出
すべき不具合がテストで検出できていなかった
▪テスト終了後も不具合が多発し、追加でテストを実施
することになった
▪お客様にテストを完了とした根拠の説明を求められたが、
説明できなかった
こんなシーンを経験したことのある方?
2-1.テスト計画あるある
この他にもまだいろいろと
困ったなって経験があると
思います
3.ワーク1
テストにまつわる疑問・課題・悩みを共有
しよう
3.ワーク1
このワークでは、皆さんが普段抱えているテストに
まつわる課題や悩み、疑問を共有していただきます
※テスト計画にこだわる必要はありません。
過去にこんなことで困ったよというレベルでOKです。
3.ワーク1
▪ワーク1の進め方
個人ワーク(10分)
グループワーク(10分)
個人で洗い出して
みよう
他の人のを
みてみよう
3.ワーク1-1
まずは個人で問題・疑問・悩みを付箋に書き出
してみましょう!
▪ 先ほどの例で挙げたものと重複していても問題ありません。
▪ テスト計画にこだわる必要はありません。
▪ 過去にこんなことあったよというレベルでOKです。
10分
3.ワーク1-2
先ほど書き出した問題・疑問・悩みを共有してみ
ましょう!
他の人はどんなことをどんなことを考えているのか
みてみましょう。
10分
※初参加の方→参加回数の少ない方(同じであれば年齢が若
い方)→ベテランさんの順で共有していきましょう
3.ワーク1-2 (成果物イメージ)
3.ワーク1
みなさん お疲れ様でした。
自分悩みは伝えられましたか?
同じことで悩んでる方はいましたか?
他の方が悩んでることが伝わりましたか?
次は、これまで挙げた課題がなぜ起こるのかを考
えてみて、テスト計画を立案する際のポイントにつ
いてみていきます。
4.原因はなにか
4-1.原因はなにか
なぜこのようなことが起こ
るのでしょうか?
4-1.原因はなにか
上手く行かなくなってしまったPJを
ヒアリングしてみると、こんな共通点
がみえてきました・・・
4-1.原因はなにか
▪そもそもテスト計画を立案せず、なんとなく個人の過去
の経験や社内の慣習に基づいてテストをしている
原因1
テスト計画を立てていない
▪テスト計画書をつくってはいるが、記載内容のPJ名と実
施期間、個人名などを変えただけのもの
テスト計画について知らない
テスト計画の重要さに気づいていない
4-1.原因はなにか
▪テスト計画書をPJ開始時に作成しているが、作成して
から誰も見ていないし、更新もされない
原因2
テスト計画が運用されていない
テスト計画を活用できていない
4-1.原因はなにか?
つまりは、活用するに値するテスト
計画を立案できていない
4-1.原因はなにか?
テスト計画を立案する際に気を
付けるべきポイントとはなにか?
5.テスト計画のポイント
5-1.テスト計画立案時のポイント
ソフトウェアテスト293の鉄則
鉄則:278
テスト計画は戦略、段取り、成果物の
三位一体と心得よ
“テスト計画では、戦略、段取り、成果物の3つの要素を
明確にすることが大切”
5-2.戦略
重要な問題を多く発見するために
▪どの範囲をテストするか
▪どこに重点をおいてテストするのか
▪どのテスト技法を用いるのか
▪バグが出たことをどのように認識するのか
▪どのようにテストの目的を達成するのか
を定義する
5-2.戦略
【戦略を定義する効果】
▪テストの指針が明確なり、目的の達成に向けて、効率
的なテストを実施することができる
▪戦略を定義し、共有することで、認識のずれを無くすこ
とができる
先ほどのシーン4、6の状況を予防する助けとなる
5-2.戦略
5-3.段取り
テスト戦略を実現するために、
▪どのようにリソースを適用するか
▪誰が・いつ・何をするのか
▪成功させるためには何が必要か
を定義する
5-3.段取り
【段取りを定義する効果】
▪テスト工程全体を見える化できる。
▪作業の抜け漏れを防ぐ。(特に事前準備)
▪テスト計画の更新タイミングが明確になる
先ほどのシーン1、2、3の状況を予防する助けとなる
5-3.段取り
5-4.成果物
テストの成果を
▪どのようにして顧客に見せるか
▪どのようにバグを管理するのか
▪どんなドキュメント作成するのか
▪何の為に作成するのか
を定義すること
5-4.成果物
【成果物を定義する効果】
▪成果物の抜け漏れを防ぐ
▪各作業の成果物が明確になる
先ほどのシーン5、シーン6の状況を予防する助けとなる
5-4.成果物
5-5.規格との対応
それってテスト計画のどこで
考えれば良いの?
5-5.規格との対応
テスト計画の各項目は何を記載しているのか?
ISO/IEC/IEEE29119との対応付け
項番号 項目名 戦略 / 段取り / 成果物
1 テストのコンテキスト 戦略
2 テストのコミュニケーション 段取り
3 テストのリスク 戦略
4 テスト戦略 戦略
5 テストの活動と見積もり 戦略 / 段取り / 成果物
6 人材の配置 段取り
7 スケジュール 段取り
5-6.まとめ
テスト計画を立案する際は、
▪各項目の意図・目的(戦略 or 段取り or 成果物)
を意識する
▪意図・目的が分かったら、その項目の定義を満たすよ
うな内容にする
ことでこれまでみてきた課題を改善する助けとなる
戦略・段取り・成果物を意識してテスト計画を立案し
てみましょう
6.ワーク2
ポイントを意識して対策を考えてみよう
6.ワーク2
ここまでの内容を踏まえて、ワーク1で挙げた問
題・疑問・悩みに対する対策やアドバイスを考え
てみましょう
6.ワーク2
▪ワーク2の進め方
グループワーク(10分)
グループワーク(5分)
整理してみよう
対象を絞り込もう
グループワーク(10分)
改善案を
考えてみよう
6.ワーク2-1
ワーク1であげた課題をグループ分けします。
対象の課題が、戦略・段取り・成果物・その他の
どのグループに属するかを考えてみる
▪ 例1:テスト計画が更新されない
→ 段取り かなぁ
▪ 例2:テストの方針が良くわからない
→ 戦略 かなぁ
▪ 例3:テスト結果の記載内容がばらばら
→ 成果物 かなぁ
6.ワーク2-1(成果物イメージ)
戦略 段取り 成果物 その他
10分
※掲示するので〇〇班と記載をお願いします
6.ワーク2-1(参考資料)
戦略
段取り
成果物
6.ワーク2-2
次に、課題の対策を考えてみます。
まず、グループのみんなが興味がある課題を1つ、2つ選
んでみましょう。
5分
6.ワーク2-3
では、実際に課題の対策を考えてみましょう。
今回は、戦略・段取り・成果物という観点で考えてみま
しょう。
考え方としては、
1. 選択した課題のグループの定義を確認
2. 定義のどの要素が欠けているかを確認
3. その要素を満たす方法を考える
6.ワーク2-3
▪例1:テスト計画が更新されない
1. グループは、段取り が該当
2. “いつ・誰が・何を“が決まっていない
3. “いつ・誰が・何を“を決める方法を考える
テスト計画を更新するタイミングをプロセスの中に組み込
み“いつ・誰が・何を“更新するかテスト計画段階で定義
してみる
6.ワーク2-3
▪例2:テストの方針が分からない
1. グループは、戦略 が該当
2. “どのようにテストの目的を達成するか“が決まってい
ない
3. アプローチを考える
テストのアプローチ(どこをどうテストすることで品質を確認
するのか)をテスト計画段階で定義しよう
6.ワーク2-3
▪例3:テスト結果の記載内容が分からない
1. グループは、成果物 が該当
2. “どんなドキュメントを作成するか“が決まっていない
3. ドキュメントの種類と書き方を考える
ドキュメントごとに記載内容のテンプレートと記入例・運
用ルールを計画段階で決めておく
戦略 段取り 成果物 その他
6.ワーク2-3(成果物イメージ)
対策案
対策案
対策案
10分
6.ワーク2-3(参考資料)
戦略
段取り
成果物
6.ワーク2
お疲れ様でした。
課題に対して、対策案をあげることができましたで
しょうか?
※今回作成した資料は、本会開催中ずっと掲
示しておきますので、他の班で出た疑問や悩み
についてアドバイスがあればお願いします!
7.PFDを用いた
テスト計画立案
(私が行った改善の例)
ここでは、戦略・段取り・成果物を意識したテスト
計画の立案する際に、
PFD(プロセスフローダイアグラム)
をツールとして用いる方法を紹介します
7-1.PFDとは
7-1.PFDとは
▪清水吉男さんが考案された成果物とプロセスの
連鎖を表現するためのツール
▪プロセス改善だけでなく、見積りやスケジューリン
グにも利用できる
▪詳細は、
ソフトウェアエンジニアのための“硬派”のブログ
(http://kohablog.cocolog-
nifty.com/blog/pfd.html)
を参照
7-2.PFDの記法と私の記載手順
プロセス
(作業)
成果物
成果物
成果物
成果物
入力 出力
必要な作業と必要な成果物の関係から
全体の作業を設計していく
7-3.段取りと成果物の検討手順
事前条件
テストの戦略(方針)を決める
-----------------------------------------------
1.成果物を定義する
2.その成果物の作成に必要な作業を検討する
3.2で抽出した作業に必要な成果物を定義する
-----------------------------------------------
以降2〜3を繰り返して、必要な作業と成果物を定義
していくと全体の作業(段取り)と成果物が明確になる
7-3. 段取りと成果物の検討手順
例:
結合テスト
実施結果
結合テスト
実施
結合テスト
仕様書
結合テスト
データ
結合テスト
データ作成
結合テスト
仕様書作成
1.成果物を定義2.必要な作業
を定義
3.必要な成果物
を定義
2.必要な作業
を定義
7-4. 実例の紹介
実際に業務で作成したPFDを紹介します
7-5.PFDを用いるメリット
▪最終成果物までの作業と必要な成果物を見
通すことができる(ゴールまでの道のりを共有)
▪成果物と作業の関係が表現されているので、1
つ1つの作業の目的が明確になる
▪事前の準備不足を予防できる
▪全体が見通せていることで、安心感がある
7-6.作成時のポイント
▪最終成果物から逆算することで必要最低限の
作業・成果物に絞り込むことができる
8.本日のまとめ
8.本日のまとめ
▪テスト計画は大切なのは分かっているがなかな
か上手くいっていないのが現実
▪有効なテスト計画の立案する際のポイントの1つ
として、戦略・段取り・成果物を意識するやり方
がある
▪段取り・成果物の定義にはPFDを用いると便利
8.本日のまとめ
やり方は1つではありません。
せっかくの機会ですので、知
見を共有して、みんなで前
に進んでいきましょう!
ご清聴ありがとうございました

テスト計画セッション

Editor's Notes

  • #8 5分
  • #13 プロジェクトリスクとは    プロジェクトのマネジメントとコントロールに関係するリスク。    たとえば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。 プロダクトリスクとは    テスト対象に直接関係するリスク。    機能が動作しないなど