TestLinkのベストプラクティス集 - プログラマの思索
TestLinkでテスト管理を運用してみて、ベストプラクティスを自分なりにまとめてみた。 あくまでも下記は僕が経験したこと、理解できたことに過ぎないので、間違っていたらコメント下さい。 【元ネタ】 脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所 TestLinkのFAQ: プログラマの思索 テスト手法の概念をTestLinkで説明する: プログラマの思索 TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索 TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索 TestLinkを受入テストで運用する方法: プログラマの思索 【1】ブロック テストケースの事前条件が、失敗したテストケースに依存しているためにテスト不能になった状態を指す。 ブロッ
TestLinkをユーザ企業が使う時の注意点 - プログラマの思索
下記の記事を読んで、TestLinkは本来、ユーザ企業が発注した業務システムを、ユーザ企業自身が受入テストで使うべきだと思った。 以下メモ書き。 【元ネタ】 TestLink を使ってみた - hokorobiの日記 TestLinkJP - TEF有志によるテスト管理システムTestLink日本語化プロジェクト 僕は、TestLinkをテスト工程のうち、結合～システムテストで運用している。 実際は、単体テスト完了したモジュールをリリースする前に、開発部隊が自分たちで業務シナリオベースのテストケースを作り、それでもってテストしている。 つまり、リリース前の品質保持のためにTestLinkを使っている。 でも本来は、ユーザ企業自身がTestLinkを使って、発注した業務システムを受入テストで使うべきなのだ。 理由は、ユーザ企業も受入テストというテスト工程を自身が関与しなければ、システム開発は
【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」 - プログラマの思索
ETWest2009の講演資料「TestLinkでアジャイルにテストする」を公開します。 CC Attribution ライセンスとします。 上記の講演で、TestLinkを半年間運用してみて、経験したこと、理解できたこと、そして確信したことは全て書いた。 一番言いたい事は、TestLinkがアジャイル開発の弱点の一つである受入テストを補強してくれることだ。 テスト駆動開発や継続的インテグレーションのプラクティスで単体テストの品質は保証できるが、結合～受入テストの品質を確保するのは、ウォーターフォール型開発だけでなくアジャイル開発でも難しい。 その問題の本質は、二つある。 一つは、受入テストの自動化は難しいこと。 もう一つは、手動の受入テストの生産性が悪いこと。 TestLinkの導入によって、手動の受入テストを効率化できると確信している。 だが最終的な目標である受入テストの自動化は、Te
TestLinkを運用して気付いたことpart4～TestLinkの概念を再考 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
TestLinkを運用して気付いたことpart5～TestLinkのテストケースの概念 - プログラマの思索
TestLinkのテストケースの概念についてのメモ書き。 【元ネタ】 TestLink 実戦投入 - かおるんダイアリー TestLinkの「テストケース」も「テスト計画」と同様に、「ビルド」(回帰テストの実施結果)と1対多の関係になる。 「テストケース」の状態遷移図を考えると、下記のようなフローになる。 アサイン前→未実行→成功 or 失敗 or ブロック 「アサイン前」の「テストケース」は「テスト仕様」にあるが「テスト計画」にアサインされていない状態。 つまり、イテレーション計画に組み込まれていないので、TestLinkへただ貯めている状態になる。 「未実行」の「テストケース」は「テスト計画」にアサインされて、いつでもテストを開始できる状態。 テスターは担当の「テストケース」をフィルタリングして、どんどんテストをこなしていく。 テストケースがいつも「成功」ならば良いが、やはり「失敗」す
TestLinkにあるアジャイルの概念 - プログラマの思索
下記の記事を読んで気づいたことをメモ。 【元ネタ】 TestLinkを検証しました ― ありえるえりあ 【引用】 テストケースの管理と、テスト計画(=テスト実施の記録)の管理のふたつの軸があるのがポイントです。 RDBアプリ風に言えば、前者がマスター(リソース)、後者がトランザクション(イベント)的な構造です。 テストケースは手順と期待値の記述で、何度も実施されればその度ごとに結果レコードができます。 テストケースの1レコードに対して、実施結果のレコードは1対多の関係で存在します。 テストケースと実施結果が1対多の関係になるのは、言われてみれば自然で当り前の構造なのですが、バグトラッキングシステム(BTS)とは違うんだという現実に改めて気づきました。 昔、wishlistもBTSで管理している話を書きました(http://dev.ariel-networks.com/Members/ino
TestLinkを検証しました - ありえるえりあ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
naturalsoftware.jp