【告知】SEA関西プロセス分科会で「TestLinkのベストプラクティス」を講演します: プログラマの思索 http://forza.cocolog-nifty.com/blog/2010/12/seatestlink-714.html 【公開】SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス～日本の品質管理技術を見直そう」: プログラマの思索 http://forza.cocolog-nifty.com/blog/2011/01/seatestlink-85a.html ETWest2009講演資料「TestLinkでアジャイルにテストする」 http://www.slideshare.net/akipii/etwest2009testlink-1537780 【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」: プログラマの思索 http://forza.cocolog-nifty.com/blog/2009/06/etwest2009testl.html 【告知】TestLinkでアジャイルにテストする: プログラマの思索 http://forza.cocolog-nifty.com/blog/2009/05/testlink-84bd.html

1. TestLinkの
ベストプラクティス
日本の品質管理技術を見直そう
2011/1/15
第43回 SEA関西プロセス分科会
あきぴー＠XPJUG関西
(copyright2010 akipii@XPJUG関西)
1

2. 自己紹介
チケット駆動開発の本を出
版しました
TestLinkによるテスト管理も
解説してます
現在 絶賛販売中
(copyright2010 akipii@XPJUG関西)
2

3. Agenda
ソフトウェアテストの課題
Agile開発におけるテストの課題
TestLinkとは
プラクティス一覧
【1】テスト計画
【2】テストケース
【3】テストマネジメント
【4】ビルド・リリース管理
【5】テスト結果集計
TestLink運用上の注意点
まとめ
(copyright2010 akipii@XPJUG関西)
3

4. ソフトウェアテストの課題
ソフトウェアテストのマネジメントはとても難しい
テスト工程で人員が最大化する
Excelによるテスト管理は大変
テスト作業のステータスや進捗を最新化しにくい
テスト結果の集計に手間がかかる
仕様変更によるテストケース修正が追いつかない
ワークフロー管理が意外に難しい
一斉号令してテストを始めたり中止する作業が多い
バグが多発した場合、同じテストケースの再検証が多い
難しい割にはテスト技術が重視されていない
(copyright2010 akipii@XPJUG関西)
4

5. Agile開発におけるテストの課題
テスト管理は小規模リリースが有効でない
反復型開発が主流
システム全体を広く浅くテストする作業を何度も繰り返す
テストは計画主導
結合テスト～受入テストは自動化しにくい
チケット駆動開発(TiDD)はテスト管理に向いていない
テストケース≠チケット(障害報告票)
テスト工程の進捗管理がやりにくい
・テストのAgile化は難しい
化は難しい
・テストの
・全てのテストの自動化は難しい
・手動のテストの生産性が悪い
(copyright2010 akipii@XPJUG関西)
5

6. TestLinkとは
オープンソースのテスト管理Webシステム
システム
オープンソースのテスト管理
http://testlinkjp.org/
最新版：1.9 (2011/1)
テストケース・テスト作業・テスト集計を一括管理できる
数千～数万のテストケースを登録・実行・集計できる
Excelのテスト仕様書をWeb化できる
(copyright2010 akipii@XPJUG関西)
6

7. TestLinkの戦略
TestLinkを主に手動の受入テストで使う
単体テストはJunitでテスト自動化
結合テスト以降は業務シナリオでテストする
テスト計画をXPのイテレーションに見立てる
テストケースをテスト計画単位にグループ化する
テスト計画のテストケースを全て成功にしたらリリースでき
るように運用する
同じテスト計画を複数回実施して回帰テストも可能
失敗したテストケースの検証はBTSと連携する
バグ修正はRedmineチケットで管理する
バグ検証はTestLinkテストケースで再テストする
(copyright2010 akipii@XPJUG関西)
7

8. TestLinkの使い所
手動の機能テストや受入テス
トの作業をサポートするのに
使う
但し、TestLinkは癖が
は癖が
但し、
あるのでノウハウが必要
(copyright2010 akipii@XPJUG関西)
8

9. テストは反復型開発
Plan
Plan
Plan
Build
Build
前半の工程は
漸進型開発で動く
モジュールを作る
Build
Review Deploy
Test
Test
Test
Review
Review
イテレーション1
漸進型開発
Review
イテレーション2
反復型開発
後半の工程は、
テスト計画をイテレーション
に同一視して、
に同一視して、
Agileにテストしていく
にテストしていく
System
Test
Review Deploy
イテレーション3
反復型開発
(copyright2010 akipii@XPJUG関西)
User
Acceptant Review Deploy
Test
9

10. プラクティス一覧 (Nakaさん)
五月雨テスト
後追いテスト
受入テスト
テスト消化曲線
バグ収束曲線
テストスイートで分割
要件カバレッジ
計画作成
登録
集計表示
TestLink
継続的
インテグレーション
更新
終了
Hudson
ブロック
みなしNG
みなし
みなしOK
みなし
ブロッキングバグ
残存バグ
同種バグ
みなしバグ
周辺テスト
Redmine
(copyright2010 akipii@XPJUG関西)
10

11. 【1】テスト計画
(copyright2010 akipii@XPJUG関西)
11

12. TestLinkのテスト計画の構造
テスト計画は実施するテストケース一式
ビルドはテスト結果の単位
テスト対象モジュールのビルド番号(バージョン)
テストスイートはテストケースの階層
テスト仕様はテストケースの貯蔵庫(バックログ
バックログ)
テスト仕様はテストケースの貯蔵庫 バックログ
過去のテストケースを再利用して回帰テストに使う
(copyright2010 akipii@XPJUG関西)
12

13. テスト計画の考え方
テスト作業をテスト計画で分割する
テスト計画をイテレーションに見立てて2～4週間単位でテストしていく
例：2～4週間のイテレーションで小刻みにテストしていく五月雨テスト
テスト作業をビルドで分割する
納品モジュールのバージョンとテスト結果を対応付ける
例：テスト結果や障害をバージョン単位に履歴を残していく受入テスト
プロダクトリスクを最優先
テスト対象(プロダクト)に直接関係するリスク
例：業務や社会に影響する障害が出ないように最優先でテスト
プロジェクトリスクは後回し
プロジェクト管理とマネジメント制御に関するリスク
例：人員不足・工数不足でできないテストは、リリース直前に後追いテスト
(copyright2010 akipii@XPJUG関西)
13

14. 五月雨テストと後追いテスト (Nakaさん)
(1)五月雨テストはテ
五月雨テストはテ
スト計画をイテレーショ
ンに同一視する。
(2)後追いテストはプ
後追いテストはプ
ロダクトリスクの低い
テストをリリース直前
に行う。
(copyright2010 akipii@XPJUG関西)
14

15. 五月雨テストと受入テスト
(Nakaさん)
五月雨テスト
(開発者の観点
開発者の観点)
開発者の観点
(copyright2010 akipii@XPJUG関西)
15

16. 五月雨テストと受入テスト
(Nakaさん)
五月雨テスト
(開発者の観点
開発者の観点)
開発者の観点
受入テスト
(発注者の観点
発注者の観点)
発注者の観点
(copyright2010 akipii@XPJUG関西)
15

17. 【2】テストケース
(copyright2010 akipii@XPJUG関西)
16

18. TestLinkとテスト仕様書
テストケースはExcelで作ってTestLinkにインポートする
既存のExcelのテスト仕様書を流用できる
テスト作業やテスト結果はTestLinkで一括管理
リアルタイムにテスト作業や進捗を把握できる
(copyright2010 akipii@XPJUG関西)
17

19. TestLinkテストケースの作り方
テストケースをTestLinkの形式に合わせる
テストスイートでテストケースを階層化する
テストケースと要件を対応づけておく
過去に使ったテストケースは貯蔵しておく
2次開発や運用保守で回帰テストに使う時が多い
要件やテストケースはTestLinkCnvMacroで一括イン
ポートする (http://sourceforge.jp/projects/testlinktools/releases/)
要件やテストケースはExcelであらかじめ作成しておく
インポート後はTestLink上で実績管理する
要件カバレッジの元ネタになる
(copyright2010 akipii@XPJUG関西)
18

20. 要件カバレッジ
テストケースの要件カ
バレッジを表示する
↓
テストケースの品質を
推測できる
(copyright2010 akipii@XPJUG関西)
19

21. 要件カバレッジ
テストケースの要件カ
バレッジを表示する
↓
テストケースの品質を
推測できる
テストに失敗した要件
を一覧表示する
↓
バグの影響度や再検
証工数を調査できる
(copyright2010 akipii@XPJUG関西)
19

22. 要件カバレッジとトレーサビリティ
要件とテストケースを紐付ければビルドモジュールまで辿れ
トレーサビリティ)
る(トレーサビリティ
トレーサビリティ
要件カバレッジを使えば、テストケースの品質も向上できる
仕様変更や障害の影響調査に使える
(copyright2010 akipii@XPJUG関西)
20

23. 【3】テストマネジメント
(copyright2010 akipii@XPJUG関西)
21

24. バグの考え方
プロダクトリスクに含まれるバグ
ブロッキングバグはプロダクトリスクが高いので最優先に潰す
プロジェクトリスクに含まれるバグ
後追いテストでカバーする時が多い
残存バグ
テスト工程で発見されないないバグ
リリース後にプロダクトリスクの高いバグが発見されると致命
的
同類バグ(同種バグ
同類バグ 同種バグ)
同種バグ
既存バグと同一原因の残存バグ
発見したバグの周辺には必ず同類バグや他のバグが残って
いる
同類バグ調査が非常に重要
(copyright2010 akipii@XPJUG関西)
22

25. 失敗テストケースはBTSと連携
バグはRedmineチケットに
チケットに
バグは
登録する
⇒失敗したテストケースは必
ずRedmineチケットを持つ
チケットを持つ
(copyright2010 akipii@XPJUG関西)
23

26. テストケースの全バグを確認
・BTSチケットのステータスをリアルタイムに表示
チケットのステータスをリアルタイムに表示
・オープン＝0になるまでリリース不可能
・オープン＝ になるまでリリース不可能
(copyright2010 akipii@XPJUG関西)
24

27. バグ修正のワークフロー
テスター
バグ検証
完了
バグ検証
チケット起票
PG
バグ修正
テストケースとBTSチケットのワークフロー対応が重要
チケットのワークフロー対応が重要
テストケースと
TestLinkの失敗テストケース検証はBTSのワークフロー管理に含まれる
テスターとPGが自発的に連携作業を行うのが可能
バグが多発した場合、TestLinkのブロックを有効に使う
のブロックを有効に使う
バグが多発した場合、
依存するテストケースは一旦保留として後回し
テスト工数を無駄に浪費しないため
(copyright2010 akipii@XPJUG関西)
25

28. ブロックとは
(Nakaさん)
テストの事前条件を満たさないためテスト不能なテストケース
例：失敗したテストケースに依存したテストケース
※参考：ソフトウェアテスト標準用語集 日本語版
(copyright2010 akipii@XPJUG関西)
26

29. テスト方法に出てくる概念
(Nakaさん)
みなしNG
みなし
失敗したテストケースに依存して失敗が予定されているテストケース
あえて失敗ステータスへ更新して、開発チームをビビらせる時もある
ブロッキングバグ
ブロック元の失敗したテストケースのバグ
ブロック数が多いほどブロッキングバグの重要度が高い
みなしバグ
ブロックしたテストケースの機能に含まれるバグ
ブロッキングバグの同類バグ調査が重要
みなしOK
みなし
テストせずに成功ステータスにする
テストケースを間引くために使う
後追いテストでテストする時が多い
周辺テスト
ブロッキングバグ周辺の成功ステータスのテストケースを回帰テスト
(copyright2010 akipii@XPJUG関西)
27

30. みなしNG・ブロッキングバグ・みなしバグ
(Nakaさん)
テストケースの状態に応
じて、
マネジメントのやり方を
臨機応変に変える
(copyright2010 akipii@XPJUG関西)
28

31. 【4】ビルド・リリース管理
(copyright2010 akipii@XPJUG関西)
29

32. 継続的インテグレーションとは
テスト工程では回帰テストが本来多い
例：再検証、デグレ確認
常時リリース可能な
モジュールを維持で
きる点が重要！
(copyright2010 akipii@XPJUG関西)
30

33. 継続的インテグレーション(CI)の可能性
並行ビルド
大規模化するほどCI
に時間がかかる
Hudsonのジョブでビ
ルド作業を並行でき
ないか？
環境の仮想化
リリース作業を簡単
にしたい
受入テストの自動化
回帰テストを自動化
(copyright2010 akipii@XPJUG関西)
31

34. 【5】テスト結果集計
(copyright2010 akipii@XPJUG関西)
32

35. 250
200
150
テスト消化曲線
バグ収束曲線
100
50
2010/4/21
2010/4/19
2010/4/17
2010/4/15
2010/4/13
2010/4/11
2010/4/9
2010/4/7
2010/4/5
2010/4/3
0
2010/4/1
残テストケース数/累積バグ数
テスト消化曲線とバグ収束曲線
テスト実施日
から)
テスト消化曲線は時系列単位の残テストケース数(TestLinkから
から
から)
バグ収束曲線は時系列単位の累積バグ数(BTSから
から
SRATS(Excelマクロ)からMTBFも計算可能
http://www.rel.hiroshima-u.ac.jp/okamu/SRATS/
(copyright2010 akipii@XPJUG関西)
33

36. バグ収束曲線から分かる傾向
品質：安定 (?)
→残存バグを除去
できている(?)
できている
品質：不安定
→典型的なデスマー
チプロジェクト
品質：何とか安定
→コストオーバー
メトリクスの過信に注意しましょう！
(copyright2010 akipii@XPJUG関西)
34

37. 金曜にコミットが多いアンチパターン
http://www.statsvn.org/stat
svn/developers.html
StatSVN - Repository
Statistics - Ruby
生産性が低いために週末に作業のピークが来る
バグが多発すると学生症候群に陥りやすい
作業効率や品質が良ければ、そもそも残業も休日出勤も必要ない
(copyright2010 akipii@XPJUG関西)
35

38. TestLink運用上の注意点
テストの観点をTestLinkテスト計画に対応づける
複数回のリリースを前提にテストケースを分割する
テスト計画を各種テスト(結合・負荷etc)に対応付ける
ビルド単位にすれば、発注者の受入テストで有効
例：外部委託、オフショア開発したモジュールをSIが受入テスト
テスト工程にも制約やクリティカルパスがある
ブロッキングバグはボトルネックそのもの
ブロッキングバグが数件あるだけで即テスト不能になる
バグ修正/検証にBTSのワークフロー管理を上手に使う
テストケースの品質が重要
テストケースの網羅性が低いとTestLinkの生産性も落ちる
各種テストケース作成技法を使ってみる
例：直交表、All Pair法、原因結果グラフ
(copyright2010 akipii@XPJUG関西)
36

39. TestLinkは発展途上
ユーザインターフェイスは使い易いとは言えない
VerUpしながら少しずつ改善されている
テストケースを一括修正しにくい
Ver1.8以降はTestLinkCnvMacroの一部機能しか使えない
Excelのテスト仕様書と連動させたい
ステータス管理を強化したい
ブロック元の失敗テストケースへリンクしたい
依存するテストケースをサスペンドリンクで視覚化
ステータス(検証中 etc.)をもっと増やしたい
テスト集計機能をもっと強化できる
テスト消化曲線をリアルタイムに表示
テスト工数を入力すれば、工数集計や予実比較も可能
(copyright2010 akipii@XPJUG関西)
37

40. まとめ・謝辞
テストを制する者はSW開発を制する
テスト管理や障害管理はSW開発で最も難しい
テスト管理はプログラミングとは異なる技術
本来は計画駆動だがAgile化も可能
回帰テストや同類バグ分析が重要
テスト管理はもっとIT化すべき
Excelのテスト仕様書で複雑なマネジメントは無理
イテレーション、ブロック、テスト結果の履歴管理、要件カバレッジ
テスト技術で設計やプログラムの品質を上げる
謝辞
TEF関西の皆さん
(copyright2010 akipii@XPJUG関西)
38