【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」
ETWest2009の講演資料「TestLinkでアジャイルにテストする」を公開します。
CC Attribution ライセンスとします。
上記の講演で、TestLinkを半年間運用してみて、経験したこと、理解できたこと、そして確信したことは全て書いた。
一番言いたい事は、TestLinkがアジャイル開発の弱点の一つである受入テストを補強してくれることだ。
テスト駆動開発や継続的インテグレーションのプラクティスで単体テストの品質は保証できるが、結合～受入テストの品質を確保するのは、ウォーターフォール型開発だけでなくアジャイル開発でも難しい。
その問題の本質は、二つある。
一つは、受入テストの自動化は難しいこと。
もう一つは、手動の受入テストの生産性が悪いこと。
TestLinkの導入によって、手動の受入テストを効率化できると確信している。
だが最終的な目標である受入テストの自動化は、TestLinkだけでは足りない。
それを実現するには、テスト環境の仮想化と並行ビルドの技術が鍵を握ると思う。
そのアイデアは下記に書いた。
プロジェクト管理やテスト工程をクラウド化する: プログラマの思索
RedmineやTestLink、Hudsonなどのツールを駆使してソフトウェア開発していくに従って、問題の難易度が上がってきた気がしている。
ソフトウェア開発に銀の弾丸はないけれど、プロセスのレベルが上がるに従って、ソフトウェア開発の本来の問題点に少しずつ近づいてきたような気がしている。
ソフトウェア開発は、製造業や営業とは異なる本質的な特徴とそこから生じる根本問題がやっぱりあるのだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2～プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1～CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか？～プロマネの仕事はテーラリングにある(2022.06.19)
「コミュニティ」カテゴリの記事
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- デブサミ2023の感想(2023.02.11)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- XPエクストリームプログラミングは偉大だ～時代がその設計思想に追いついた(2022.11.16)
- 第23回東京Redmine勉強会の感想～コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
「ソフトウェア工学」カテゴリの記事
- QAエンジニアの役割は開発チームのガードレールみたいなものという考え方(2023.08.21)
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- 「ゲームをテストする バグのないゲームを支える知識と手法」の感想(2023.06.10)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
「TestLink」カテゴリの記事
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
コメント
すばらしいスライドですね
ひとつ聞きそびれてしまいました。
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