Visual Studio Team Servicesで顧客に手軽にフィードバックを入力してもらう(16日目)

はじめに

フィードバックがほしい、とお願いしても、VSTSのWeb UIに不慣れな人ではなかなかチケットを作ってもらうことは難しいです。もう少し気軽にフィードバックするための仕組みとして、VSTS/TFSには専用のフィードバッククライアントが用意されています。

フィードバッククライアントそのものは無償で使えるので(VSTSの接続ユーザーにも入りません)、気軽に試してもらう場合有効です。

フィードバックをお願いする

ダッシュボードの設定

ダッシュボードにあるRequest feedbackというリンクをクリックすればいい…のですが、ダッシュボードに存在しないことがあります。

このような場合、ダッシュボードを編集して、Other Linksというボックスを選択して、Addで追加します。

Other Linksが追加されたので、Request feedbackをクリックして、フィードバックのお願いを開始します。

フィードバック依頼

まず、フィードバックがほしいStakeholder(利害関係者)をSelect Stakeholderで選択します。

次に、試したいアプリケーションの種類を選択します。ここではWeb Applicationを選び、URLを指定します。Stakeholderではクリックすればそのまま開くので、手間がかかりません。

注意してほしいことなどがあれば下に捕捉します。

フィードバックがほしい項目について一つずつ記載します。Add Itemをクリックすると、要求項目が増えます。ここでは2件のフィードバックを依頼しました。

選択した人のところにはこのようなメールが届きます。フィードバッククライアントをインストールしている場合、Start for feedback sessionをクリックすれば始まります。

そうでない場合は、install the feedback toolをクリックします。

こんな風にクライアントが起動するので、インストールしてください。

フィードバック開始

指示内容とURLを確認して、「次へ」をクリックします。

フィードバック依頼項目が二つあるので、１と２を確認します。

項目1のUIについては悪くないので、そのまま「悪くないね」というコメントと、評価(問題なかったので★5)を記載しています。

フィードバックのとき、基本的に問題なければ一番いいレートにしておくと、受け取る側のモチベーションにもつながります。ダメだったらダメでいいのですが、どこがどういう風にダメだったか、あるいは改善してほしいか、ちゃんと書きましょう。

フィードバック項目2ではAbout画面がデフォルトのままだったので、スクリーンショットの添付と、コメント、ダメだったので、★1を付けています。

★1は致命的で、業務上どうしようもないところとかにつけるといいでしょう。

フィードバックの結果が問題なければ、「送信して閉じる」をクリックします。

開発側

フィードバックはWorkのQueriesから確認できます。自分が送ったフィードバックはAssign to meで見えますし、チーム全体のフィードバック項目をみたければ、Shared Queriesにある、feedbackを選べばチーム全体に送られてきたフィードバック項目が全部確認できます。

まとめ

フィードバッククライアントは無償で使えるし、簡単に画面上のここというところを指示できるし、開発側もフィードバックというカテゴリーで一元管理できるのでとても便利だと思います。

ぜひ使ってみてください。

Visual Studio Team ServicesとChromeで未知のバグを発見する(15日目)

はじめに

テストケースだけでバグが検出できればいいのですが、そんな甘いものではなく、何気なく操作しているタイミングで出ることがよくあります。中には「神の手」を持つ方がいて、「この人が操作するときだけ起きる」というある意味素晴らしいバグハンターという方もいらっしゃいます。

特に開発時には無意識によけることもあり、こういうバグはテストケースでは救えません。どうするかといえば、「普段から記録しておけばいいんじゃね？」ということになります。

そういう操作を支援するのが「探索テスト(Exploratory testing)」機能です。ChromeのFeedback & test拡張機能および、Test Managerがサポートしています。

Chrome拡張機能

操作を記録する

Test & Feedback拡張機能を起動して、左端の△をクリックすると記録を開始します。

左端が赤枠の□になると記録開始です。以下の機能があります。

• テスト中(クリックすると停止)
• スクリーンショット
• メモ
• 動画
• VSTS/TFSにタスク/バグ/テストパターンを作成
• 操作タイムラインを見る
• Work Itemにリンクする
• デバイスに接続する
• 設定
• About画面

スクリーンショット＆メモ

画面に対するフィードバックをしたい場合、スクリーンショットを撮って、補足項目を文字入力します。

履歴

操作した履歴やスクリーンショットが確認できます。

作業項目と関連付け

特定の作業項目と関連付けておくことで、探索テストがどの作業に関連しているものかわかりやすくなります。

バグの作成

画面に問題があったので、バグとして登録します。Create bugで新しいバグとして登録します。特定の手順で再現することがわかるバグであれば、Create test caseで新しいテストケースを作れば今後再現テストに役立ちます。

バグ作成時、記録した操作及び、スクリーンショット、レスポンスの時間が全部記録されています(Chromeの機能でとっています)。

VSTSでのバグ確認

作成したバグはチームのバックログに登録されて、すぐに確認できます。

スクリーンショットが添付されているので、迷うことはありません。

添付されているhtmlにはChromeの開発者ツールで見える、応答状態もhtmlとして記録されています。

htmlをダウンロードして開くとこんな感じで確認できます。

Test Managerで探索テスト

Test Managerで起動する

Test Managerを使っても同様のことができます。こちらはどちらかといえばリッチクライアントアプリで探索テストするときに使うといいでしょう。あと、マイクも使えるので、音声で「どんな操作をした」という記録も採取できるのがいい点です。

探索テスト対象のビルドと環境に関連付けます。Test settingsやEnvironmentはSystem Center Virtual Machine Managerと連携した自動テストをするときに用意するので、ローカルテストの場合はデフォルトで構いません。

開始すると、このようなウィンドウが出てきます。タスクバーと同様のウィンドウ領域に影響するウィンドウなので(これは画像編集で小さくしています)、クライアントエリア全体＝フルスクリーンであると仮定するようなアプリはちょっと気を付けてください。

記録が終了するとこのように探索テストの結果が記録されます。

記録の日数について

Testの設定で保持日数の既定値が決まっています。長期間放置すると、VSTSが自動的に消してしまうので、注意しましょう。

まとめ

業務アプリであれば、普段から使って「あれここ変？」というような調査は難しいと思いますが、サービスや日常のアプリであれば、探索的テストを常時実行しておけば、ふとしたときでもバグが発生したときの操作記録が残るため、便利です。

特にChromeの拡張機能はとても便利ですね。VSTS/TFSにつながなくてもキャプチャや記録はとれるので、単独でも使いたい一品です。はやくEdgeやFirefoxにも(ry。

Visual Studio Team Services で手動テストを実行してバグ記録、修正をする(14日目)

手動テスト、バグ発行

テストを実行

昨日作成した、テスト計画のテストケースからテストを実行します。Activeになっているテストを選択して、Run with Optionsを選択します。

Chromeで実行

こんな選択肢が表示されます。

• Webブラウザでテストランナーを実行かTest Manager(2015/2017)を使う
• クライアントのデータ収集する(Test Managerのみ)
• テスト対象のビルドを選択する

テスト対象のビルドはこんな風にFind buildから選択できます。これによって、テスト対象のビルドの品質を計測することができます。自動化を構成していた場合、この辺は自動で行われます。

Webランナーを実行したとき、このような小さいウィンドウが表示されます。テストケースを作ったときの手順も表示されるので、この通りに実施します。

昨日Chromeでなければならないという理由が右上の四つのボタンです。カメラ(画面キャプチャ)、ユーザー操作およびログ、動画撮影、追加情報の添付といった機能はすべて昨日紹介したChromeの拡張機能で実装されています。

拡張機能はChromeベースのWeb標準技術になることが決まっているので、遠からずEdgeやFirefoxでもサポートされるのでしょう、たぶん、きっと。

手順の横にあるレと×で期待通りの動作かどうかをチェックします。レが成功で、×が失敗です。

失敗と判定した場合、コメントへの追記や画面キャプチャ、追加情報を添付しましょう。

Create Bugをクリックすると、VSTSへバグの登録ができます。

バグ情報

作成したバグはすぐにVSTSで確認できます。対象のビルド、テスト、プロダクトバックログといった情報がすべてリンクされています。

こんな風に添付された情報の確認やテスト計画を一覧で確認できます。

概要の確認ができます。Update Statusをクリックすると、このバグの原因などが登録できます。

今回は新しい問題なので、New Issue,Product issueといった分類を記録して、コメントに具体的に何が問題だったのかみたいな情報を記録しておくことで、みんながトラックできます。

バグ修正

Aboutが間違えていたので、変更してコミットします。

新しくビルドができたので、このビルドでテストを実施します。

コミット時に関連付けておいたので、バグのDevelopmentに変更コードのリンクが作成されています。

Developmentをリンクをクリックすると、変更点が差分で表示されます。

Test Managerでの実行

Test Managerでテスト実行する場合、ブラウザでは選択できなかった、Data Collectionが指定できます。これを指定した場合、OSを一度再起動が要求されるので、再起動してください。

同じテストステップを見るので、同じ内容が表示されています。

同様に、失敗した場合のチェックもつけられます。

Visual Studio Team ServicesのWebテスト機能を準備する(13日目)

テストタブ

TestタブではVSTSのテスト機能の情報が集約されています。結構高度な機能で、要件に基づくテストや、負荷テストを一元管理することができます。

もしもTestタブがない場合、marketplaceから購入、もしくはinstall for paid usersでVisual Studioサブスクリプションを持っている人に割り当てる必要があります。

marketplace.visualstudio.com

なかなか盛りだくさんの機能があるので、数日に分けて紹介します。

Test & feedback用Chrome拡張機能

まず、テストを実行する場合、Visual Studio 2015/2017(RC)か、Google Chromeが必要です。Edge, Firefox, Safariでも使えるのですが、フィードバックやhttpリクエストのキャプチャをそのまま添付するにはChromeのみリリースされている拡張機能をインストールしておく必要があります。

Installをクリックすると、Chrome拡張機能のページに遷移して、インストールできます。インストール時Googleアカウントは不要です。

拡張機能インストール後、VSTSに接続します。connectedがVSTS/TFSに接続するモードで、全機能が使用可能です。Standaloneでは画面のキャプチャ、操作記録などの一部の機能のみ使用可能です。同様のツールはほかにもありますが、キャプチャだけでも結構便利なのでおすすめです。

チームの選択まで行って、Saveすると、設定完了です。仮にほかのチームおよびプロジェクト、ほかのVSTS/TFSに接続するときは一度Disconnectで切断してください。

初期設定

Configurationsをクリックすると、テスト対象の環境構成の設定ができます。初期状態ではBrowserとOperating Systemの組み合わせが用意されています。Add new valueをクリックして、例えばmacOSやLinux,Windows 10(1607)やWindows 10(1511)といった構成を追加できます。

もちろん、画面左上の＋をクリックして、Browser, Operating System以外にもOracleや独自のミドルウェアバージョンという構成を追加できます。

テストを作る

まず、現在のスプリントでどんなテストを実施するのか、Test Plan(テスト計画)を作成します。画面左上の＋をクリックすると、テスト計画名、Area Path, Iteration(スプリント)の設定ができます。Area Pathにチームを設定すると、自動的にそのチームにテスト計画が割り当てられます。

作成されたら、NewからNew Test Caseでテスト手順を作ります。この手順を見ながらテストすることになるので、可能な限り具体的なテスト手順を書きましょう。それこそExcelに(w)書くようなStep by Stepで書きます。

もちろんタスク同様にプロダクトバックログに割り当てられるので、Related WorkからAdd linkでバックログやタスクを関連付けておくとなおいいです。

テスト単独では担当者の設定ができますが、テスト計画に含まれる多くのテストを1人で実施するのは非現実的です。

そのような場合、テスト計画を複数の担当者に割り当てて、「このテストやってね」ということでメールの送信ができます。

＃ぼっちプロジェクトなので、一人ですが、そう思ってください。

テストの設計ができたら、Active状態になっています。

このテストをどの組み合わせで実施するか、…をクリックすると、構成の編集ができます。この構成は前述の初期設定で作ったConfigurationsの組み合わせになります。

要件ベースのテスト抽出

New Test Caseで一から作るのもいいですが、先にテストタスクを作ってから、対象のテストケースを抽出するという方法もあります。

テスト計画の編集

テスト計画を右クリックすると、こんな風にメニューが出ます。テスト計画は階層を持つことができるので、クライアント、Webといったテスト対象ごとにわかりやすく区分できます。

まとめ

テストの設定や作り方について紹介しました。以前はTest Managerをインストールする必要があったテストですが、ほぼすべての操作がWebでできるようになって、大変便利になっています。

特にChrome拡張機能は単独でも便利なので(EdgeやFirefoxも出てほしいですね)、これだけでも使ってみてください。