Azure BoardsとAzure Test Plansの
いい関係
かめがわ かずし(kkamegawa)
自己紹介
personal:
name: かめがわ かずし
alias: kkamegawa
community:
MVP: Microsoft MVP for Developer Technologies(2009-)
UsersGroup: Team Foundation Server Users Group
URL: https://dev.azure.com/tfsug/tfsuginfo
Blog: はてなブログ
URL: https://kkamegawa.hatenablog.jp
This contents based on 2020/5/6
お品書き
最初に使い始めるAzure Boards
タスクとテストの関連付けによる活用について
Azure DevOps全体象
Azure DevOps概要
アジャイルツールを使用し
て、より迅速にユーザーに
価値をもたらし、 チームの
垣根を越えて作業の計画、
追跡、相談ができます。
多くの言語、プラットフォーム、
クラウドに 対応したCI/CD を使
用して、ビルド、テスト、 デプロ
イできます。GitHub や他の Git
プロバイダーも対応しています。
クラウドでホストされた容
量無制限のプライベート Git
リポジトリです。プルリクエ
ストと高度なファイル管理
を提供します。
手動の探索的テスト ツー
ルを使用することで、テス
トと公開を自信を持って行
えます。
パッケージを作成、提供して、
チームで共有し、ワンクリック
で CI/CD パイプラインに 成果
物を追加できます。
Azure Boards Azure ReposAzure Pipelines
Azure Test Plans Azure Artifacts
https://azure.com/devops

Azure Boards
バックログ / タスク / バグを一元的に管理するため
のサービス
チーム単位にカンバンの管理が可能
小規模チームだとオーバースペックかもしれない
Basicプロセスはあるけれど
Azure Test Plans
Visual Studio Subscriptionか、Test Plans契約が必要な
有償サービス
バックログとテストを関連付け、「何をテストしなけ
ればならないのか」を管理する
探索テストもできるけど、それだけじゃないよ
プロジェクトを始める前に
既定のテンプレートの設定
Advancedタブの既定に反映
明らかに使わないプロセスは
Disable
ちょっとカスタマイズしたい場
合はCreate Inherited process
https://dev.azure.com/{organization}/_settings/process
プロジェクトの始め方
チームプロジェクトを作る
プロセスを変えたければ
Advancedタブで変更
タスク管理とコード連携を
初めてやる場合はBasic。
本格開発ならScrum / Agile。
余談:チームプロジェクト作成はあちこちで可能
https://dev.azure.com/{organization}/_settings/process
https://dev.azure.com/{organization}/_settings/projects
https://dev.azure.com/{organization}
Azure Boards
Azure Boards
作業の情報を集積する場所
作業ベースでテスト、ビルド、ドキュメントを管理
カスタマイズできる余地もあるよ
CMMIは今回触れません
プロセステンプレートによる”New Work Item”の差
Agileプロセス Basicプロセス Scrumプロセス
Basicプロセスの利用しどころ
GitHubのissueになれている人は使いやすい
シンプルに始められる
きっちり管理したい人にはちょっと不向き
誰が、なんのタスクをするくらいしかない
インフラ作業や問い合わせ管理にはいいかも
ScrumとAgileの違い
https://docs.microsoft.com/en-us/azure/devops/boards/work-
items/guidance/choose-process?view=azure-devops&tabs=basic-process
• Epic:やりたいこと
• Feature:具体的な機能レベル
• User Story:実現方法
• Task:作業
• Bug:発生したバグ
• Issue:問題(課題、懸念事項)
• Epic:やりたいこと
• Feature:具体的な機能レベル
• Product Backlog:実現すること
• Task:作業
• Bug:発生したバグ
• Impediment:問題(人、プロダクト全部)
Impedimentの説明
https://www.ryuzee.com/contents/blog/3574
どっちも同じに見えるんだけど、どっち?
一つの判断基準は「作業
時間を見たいかどうか」
(標準で)Agileにはある、
Scrumにはない
継承してテンプレート
作ればScrumでも可 Agile Scrum
Work Item作るときに何を入れる?(Agile/Epic)
Assign Task以外は無理に入れる
必要はない
Area サブシステム毎などに検討
Iteration 「いつ」やるか
Description 齟齬がないようにしっかり
Priority 優先度のルールはしっかり
合意
Start Date 開始日
Target Date 目標日
Development Gitブランチ、ビルド、Work
Itemなどを関連付け
Tag Areaに入れられないけど、
タスクを検索するときに
Work Item中心の開発
Work Itemからメール、Gitブランチの作成
が可能
ここから作ったGitブランチはコミットメッ
セージに “#ID fix hoge”とかしなくても自動
的に関連づく
テンプレート、タスクのカスタマイズも可能
テンプレート
そうはいってもWork Itemに
書くことありすぎ
特にBugではDescriptionの内
容が個人によってブレがあり
すぎる
必須事項をテンプレート化
プロセスのカスタマイズ
Create Inherit Process/ Work Item
のCustomizeから
昔のオンプレミスではXMLファイ
ルをいじってたんですよ…
Work Itemレイアウトカスタマイズ - Due Date追加
Due Date(期日)をTaskに追加してみる
必須項目としてDue Dateが入りました
拡張機能もたくさんあります
https://marketplace.visualstudio.com/search?term=control%20group%20tab%20page&target=AzureDevOps&categor
y=Azure%20Boards&hosting=cloud&sortBy=Relevance
Stateを追加する
追加しすぎても整合性取れなくなる。
使う人から「めんどくさい」と思われないように。
※:必要性が出てからでいいです
特定の条件下でWork Itemの動作を強制させる
必須ではないけど、特定のタイミングで
「これが設定されていなくてはならな
い」という検証をしたいときに使う
例えばタスクをActiveに遷移するとき
Descriptionが空欄だとダメという場合
Ruleを作成する
https://docs.microsoft.com/en-
us/azure/devops/organizations/settings/work/custom-
rules?view=azure-devops
オンプレミスのプロセステンプレートカスタマイズ
witadminというツールを
使って一から作れます。
正直全くお勧めしないです
バージョンアップ追従が大変
昔はMSもこれ使ってWFテ
ンプレート公開してました
https://docs.microsoft.com/ja-jp/azure/devops/reference/witadmin/witadmin-customize-and-manage-objects-for-
tracking-work?view=azure-devops-2019&viewFallbackFrom=azure-devops
プロセステンプレート移行できる?
Azure DevOps標準組み込みのテンプレート間
(Basic/Agile/Scrum/CMMI)での移行はできません
継承したテンプレート間であれば可能です
継承テンプレートを移行するときは足りない種類を作っ
てから実施します
https://kkamegawa.hatenablog.jp/entry/2019/07/22/2218
34
Boardsのメニュー
Work Items : Work Itemの作成、ザクッとみる。個人
用のビュー
Boards:いわゆるカンバン。ステークホルダー向け
Backlogs:優先順位設定。プロダクトオーナー向け
Springs:スプリント単位のカンバン。開発チーム向け
Queries:Work Itemを列挙するクエリを構築。多様な
場所で使います。
タスクの連携
「Excelで見たいんだよね」という管理職にはOffice
Integration(Azure DevOpsライセンスがあればOK)。
https://docs.microsoft.com/ja-jp/azure/devops/boards/backlogs/office/track-
work?view=azure-devops
今ならTeamsでタブの統合もおすすめ(Azure ADのみ)
https://docs.microsoft.com/en-us/azure/devops/service-hooks/services/teams?view=azure-devops
CSVでのタスク取り込み
https://docs.microsoft.com/en-us/azure/devops/boards/queries/import-work-items-
from-csv?view=azure-devops
azure-cli
https://docs.microsoft.com/en-us/cli/azure/ext/azure-devops/devops?view=azure-cli-latest
Power Automate / Logic Appsでタスク連携
作業割り当てられたら To Doに
入れる、というフロー
タスクの更新は明示的にタスク
IDを指定しないといけない
Automateの場合は同一ドメイ
ンのorganization, LogicAppsの
場合は同一サブスクリプション
じゃないときついので注意
よくある質問
Planner, To DoとAzure Boardsの違いは?
 チームでタスク管理したいだけならPlanner / To DoでOK
Logic AppsでTo Doへタスク追加はできるよ
 成果物とかコード管理、リリース管理入るならAzure Boards
MS Projectと連携しないの?
 昔はしていたのですが、今はサードパーティー製品での対応です
 余談ですが、SharePointも同じく対応止めました(オンプレミスも)。
GitHub Issueとどっちがいい?
 ラベルベースの気軽な管理で始めたい場合Issue
(Projectまでは使わなくてもいい場合)
 検索クエリを駆使したい場合Boardsがいい
 最近Issueと同期するActionも公開されました
https://github.com/marketplace/actions/github-issues-to-azure-devops
Azure Test Plans
Azure Test Plans
探索テスト
テストケース管理
テスト進捗管理
そもそもテストを管理する、とは
テスト項目を設計するにはINPUTの要件が必要
要件が変わるとテストも変わる
トラッキングが大変
テスト計画を作る
1. Configurationを作成
テスト対象構成(OS, ブラウザー, ミドルウェア,etc)を管理
2. Test Planを作成
Area / Sprintを指定して作成
3. Test Suiteを作成
4. Test Caseを作成
テスト計画の作成
現在のIteration/Sprintで実
施するテストを計画する
テスト計画の設定
テスト対象パイプライン
ビルド番号
自動テストの場合対象
のリリースパイプライン
とステージ
これMulti-Stage Buildに移
行するとどうなるんだろ
う…
テスト計画で実施するテストの作り方
Suite:
テスト一連のまとまり
Static suite:
新規で一から作る
Requirement based suite:
要件ベースで検索して
関連付け
Query based suite:
特定のクエリ結果
Requirement Based Suite
Microsoft.Requirementカテ
ゴリーに属するテストが列
挙される
ScrumではProduct Backlog
Item, AgileではUser Story
関連付けられてるTestが
自動的に追加される
このような要件トレーサビ
リティは多くの場所でサ
ポートされています
https://docs.microsoft.com/en-us/azure/devops/pipelines/test/requirements-
traceability?view=azure-devops
Query Based Suite
特定のテストケースを
検索して追加する
WIQLで検索してあげて
ください
https://docs.microsoft.com/en-
us/azure/devops/boards/queries/wiql-syntax?view=azure-devops
「テスト項目はExcelで入力できないとダメ」という人
1. ExcelをSharePoint
にアップロード
2. Logic Apps /
Automateが起動
3. Azure Test Plansに
登録
4. Excelを解析して
Test Plansへステッ
プ登録
テスト同期システムの仕組み
Office 365と同一Azure AD配下
のAzureサブスクリプション持っ
ていなかったため、Blobを経由
しています
Power AutomateでHTTPコネク
ターはPremiumコネクターなの
で、Logic Appsで組んだほうが
いいです。
参考資料
Azure Boards一連のエントリー
https://kkamegawa.hatenablog.jp/archive/category/Azure%20Boards
Azure Boardsのプロセステンプレート説明
https://qiita.com/mstakaha1113/items/2c857e85ed6203d93028
Azure Test Plans
https://docs.microsoft.com/ja-jp/azure/devops/test/?view=azure-devops
https://docs.microsoft.com/ja-jp/azure/lab-services/

Azure Boards and Azure Test Plans inside out.