【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」
ETWest2009の講演資料「TestLinkでアジャイルにテストする」を公開します。
CC Attribution ライセンスとします。
上記の講演で、TestLinkを半年間運用してみて、経験したこと、理解できたこと、そして確信したことは全て書いた。
一番言いたい事は、TestLinkがアジャイル開発の弱点の一つである受入テストを補強してくれることだ。
テスト駆動開発や継続的インテグレーションのプラクティスで単体テストの品質は保証できるが、結合~受入テストの品質を確保するのは、ウォーターフォール型開発だけでなくアジャイル開発でも難しい。
その問題の本質は、二つある。
一つは、受入テストの自動化は難しいこと。
もう一つは、手動の受入テストの生産性が悪いこと。
TestLinkの導入によって、手動の受入テストを効率化できると確信している。
だが最終的な目標である受入テストの自動化は、TestLinkだけでは足りない。
それを実現するには、テスト環境の仮想化と並行ビルドの技術が鍵を握ると思う。
そのアイデアは下記に書いた。
プロジェクト管理やテスト工程をクラウド化する: プログラマの思索
RedmineやTestLink、Hudsonなどのツールを駆使してソフトウェア開発していくに従って、問題の難易度が上がってきた気がしている。
ソフトウェア開発に銀の弾丸はないけれど、プロセスのレベルが上がるに従って、ソフトウェア開発の本来の問題点に少しずつ近づいてきたような気がしている。
ソフトウェア開発は、製造業や営業とは異なる本質的な特徴とそこから生じる根本問題がやっぱりあるのだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
「コミュニティ」カテゴリの記事
- みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない(2021.01.14)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 増刷記念「ここはウォーターフォール市、アジャイル町」の裏話の感想~日本人はフレームワークが苦手でいつも振り回されている(2020.11.19)
- 第19回東京Redmine勉強会の感想 #redmineT(2020.11.14)
- 「製造業アジャイル、静岡での実践!」を聞いてRedmineはコミュニケーション管理ツールなのだと気づいた #devlove #静岡ギルド(2020.11.11)
「ソフトウェア工学」カテゴリの記事
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
「TestLink」カテゴリの記事
- テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか(2020.11.02)
- TestLinkにExcelのテスト項目書をインポートする方法(2017.06.01)
- TestLink Tutorialのリンク(2016.03.12)
- TestLinkで手動テストや自動テストの結果を統合してレポートさせる手法(2016.01.31)
- エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること(2015.03.14)
コメント
すばらしいスライドですね
ひとつ聞きそびれてしまいました。
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