Toshiyuki Kawanishi
tosik****@users*****
2008年 12月 18日 (木) 14:24:52 JST
あきぴーさん 川西です。 実用に即したご質問ありがとうございます！ > 以前、JaSST関西にて「ビルド＝製造番号」と聞いていましたが、 >「Testlinkのビルド＝HudsonのビルドNo」で > 運用できるんですね。 > その話から、Testlinkのビルドの概念が理解できて、すっきりしました。 良かったです。あくまで運用の一例ですが、 CIと組み合わせる場合は、それで問題ないと思います。 # 以前は、Subversionで作成したタグの名称を TestLinkのビルド名として登録していました。 他にも、インストーラを作成してくれる構成管理ツールなども ビルド番号を振ってくれるでしょうから、 各プロジェクトに合わせて そのような番号を登録すれば良いと思います。 > しかしながら、以前の質問のように、 > Testlink上で要件からテストケースを1個ずつ作成して、要件とテストケースを > 紐付けするのは、ケース数の桁が数千〜数万の場合、非現実的です。 確かに、その通りなんですよね...... 私もそこまで要件管理機能を活用できていない状況です。 そこで、Tracなどのプロジェクトを管理するためのツールと 連携するための何かしらを作ってみようと思っています。 （すみません。私はRedmineよりもTracを使っているもので......） XPのストーリー（SCRUMのプロダクトバックログ）を 要件として登録していければなと考えています。 ということで、個人的には、 アジャイル的な運用を考えるプロジェクトにおいては、 今ある要件を一気にTestLinkに インポートして運用するというよりも、 今後、洗い出したストーリー（プロダクトバックログ）や、 イテレーションに関係あるストーリーを登録していって、 それを既存のテストケースに紐付けるなり それをベースにテストケースを作成する といったことを考えています。 # Hudsonの事例と違って、これはまだ準備中で、 これから実行してみようと思っている段階です。 > あるいは、Testlink1.8では、 > 要件管理の機能が大幅強化されているでしょうか？ TestLink 1.8 では要件管理のUIは改善されていますが、 文書名登録-->要件登録-->テストケースと紐付け もしくは 文書名登録-->要件登録-->テストケース作成 という流れは変わりません。 カスタムフィールドや要件とテストケースの関連の扱いに関しては 今後のTestLinkの課題になってくるのかなと思います。 # ただ、紐付けをインポートするための一般的な フォーマットを考えるというのは難しいというはあると思います。 上手い方法が無いかどうか考えてみます。 何かアイディアがあればご教示ください。 以上、よろしくお願いします。 Toshiyuki Kawanishi <tosik****@users*****> --- > 川西さん > > あきぴーです。 > 下記のご回答ありがとうございます。 > > 以前、JaSST関西にて「ビルド＝製造番号」と聞いていましたが、「Testlinkのビルド＝HudsonのビルドNo」で > 運用できるんですね。 > その話から、Testlinkのビルドの概念が理解できて、すっきりしました。 > > もう一つだけ、Testlinkの要件管理機能についてご質問させて下さい。 > > 今の僕はTestlinkの要件管理は使っていませんが、マスタデータは揃っているので、次回からTestlinkに > インポートして運用したいと考えています。 > > しかしながら、以前の質問のように、Testlink上で要件からテストケースを1個ずつ作成して、要件とテストケースを > 紐付けするのは、ケース数の桁が数千〜数万の場合、非現実的です。 > > 川西さんや他のコミッタの方は、要件管理をどのように運用しているのでしょうか？ > あるいは、Testlink1.8では、要件管理の機能が大幅強化されているでしょうか？ > よろしければ、運用例を教えて頂けると助かります。 > > Testlinkの要件管理を使いたい動機は下記の通りです。 > > >> >> 今、自分が書いたテスト仕様書は、テストケースの行に必ず要件管理IDの欄を > >> >> 追加しています。 > >> >> 理由は、テストの目的や観点を明確にして、お客様に説明するためです。 > >> >> つまり、僕の環境では、テストケースと要件管理IDを紐づけるマスタデータは > >> >> 揃ってます。 > >> >> 狙いは下記のトレーサビリティです。 > >> >> > >> >> 要件(Testlink)→テストケース(Testlink)→【チケット】(Redmine)←ソース(Subversion) > >> >> > >> >> 上記のトレーサビリティができれば、設計漏れや要件漏れという上流工程の不具合は > >> >> テスト仕様書の作成工程で潰せると思います。 > > 今、Redmine＋Testlinkで結合テストや受入テスト、障害修正は非常にスピードアップできてます。 > しかし、バグ発生の原因を探ると、確かにPGMミスもありますが、仕様漏れや設計漏れ、他機能への > 影響の考慮漏れ、など、上流工程や変更管理の品質の方に問題があると思ってます。 > > その対策として、Testlinkの要件管理を使いたいのです。 > > 質問ばかりで申し訳ありませんが、よろしくお願いします。 > > 2008/12/17 14:17 Toshiyuki Kawanishi <tosik****@users*****>: > > あきぴーさん > > > > > > 川西です。 > > > >> Redmineパッチの修正ありがとうございました。 > >> 更に、Redmineロードマップ画面と同じく > >>「<取消線>検証完了</取消線>-バグ修正」と表示されて、非常に > >> 使いやすくなりました。 > > > > 早速、ご確認ありがとうございます！ > > 一応私の環境では確かめたのですが、 > > あきぴーさんの環境でも大丈夫だったようで安心しました。 > > > > # Tracを使った場合も同様のバグがあるようですので、 > > 今晩にでも時間を見つけて修正します。 > > > > > >> 以前の川西さん、梶野さんのご回答から推測すると、 > >> ビルドとテスト計画は下記の認識で合っているでしょうか？ > > （中略） > >> 上記のように考えると、リリース後は、テスト計画は閲覧可能とするが、ビルドはCloseして > >> テスト結果を変更できないようにするTestlinkのやり方が非常に理解できます。 > > > > 1〜3のとおりで間違いないと思います。 > > > > ただ、3については、 > > あくまでイテレーション開発をしている場合は、 > > TestLinkをそのように運用すると良いという一例だと思います。 > > > > # TestLinkの思想として > > 「TestLinkのテスト計画＝イテレーション」 > > 「TestLinkのビルド＝継続的インテグレーションで行う統合ビルド」 > > と決まっているわけではありません。 > > （念のため。） > > > > この場合は、イテレーション計画（スプリント計画）の時に、 > > どのテストを実行するか考える > > （TestLinkのテスト計画にテストケースを追加する） > > のが良いと思います。 > > > > あと、個人的な例としては、 > > 私は継続的インテグレーションサーバとしてHudsonを使っているので、 > > Hudsonが自動で振ってくれるビルド番号を > > TestLinkに登録するようにしています。 > > （毎回のビルドをTestLinkに登録している訳ではありません。 > > TestLinkで管理しているテストが必要となった時のビルドのみを > > TestLinkに登録しています。） > > > > > >> ご気分を悪くされたら申し訳ありません。 > > > > あ、すみません。全然、気分を悪くしたつもりはなかったです。 > > 念のため確認というつもりで書かせていただきました。 > > パッチがあると、 > > 割とすんなりと本家の人がOKだしてくださるもので。 > > > > # 私のメールの書き方が悪かったかもしれません。 > > 夜中に書いたもので...... > > > > > > 以上、よろしくお願い致します。 > > > > > > Toshiyuki Kawanishi <tosik****@users*****> > > > > > > --- > >> 川西さん > >> > >> あきぴーです。 > >> Redmineパッチの修正ありがとうございました。 > >> 更に、Redmineロードマップ画面と同じく「<取消線>検証完了</取消線>-バグ修正」と表示されて、非常に > >> 使いやすくなりました。 > >> > >> 下記の件、ご丁寧なアドバイス並びにご指摘ありがとうございます。 > >> Testlink日本語分科会の人達はとても親切なので、下記の要望をあげたら実現してくれるかな、とちょっと > >> 甘えた部分があったかと思います。 > >> ご気分を悪くされたら申し訳ありません。 > >> > >> ビルドの考え方について再質問させて下さい。 > >> 以前の川西さん、梶野さんのご回答から推測すると、ビルドとテスト計画は下記の認識で合っているでしょうか？ > >> > >> 1.ビルドごとにテストケースをアサインすることはできない。 > >> > >> 2.ビルドは、テスト計画にアサインされたテストケースを回帰テストで管理するためにある。 > >> (１の機能が実装されている理由に相当する) > >> > >> #実際の運用のイメージ > >> 最初はビルドを1個だけ追加する。 > >> →ビルドに紐づいたテストケースをテストする > >> →リリース時にビルドをCloseして、テスト結果を変更できないようにする。 > >> →2回目のテスト開始時に、新たなビルドを追加する。 > >> テスト計画にアサインされた全テストケース(1回目のテストで成功になったケースも含む)をテスト開始。 > >> 1回目のテスト結果は無関係。 > >> →以下繰り返し。 > >> > >> 3.イテレーション単位にテストケースを変更してリリースするならば、そのたびにテスト計画を > >> 作って、テストケースをアサインする。 > >> > >> #実際の運用のイメージ > >> イテレーション1は機能A、イテレーション2は機能Bをリリースする計画を立てたと仮定する。 > >> > >> イテレーション1を開始 > >> →機能Aのテストケースをテスト計画1にアサインする > >> →テスト計画1へビルド1をアサインする > >> →機能Aのテスト実行 > >> →機能Aのテスト結果が全て「成功」になったら、ビルド1をCloseする > >> →イテレーション1をリリース > >> ↓ > >> →イテレーション2を開始 > >> →機能Bのテストケースをテスト計画2にアサインする > >> →テスト計画2へビルド2をアサインする > >> →機能Bのテスト実行 > >> →機能Bのテスト結果が全て「成功」になったら、ビルド2をCloseする > >> →イテレーション2をリリース > >> > >> つまり、XPやScrumのイテレーションはTestlinkのテスト計画に相当し、Testlinkのビルドは > >> XPの継続的インテグレーションで行う統合ビルド(実際のシステムのビルド)と同等であると > >> 見なしてよろしいでしょうか？ > >> > >> 上記のように考えると、リリース後は、テスト計画は閲覧可能とするが、ビルドはCloseして > >> テスト結果を変更できないようにするTestlinkのやり方が非常に理解できます。 > >> > >> 以上、よろしくお願いします。 > >> > >> 2008/12/17 0:03 Toshiyuki Kawanishi <tosik****@users*****>: > >> > あきぴーさん > >> > > >> > > >> > こんばんは。川西です。 > >> > いつもご質問ありがとうございます！ > >> > ご質問のおかげで情報が整理できて助かります。 > >> > > >> > 私の分かる範囲でですが...... > >> > > >> >> 1.テスト結果の「各テストケースの全バグ」欄にある「解決済み」「オープン」の意味は？ > >> >> テストケースが失敗→成功になっても、「解決済み」にならない。 > >> >> 失敗したテストケースに紐付けたバグが解決or検証完了になっても、「解決済み」に > >> >> ならない。 > >> > > >> > ご報告ありがとうございます！ > >> > これはTestLinkもしくはredmineパッチのバグだと思いますので、 > >> > 私の方で調べて、またご連絡します。 > >> > > >> > > >> >> 2.要件とテストケースの紐付けを一括インポートする方法はありますか？ > >> >> テストスイートXMLをインポートする時に、要件も一括インポートしたいのです。 > >> > > >> > これは手作業で行うしか無いと思います。 > >> > > >> > > >> >> 3.ビルドの使い方をもう一度教えて下さい。 > >> >> 現在は、テスト計画に追加されたテストケースは、テスト計画に紐づくビルドに > >> >> 全て表示されてしまいます。 > >> >> リリース単位でテストケースやテスト結果を管理するには、テスト計画の単位で > >> >> 管理するしかないのでしょうか？ > >> >> リリース時にビルドに紐付けたテストケースやテスト結果を変更できないようにしたい。 > >> >> つまり、ビルドをリリースするバージョンのように使いたいのです。 > >> > > >> > ビルドをクローズすると結果を登録できなくなります。 > >> > > >> > 具体的には、 > >> > ホーム-[ビルドの管理]-[<ビルド名称のリンク>]とたどって、 > >> > 「オープン」のチェックをはずし、[更新] ボタンをクリックします。 > >> > その後、 > >> > テスト結果登録画面の左上のプルダウンメニューから > >> > クローズしたビルドを選択して、[フィルターの適用] ボタンをクリックすると、 > >> > 成功/失敗/ブロックという結果を選択するボタンが非表示になります。 > >> > > >> > ですので、仰っていただいたように、 > >> > テストが終了してそのビルドをリリースした場合は、 > >> > 該当のビルドをクローズすることをおススメします。 > >> > > >> > > >> >> 過去のメーリングリストを読んだら、似たような質問をしている人もいました。 > >> >> TestlinkのUIは、Ver1.8では使いやすくなっているでしょうか？ > >> > > >> > ご存じの事と思いますが、 > >> > 最近このMLに加入していただいた方もいらっしゃいますので、 > >> > 念のため確認させていただきますね。 > >> > > >> > TestLink日本語化プロジェクトのメンバーの中でも > >> > TestLinkのコミット権を持った人が何人かいますが、 > >> > TestLink自体の機能を追加したりする > >> > 担当になっている人はいません。 > >> > 基本的なミッションとしては、UIの日本語化と > >> > デイリー＆リリース前のテストとなっています。 > >> > > >> > ですので、MLに寄せて頂いたご要望は、できる限りまとめて本家開発者に > >> > お伝えしますが、私たちが直接ソースをいじっている訳ではありません。 > >> > > >> > TestLinkに限らず、オープンソースソフトウェアに希望の機能を追加する > >> > 近道は本家開発者にパッチを送ることだという事を、 > >> > 念のため再度、確認させてください。 > >> > > >> > # 本当は頂いたご要望を直接反映できれば良いのですが、 > >> > その辺が悩ましいところです。 > >> > そういえばredmineパッチは本家のトラッカーに登録したところ、 > >> > 喜んでくれたのでコミットしました。1.8から同梱される予定です。 > >> > > >> > > >> > ご要望に関しては、ごもっともだと思いますので、 > >> > 私の方でもパッチが書けるかどうか試してみたいと思います。 > >> > 皆さんの方でも、こんなパッチが書けたよという情報がございましたら、 > >> > ご連絡いただけるとありがたいです。 > >> > その方が本家に採用されやすいですので。 > >> > > >> > # ただ、前にもお伝えした通り、個人的には > >> > バグ収束曲線などは連携した側のBTSで描くのが自然だと思います。 > >> > TestLinkでグラフを描くのであれば、仰っていただいたように、 > >> > 西山さんのExcelマクロのようなテストの進捗に関するグラフになると思います。 > >> > > >> > なお、今だと、1.8rc2のコードをベースにパッチを書いた方が > >> > 本家に採用されやすいと思います。 > >> > > >> > # 個人的には、全文検索とテストケースのバージョン間のDiffを取るための > >> > パッチを書いてみたいところなのですが、 > >> > 時間があまり取れていません...... > >> > > >> > > >> > 以上、よろしくお願いします。 > >> > > >> > > >> > Toshiyuki Kawanishi <tosik****@users*****> > >> > > >> > > >> > --- > >> >> お久しぶりです。あきぴーです。 > >> >> Testlinkを3ヶ月運用してみて、Redmineと共にプロジェクト管理をIT化するツールとして > >> >> 非常に有用だと考えてます。 > >> >> > >> >> しかし、TestlinkのUIを使いこなせなかったり、どうしても使いにくくて改善して欲しい > >> >> 機能があります。 > >> >> 以下、たくさん質問してしまいますが、よろしければ、少しでもよろしいのでご回答を > >> >> 頂けると非常に助かります。 > >> >> > >> >> 【実行環境】 > >> >> Ver 1.7.4 > >> >> > >> >> 【Testlinkの使い方について】 > >> >> 1.テスト結果の「各テストケースの全バグ」欄にある「解決済み」「オープン」の意味は？ > >> >> テストケースが失敗→成功になっても、「解決済み」にならない。 > >> >> 失敗したテストケースに紐付けたバグが解決or検証完了になっても、「解決済み」に > >> >> ならない。 > >> >> > >> >> 2.要件とテストケースの紐付けを一括インポートする方法はありますか？ > >> >> テストスイートXMLをインポートする時に、要件も一括インポートしたいのです。 > >> >> > >> >> 要件はCSVインポートで可能なのは知ってます。 > >> >> （但し、UTF8でないと文字化けする。「データ」という文字は文字化けする。） > >> >> > >> >> 要件管理IDとテストケースを紐付けるためには、要件CSVとテストスイートXMLへ > >> >> どのように連携させればよいか？ > >> >> 「テストケースを要件にアサインする」画面で手作業で行うしかないのか？ > >> >> > >> >> しかも「テストケースを要件にアサインする」画面ではテストケース単位でしか > >> >> 要件をアサインできない。 > >> >> 数千〜数万オーダーのテストケースを一括インポート後に画面上で要件に > >> >> アサインするのは非現実的です。 > >> >> せめて、テストスイート単位で、複数のテストケースを要件に一括アサインできない > >> >> でしょうか？ > >> >> > >> >> 今、自分が書いたテスト仕様書は、テストケースの行に必ず要件管理IDの欄を > >> >> 追加しています。 > >> >> 理由は、テストの目的や観点を明確にして、お客様に説明するためです。 > >> >> つまり、僕の環境では、テストケースと要件管理IDを紐づけるマスタデータは > >> >> 揃ってます。 > >> >> 狙いは下記のトレーサビリティです。 > >> >> > >> >> 要件(Testlink)→テストケース(Testlink)→【チケット】(Redmine)←ソース(Subversion) > >> >> > >> >> 上記のトレーサビリティができれば、設計漏れや要件漏れという上流工程の不具合は > >> >> テスト仕様書の作成工程で潰せると思います。 > >> >> > >> >> 3.ビルドの使い方をもう一度教えて下さい。 > >> >> 現在は、テスト計画に追加されたテストケースは、テスト計画に紐づくビルドに > >> >> 全て表示されてしまいます。 > >> >> リリース単位でテストケースやテスト結果を管理するには、テスト計画の単位で > >> >> 管理するしかないのでしょうか？ > >> >> リリース時にビルドに紐付けたテストケースやテスト結果を変更できないようにしたい。 > >> >> つまり、ビルドをリリースするバージョンのように使いたいのです。 > >> >> > >> >> 【TestlinkのUI改善要望】 > >> >> 1.テストケースへユーザをアサインする場合、選択したテストスイートで一括アサイン > >> >> できない。 > >> >> 現在のUIは、最下層のテストスイート単位でしか一括アサインできません。 > >> >> > >> >> 修正方法は、選択したテストスイートに紐づくテストケース全てをFormタグで囲む > >> >> ようにすればよいと思います。 > >> >> > >> >> 2.RedmineチケットからTestlinkのケースURLをリンクすると、Testlinkフレームが消え > >> >> ます。 > >> >> 同様に、テスト計画へケースを追加・削除、ユーザをケースへアサインするリンクを > >> >> 押して別画面を開くと、フレームが表示されないです。 > >> >> Frameの問題でしょうか？ > >> >> > >> >> 3.テストケースの内容、テスト結果、添付ファイルの全文検索が無い。 > >> >> RedmineやTracのように、全文検索機能が欲しいです。 > >> >> ITILの言う変更管理の機能を実現するために非常に重要だと思います。 > >> >> > >> >> 4.Testlinkテスト結果画面へバグ収束曲線、バーンダウンチャートを表示して欲しいです。 > >> >> 西山さんのExcelマクロをTestlink上で表示して欲しいです。 > >> >> テスト実行履歴(結果も実行時も)はDBにあるから、実装可能だと思います。 > >> >> > >> >> 5.テスト結果画面からemail送信機能があるが、confing.inc.phpの/** [SMTP] */を > >> >> どのように設定するのか？ > >> >> 一度設定したら、2回目の変更が反映されないようです。 > >> >> > >> >> 6.テスト結果の「各テストケースの全バグ」欄で、チケットにリンクできるのに、テスト > >> >> ケースIDのリンクが無いので、リンクを追加して欲しいです。 > >> >> 理由は、この欄でNGケースのチケットが解決されたか？検証完了まで持って行ったか、 > >> >> を知りたいからです。 > >> >> 修正方法は、テストケースIDが分かっているからリンクを張るだけです。 > >> >> > >> >> 僕は、タブブラウザで下記3画面を開いて、進捗をリアルタイムに確認しています。 > >> >> > >> >> 6-1.テスト実行→テスト結果の詳細を確認する > >> >> 6-2.全般的なテスト計画のメトリクス→消化テストケース数から進捗を確認する > >> >> 6-3.各テストケースの全バグ→NGケースとバグチケットのステータスを確認する > >> >> > >> >> 7.テスト結果、テスト実行画面でRSS機能はないのでしょうか？ > >> >> 逐一、手作業でRefreshしなければ、最新表示されないです。 > >> >> > >> >> > >> >> 過去のメーリングリストを読んだら、似たような質問をしている人もいました。 > >> >> TestlinkのUIは、Ver1.8では使いやすくなっているでしょうか？ > >> >> > >> >> http://lists.sourceforge.jp/mailman/archives/testlinkjp-users/2007-November/000035.html > >> >> > >> >> 長文になってしまい申し訳ありませんが、一つでも回答して頂けると幸いです。 > >> >> 以上、よろしくお願いします。 > > > > _______________________________________________ > > Testlinkjp-users mailing list > > Testl****@lists***** > > http://lists.sourceforge.jp/mailman/listinfo/testlinkjp-users > > > > _______________________________________________ > Testlinkjp-users mailing list > Testl****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/testlinkjp-users
