SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス～日本の品質管理技術を見直そう」
【告知】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でアジャイルにテストする」: プログラマの思索 ht
TestLinkの要件管理機能 - プログラマの思索
TestLinkの要件管理機能についてメモ。 【元ネタ】 要件のテスト - watawata日記 TestLinkの可能性: プログラマの思索 要求管理(要件管理)ツール RaQuest 要求管理ツールRaQuest・要求項目の作成 要求管理ツールRaQuest・ツリーと一覧を駆使した要求項目の効率的な管理 要求管理ツールRaQuest・要求の追跡 TestLinkの機能とV字モデルの関係 (Testlinkjp-users) - TestLink日本語化 - SourceForge.JP テスト管理ツールTestLinkには不十分だが、要件管理機能が付いている。 TestLinkCnvMacroを使えば、TestLink要件をTestLinkキーワードを経由して、TestLinkテストケースとN対Nの関係に持ち込むことができる。 この紐づけによって、要件カバレッジが可能になり、キーワード
TestLinkメモ - 科学と非科学の迷宮
今週の金曜にShibuya.tracに参加しようと思います。 手ぶらで参加するのもあれなので、この3ヶ月ほどTestLinkを使って気づいたことをまとめようと思います。 使ったきっかけ テスターの要員確保してないプロジェクトで、いきなりテストしてくれって言われてどうしようかと悩んでいたときに、「そういや昔TestLinkってのをブックマークしたっけ」と思い出し、使ってみようと思ったのが始まり。 書き方メモ tracとの対応 tracのコンポーネントとトップレベルスイートを大体1:1対応させる。 trac上でタスクとして定義しているチケットごとにテストスイートを作成する。 テストケースには以下の内容を書く。 概要:対応するチケットへのリンク貼るだけでいい。補足説明いるなら追加。 実行方法:どのユーザでログインするか、どのブラウザを使うか、どのオブジェクトを対象にアクセスするかを明確に書く。例
TestLinkの運用例part2 - プログラマの思索
allpair法をTestLinkに使う方法が書かれた記事があったのでメモ。 【元ネタ】 TestLinkメモ - 科学と非科学の迷宮 AllPair法で作成したテストケースをTestLinkにテストケースとして読み込むツールallpairs2testcase.rb - Rubyの魔神 - はてな？Rubyグループ allpair法は、組み合わせテストのテストケース作成技法の一つで、同じ値のペアが最低1回現れるように組み合わせてテストケースを作成する方法。 直交表に比べると、テストケース数を少なくできる。 実際のテストケース作成時は、複数の入力項目の組合せテストが非常に多い。 例えば、組込製品やパッケージ製品ならば、ドライバやOSのバージョンを組み合わせたテストケースを作っているだろう。 業務システムならば、業務のパターンや状態を組み合わせてテストケースを作りこんでいるだろう。 実際の現場
TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理 - プログラマの思索
TestLinkでテストケースを作りこんで、テストしていくと、色んなことに気付く。 TestLinkでテストしていきながら感じたことをメモ。 【1】ウォーターフォール型開発では、下流工程にテストが来る。 単体テスト、結合テスト、システムテスト(総合テスト)、受入テストの違いをきちんと使い分けているだろうか？ テストは基本的に、V字モデルの左側の工程の検証作業になる。 単体テストは開発工程の検証だが、結合テストの違いは何だろうか？ 単体テストは、最低限動作することを保証すること。 Exceptionが発生するようでは話にならない。 ホワイトボックステストで、最低限、分岐網羅(C1)を検証する。 だから、コードカバレッジが非常に重要になる。 結合テストは、複数のモジュール同士を結合して動作するのを検証する。 普通のプロジェクトでは、結合テストで火を噴くことが多い。 理由は、結合テストになって初
TestLinkを運用して気付いたことpart10～テストの制約条件 - プログラマの思索
TEF関西のNakaさんの話を聞いて考えたことをメモ。 【元ネタ】 ソフトウェアテスト標準用語集 日本語版Ver 1.3 普通のプロジェクトは結合テストで火を噴く。 理由は、結合テストで初めて、システムが稼動するのを顧客も開発者も見れるから。 そこで、初めて、要件漏れ、認識相違、仕様漏れに気付く。 でも、それだけの理由だけではないという指摘を受けた。 ソフトウェアテスト標準用語集 日本語版Ver 1.3には「プロダクトリスク」「プロジェクトリスク」の用語解説がある。 プロダクトリスクとは、「テスト対象に直接関係するリスク」。 プロジェクトリスクとは、「（テスト）プロジェクトの管理（マネジメント）と制御（コントロ－ル）に関係するリスク。例えば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。」 実際のテスト、特に結合テスト、システムテスト、受入テストのようにプロジェクト後半になる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
