0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

要件・テストケース・バグの追跡を1画面に:リリース前の「これ、テストしましたっけ」が消えた

0
Posted at

はじめに

今期から、出荷判定の場で「この要件、どこでテストしましたか」と聞かれる回数が増えました。聞くほうも意地悪で言っているわけではなくて、たいていは前の四半期に一度こぼれたからです。

うちのチームでは、その確認をこんな手順でやっていました。

  • 要件の一覧を開いて、1件ずつ詳細ページに入る
  • 紐づいた設計タスクを見て、そこからテストケースに飛ぶ
  • テストケースの実行結果を見て、落ちていればバグを開く
  • 途中でどれを見たか分からなくなるので、手元のスプレッドシートに転記する

要件が20件くらいまでなら、まだ回ります。50件を超えたあたりから、確認そのものよりも「どこまで見たか」の管理に時間を取られるようになりました。しかも、この作業でいちばん怖いのは見落としのほうです。リンクが張られている箇所は目に入るのに、そもそもリンクが1本もない要件は、一覧を眺めていても気づけません。

そんな経験、ありませんか。追跡は「つながっているものを辿る」作業だと思われがちですが、実務で効くのは「つながっていないものを見つける」ほうなんです。

抜けているものが見えるようにした

やったことは1つで、要件からテストケース、バグ、コードまでの上下流を1つのビューに縦積みして、下流が存在しない行に印が付く状態にしました。人が辿るのをやめて、辿れない場所だけを見るようにした、という感じです。

この記事で登場するONES.comの製品は2つです。

  • ONES Project:要件・タスク・テストケース・バグを課題として扱う、プロジェクト管理のツールです。
  • ONES Wiki:確認した結果や判断の理由を書いて残しておける、ナレッジベース管理のツールです。

🧭 層と関係を決めてしまえば、あとは展開するだけ

使っているのは、ONES Projectのトレーサビリティマトリクスというビューです。作るときに決めるのは、実質この3つだけでした。

決めること うちの設定
起点の層 要件(今回のリリースに含まれるもの)
追跡する層の並び 要件 → 開発タスク → テストケース → バグ
層と層のつなぎ方 事前に設定してある追跡関係をそのまま使う

各層に表示する属性も選べるので、うちはステータスと担当者だけ出しています。列を増やしすぎると、結局スプレッドシートに戻ってしまうからです。

保存すると、要件が1行ずつ並んで、その下に下流の課題がぶら下がった状態で表示されます。行を展開したり畳んだり、1本の連鎖だけをハイライトして上から下まで通して見たりできます。最終層にはコードブランチやマージリクエスト、コミット履歴も出せます。「要件からコミットまで一続きで説明してください」と言われる場面がある方は、ここまで並べておくと後がかなり楽になります。

ビューは複製も共有もできるので、リリースごとに範囲だけ差し替えて使い回しています。

見るのは「ギャップ」の列だけ

いちばん使っているのは、下流が欠けている連鎖だけを集めて表示する機能です。該当する層に印が付くので、確認作業がこう変わりました。

以前 今
見る対象 要件を全件、順番に 印が付いた行だけ
リリース前の確認 2人で半日がかり 1人で15分ほど
見落としの気づき方 リリース後に発覚 その場で一覧に出る

もう1つ助かっているのが、権限の扱い方です。自分に見えない範囲のせいで途切れている連鎖は、ギャップとして数えられません。「本当に抜けているのか、単に自分に見えていないだけなのか」を区別しなくていいので、出てきた行をそのまま信じて動けます。

プロジェクト概要には、層ごとに下流が紐づいている割合を示すカバレッジのカードも出せます。数字が前の週より落ちていたら、新しく作った要件を誰も下流につないでいない、というサインとして見ています。

真似するなら、この順番がおすすめです

いきなり全層を並べると、ほぼ確実に真っ赤になって心が折れます。うちは次の順で広げました。

  1. 要件 → テストケースの2層だけで作る。 ここが埋まらないうちに下は見ない
  2. ギャップが出た要件を、まとめて1回だけ棚卸しする。 意図的にテスト不要なものは、その理由をONES Wikiに1ページ書いて残す
  3. バグとコードの層を足す。 説明を求められる場面が実際にあるなら、ここまで
  4. カバレッジのカードを週次で眺める。 落ちた週だけ原因を見る

2番の「理由を残す」は省きたくなるのですが、これを飛ばすと翌月に同じ議論をやり直すことになります。ギャップを埋めるのではなく消す判断をしたなら、その判断も記録の一部です。

棚卸しで出てきた不足分の課題を作るところは、ONES Assistantに絞り込み条件を渡して起票してもらっています。表を見ながら手で打ち込む必要はありません。

これで全部見えるわけではありません

追跡関係が事前に設定されていないと、当然ながら何も展開されません。関係の定義が終わっていないプロジェクトでは、まずそこからです。

それから、これは「関係が張られているか」を見る仕組みであって、中身が妥当かどうかまでは見てくれません。要件に対してテストケースが1件だけぶら下がっていれば、ギャップとしては解消済みになります。カバレッジが100%になった瞬間に安心しないよう、そこは意識して見るようにしています。

確認結果を手元に残したいときは、ビューをExcelに出力できます。絞り込みや並び替え、ギャップの表示状態もそのまま反映されるので、画面と同じものが手元に落ちてきます。

おわりに

追跡の作業がつらいのは、件数が多いからではなくて、全部見ないと抜けが分からないからでした。抜けだけが浮かび上がる状態を作ってしまえば、件数が増えても見る量は増えません。

手元のプロジェクトで、直近のリリースに含まれた要件を1件開いてみてください。そこからテストケースまで、クリックだけで辿り着けるでしょうか。途中で検索窓に頼ってしまうなら、辿る作業ではなく辿れる構造のほうを見直すタイミングかもしれません。

同じところで手間取っている方は、ONES.com で実際のビューを触ってみてください。自社の要件・テスト・バグの関係をそのまま再現できるか見てほしい場合は、support@ones.com までご連絡ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?