【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」
ETWest2009の講演資料「TestLinkでアジャイルにテストする」を公開します。
CC Attribution ライセンスとします。
上記の講演で、TestLinkを半年間運用してみて、経験したこと、理解できたこと、そして確信したことは全て書いた。
一番言いたい事は、TestLinkがアジャイル開発の弱点の一つである受入テストを補強してくれることだ。
テスト駆動開発や継続的インテグレーションのプラクティスで単体テストの品質は保証できるが、結合~受入テストの品質を確保するのは、ウォーターフォール型開発だけでなくアジャイル開発でも難しい。
その問題の本質は、二つある。
一つは、受入テストの自動化は難しいこと。
もう一つは、手動の受入テストの生産性が悪いこと。
TestLinkの導入によって、手動の受入テストを効率化できると確信している。
だが最終的な目標である受入テストの自動化は、TestLinkだけでは足りない。
それを実現するには、テスト環境の仮想化と並行ビルドの技術が鍵を握ると思う。
そのアイデアは下記に書いた。
プロジェクト管理やテスト工程をクラウド化する: プログラマの思索
RedmineやTestLink、Hudsonなどのツールを駆使してソフトウェア開発していくに従って、問題の難易度が上がってきた気がしている。
ソフトウェア開発に銀の弾丸はないけれど、プロセスのレベルが上がるに従って、ソフトウェア開発の本来の問題点に少しずつ近づいてきたような気がしている。
ソフトウェア開発は、製造業や営業とは異なる本質的な特徴とそこから生じる根本問題がやっぱりあるのだ。
| 固定リンク
「TestLink」カテゴリの記事
- TestLinkを受入テストで運用する方法(2009.12.11)
- 特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係(2009.12.06)
- TiDDを実践して気づいたことpart4~TestLinkによるテスト戦略(2009.11.30)
- TiDDを実践して気付いたことpart3~繰り返し開発の戦略(2009.11.29)
- 開発に30分、テストに10万年(2009.11.28)
「コミュニティ」カテゴリの記事
- Ruby関西とiPod(2006.01.29)
- Redmine勉強会(2009.05.30)
- 【公開】XP祭り関西2009講演資料「チケットファーストでアジャイル開発!~チケットに分割して統治せよ」(2009.02.21)
- 【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」(2009.06.05)
- 【告知】TestLinkでアジャイルにテストする(2009.05.03)
「ソフトウェア工学」カテゴリの記事
- Mercurial以前と以後のチケット駆動開発(2009.12.15)
- メトリクスでソフトウェア品質を見える化する(2009.12.15)
- TiDDを実践して気づいたことpart4~TestLinkによるテスト戦略(2009.11.30)
- TiDDを実践して気付いたことpart3~繰り返し開発の戦略(2009.11.29)
- 開発に30分、テストに10万年(2009.11.28)
「プロジェクトマネジメント」カテゴリの記事
- チケット駆動開発のアンチパターンpart2(2009.12.02)
- TiDDを実践して気づいたことpart4~TestLinkによるテスト戦略(2009.11.30)
- TiDDを実践して気付いたことpart3~繰り返し開発の戦略(2009.11.29)
- アドレナリンジャンキー (2009.11.19)
- ビジネスもSW開発プロセスも鈍重になっていく(2009.11.21)


コメント
すばらしいスライドですね
ひとつ聞きそびれてしまいました。
TestLink と Redmine を連携させるとき、TestLink で失敗 -> Redmine に登録 -> TestLink に登録の作業は手作業でやっていますか?
今回 Trac で同じことをやろうとしたんですが、数が多いのと時間がかかるので断念してしまいました^^;
投稿: かおるん | 2009/06/05 23:30
当然、下記で運用してます。
TestLinkテストケースで「失敗」
-> Redmineチケットに「新規」登録
-> Redmineチケットが「解決」
-> TestLinkの再テストが「成功」したら、Redmineチケットを「検証完了」にする
-> PLが最終確認後「完了」にする
この運用フローができてから、バグ修正フローが非常にスムーズになりました。
上記が運用しづらい理由がよく分かりません。
「数が多い」のは「一つの失敗テストケースで、登録するチケットが複数個あり多い」のでしょうか?
「時間がかかる」のは「チケットに登録するのに時間がかかる」のでしょうか?
あえて言うならば、RedmineもTracもBTSなので上記の運用は本来の使い方だと思うのですが。。
投稿: あきぴー | 2009/06/06 09:28