NotionでQAスケジュール管理からバグ分析まで一元管理を目指してみた

こんにちはQAエンジニアをしているもんです。
今回はテスト管理をすべてまとめてみたら案外いい感じに仕上がったので記事にしようと思います。

# Notionでまとめたいと思った理由
確認した事項やテストケースの共有はずっとしていましたが、一番伝えたい **"なぜその範囲をQAする（あるいはスコープから外す）に至ったのか"** が共有できていないというのが私の課題でした。
検出したバグの優先度はチームで決められてもそもそも検証する範囲の優先度はQAでいい感じに決めていました。

# Notionでまとめるにあたって絶対に達成したいこと
Notionでまとめるにあたっていくつか絶対に達成したい目的を決めました。

1. いついかなる時でも進捗が把握できること
2. チケットごとに実施する観点が共有できること
3. バグ分析が可能であること
4. いつでも引き継ぎできる状況を作っておくこと

# 1.いついかなる時でも進捗が把握できるしくみ
リリース日が決まっている以上、スケジュールと進捗の共有は必須なのでスケジュール表をまずは作成しました。

### 使い方
1. 開発概要は1チケット=1行で作成する（1stのみ画面単位）
2. テンプレを利用してページ内にテストケースを作成する
3. QA開始したらQA完了状況を”進行中”に変更する（QA開始日時が自動でセットされる）
4. 完了したらQA完了状況を”完了”に変更する（QA終了日時が自動でセットされる）
5. 予定日数とかかった日数の差異を確認し、読み違いがあれば振り返りをする
6. 進捗に遅れが発生したら速やかに報告し、対策を打つ

![スクリーンショット 2024-11-26 12.11.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3490706/7301d7fe-5300-3e7f-db53-c601d9218c55.png)


図のように各項目を埋めると、QAスケジュールの予定と実態が把握できるようになっています。
これにより、回数を重ねれば重ねるほど精度の高いテスト計画が立てられるようになります。
開発規模を定めている場合は規模あたりにかかる工数も出せるのでポイント数を項目に追加するとより精度が上がると思います！

# 2. チケットごとに実施する観点が共有できること
いつも希望する工数をもらえるのが一番の理想ですが、多くの場合使える工数は限られています。
その為、使える工数を何に使用するかをチーム全体で共有出来るQA観点優先度方針というのを作成しました。

### 優先度の判断基準を定める
どの観点を優先させるか決めるにあたり、判断基準を社内の障害対応レベルに沿って定めました。

### QAの進め方
1. スケジュールに合わせてMustじゃない観点を優先順位何番まで確認するか話し合って決める
2. 1で決めた範囲内でテスト設計をする
3. QAスケジュールのテストケースに網羅する優先順位を記載する（〇〇番まで確認する）
4. テストケースにどの観点に対応するのかを紐づけする
5. 開発担当者と確認観点のレビュー会を実施する
6. Mustで確認する必要がある項目を全て消化する
7. Mustではない項目を優先順位の高い順に消化する

### 補足事項

- QA期間に増減が発生した場合は1-3を速やかに実施しMustじゃない観点をどこまで見るかの見直しをする（Must観点については全人類を投入しても守り切る）
- スケジュールが出ない状態でテスト設計する場合はMust観点からテストケース作成をする
    - Must観点のテストケース作成終了後に優先順位の高い順にテストケース作成をする

### QA優先度の決め方
1. 社内で決められたインシデントレベルに沿ってどこまでを守るか定める
例:インシデントレベル
★★★★★
★★★★
★★★←ここまではMustで守り切る事にする
★★
★
2. 出てきた観点が★★★以上のバグを検出するものならMustと置く
3. ★★以下の観点の優先順位を決める

![スクリーンショット 2024-11-26 10.47.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3490706/a277d055-d335-8839-531a-7d56c1480452.png)

![スクリーンショット 2024-11-26 10.48.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3490706/c31047fc-cf4b-3d80-75d4-d872b1fb8252.png)


# 3. バグ分析が可能であること
バグが出た場合の原因をタグでフィルタリングできるようにしました。
実施結果のマスタをもたせることでチケット単位以外でもバグ起票日などの日付単位でもバグの分析を可能にしました。

バグの要因タグは情報処理推進機構の[組込みソフトウェア開発における品質向上の勧め［バグ管理手法編］](https://www.ipa.go.jp/archive/publish/qv6pgp00000010b6-att/000027629.pdf)を参考にさせて頂きました


![スクリーンショット 2024-11-26 11.05.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3490706/2942d48a-56c7-9a89-6621-27a03adee404.png)


# 4. いつでも引き継ぎできる状況を作っておくこと
長く運用を考えた時に、いつでも引き継ぎできることも考慮しました。
気をつけた点としては以下です。

1. ページをあっちこっち行き来しなくても運用できる
2. やるべきことがテンプレートで分かる

### スケジュール管理表のテンプレートを追っていけばテストケース作成まで完了できる
Notionの良いところはテーブルの項目にページを作成できるところです。
これによりスケジュールからページを開いていけば作成時も実施時も何をすれば良いか分かる状態になっています。

1. 開発概要を選択
![スクリーンショット 2024-11-26 11.49.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3490706/25b3412b-65ac-5916-b279-b7fc23b488d8.png)
2. テストケースをチケットで作成
![スクリーンショット 2024-11-26 12.10.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3490706/7f207272-7db9-912c-a8f6-c99c2aa74140.png)

3. チケットごとに実施結果記入テーブルを作成
![スクリーンショット 2024-11-26 11.52.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3490706/c84e698a-46dd-2b97-c972-cb1779b91116.png)

### 工夫したところ
ページごとにやるべきことや命名時のポイントを記載することで誰でも使えるようにしました。
また、ケースにQA観点優先度方針項目を紐づけ出来るようにすることでチーム内レビュー時に抜けている観点がないか確認しやすくしました。

## まとめ
NotionでQAスケジュールからバグ分析まで一元管理出来るようにすることで今まで難しかった本当の意味での観点やスケジュールの共有が可能になりました！

また、一連の動作で完結できるので私自身も作業効率が上がった気がします。
今後もより良いサービス開発に貢献出来る様にNotionに限らず様々なツールを利用しながら業務改善をしていきたいと思います！