Toshiyuki Kawanishi
tosik****@users*****
2008年 12月 17日 (水) 14:17:27 JST
あきぴーさん 川西です。 > 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 > >> > >> 長文になってしまい申し訳ありませんが、一つでも回答して頂けると幸いです。 > >> 以上、よろしくお願いします。
