はじめに

こんにちは！クラシルのQAを担当しています。shiominです。
今回のブログでは私が2人目のQAとして取り組んできたチーム体制の整備とそれに伴っての成果を紹介していければと思います。

はじめに
現状のQAチームはどんな感じ？
私が入社した当時、QAチームにあった課題
取り組んだこと
さいごに
参考文献

現状のQAチームはどんな感じ？

delyのQAチームの現状をまずお話しすると、現在は3人体制で日々QAの業務を行っています。

メイン業務はクラシルAppのiOS、Androidの検証業務（たまにWebも）になりますが、よりクラシルプロダクトの品質を向上させるための取り組みなども行っています。
しかし、QAチームはまだ2年にも満たないくらいの新しいチーム＆人数も3人しかいないので現在はQAチーム体制の強化・整備に重きをおいています。
その中で私は通常の検証業務とチーム体制の整備をメインにここ10ヶ月くらい取り組んできました。

ちなみに現在のQAチームは以下のツールをメインに使っています。

Notion
- テストツールなどは導入されていない為、テスト設計はNotionで行っています
JIRA (2023/02頃~)

私が入社した当時、QAチームにあった課題

私がdelyに入社した当初、QAチームには主に以下のような課題がありました。

業務を効率よくまわせるシステムになっていなかった
過去のテストケースは残されてはいるもののナレッジとして蓄積されていなかった
QA中に発生した不具合や本番で発生した不具合がチケットとしてしっかり残っていなかった（Slackでのやりとりを探さないといけない状況）
1. これに伴い、不具合を分析しプロダクトの健康状態が可視化できていなかった

取り組んだこと

ここからは上記の3つの課題に対して、私がどう取り組んでいったかをご紹介できればと思います。

1．業務を効率よくまわせるシステムになっていなかった

この課題を解決するために入社当初、まず2人以上で回していく上で必要なステータスの追加とタスクボードの整備から行いました。
ステータス管理をより自然な流れにするために、元々あったステータスの中にレビュー中と実行前を追加しました。

レビュー中：2人体制となったことからテストケースのレビューを行う工程を追加
実行前：設計が終わっていること。まだ実行は開始できないことを把握するための工程を追加
- 実行前を追加したことに伴い、QAチームが設計や実行にどのくらいの工数がかかっているのかを測定することが可能となりました
  ステータスの流れのイメージ図（黄色が追加箇所）

JIRAが導入されるまではNotionで管理をしていましたが、JIRA導入後はこの流れをベースにしつつJIRAの機能を活かしてQA対応予定のチケットを事前に把握し積んでおけるようにBacklogを活用し、タスク管理する上で状況を把握しやすいカンバンボードの作成を目指しました。
JIRAはカードの色や、カードに表示させる項目を別途設定できるので、JIRAだからこそできる機能を駆使してチケットの詳細を見に行かずともボード上である程度情報を拾えるようにしました。このJIRA整備の作業を行う際、JIRAの一番編集権限の高い権限を一時的に借り、以下の改修を行いました。

カンバンボードの編集
チケットステータスの編集
チケットプロパティの編集・追加

元々JIRAは結構触ったことがあったのですが、ステータスの編集やチケットのプロパティ追加などは初めての経験だったので非常に勉強になりましたし、JIRAで触ったことがある範囲が広がったのは私個人としてもスキルアップにつながったと思います。

QAタスクの管理についてはこれで一区切りしましたが他にも効率化の一環として、
Notionのデータベースを作成すると、テンプレートが作成できるようになるので、それを活かし以下のテンプレートを作成しました。

テスト設計時の項目テンプレート
- それまでテスト設計をする際に毎回項目を都度書いていたので１クリックで項目セットを呼び出せるようにしました
テストケースに変動がないケースのテンプレート
- App全体のリグレッションテストケース
- 定常チェック用のテストケース

これらのテンプレートを作成したことで、上記画像のように作成したページ上に各テンプレートが表示され、任意のテンプレートを１クリックで呼び出せるようにしました。この仕組みをQA設計に適用したことによって以下のような効果を得ることができ、より効率化を進めることができました。

まっさらなページから項目を追加する手間の削減（約10分の削減）←小さい削減でもこういう手間を効率化していくのはアリだと思っています
チーム内でのテスト設計時の記載項目の統一化
リグレッションケースを毎回１から作成する手間の削減（約1時間の削減）

2．過去のテストケースは残されてはいるもののナレッジとして蓄積されていなかった

この課題を解決するため、Notionのカスタム性の高さをどううまく活用し管理しやすいようにするかを考えました。（前提としてテストケースはNotionに作成する運用となっています。）
そこでベースとする管理方法の考え方を検討し、同じくカスタム性の高いテストツールTestRailのスタイルを採用することにしました。

ここではNotionを活かしたテストケースの管理方法を紹介できればと思います。

このTestRailの構造をNotionで再現していく上で、私は以下の手順でテストケースのカテゴリの細分化を行いました。

各OS or チーム単位にNotionの子ページを作成
1. TestRailでいうとプロジェクト単位のイメージ
クラシルはUIパターンが現在２パターンあるため、Appの場合は各ページの中でテーブルを各UIパターン毎に作成
1. TestRailでいうとTest Caseのセクション単位のイメージ
UIパターン毎に分けた上でさらに各テーブルにて機能毎にタブを作成
1. TestRailでいうとTest Caseのセクション下のサブセクション単位のイメージ
2. ※上記画像参照※

例）TestRailのTestCaseのセクション構造イメージ *1

これにより、過去のテストケースを確認したいと思った際に、

どのOS or チームか
どのUIパターンか
どの機能か

この3点が把握できていればテストケースが探しやすくなるようになりました。

またこの仕組みを導入したことにより、テストケースを作成する時にかかる工数を少しですが削減することができています。
Notionのテーブルはフィルターをかけていればタブ内の『新規』ボタンを押下してページを作成した際に、作成したタブにかかっているフィルターの項目がページのプロパティ上に自動的に入力されるようになっているからです。

これにより、少しですがプロパティを設定する手間を省くことができました。

3．QA中に発生した不具合や本番で発生した不具合がチケットとしてしっかり残っていなかった（Slackでのやりとりを探さないといけない状況）
　a. これに伴い、不具合を分析しプロダクトの健康状態が可視化できていなかった

この課題に対しては以下の流れで不具合分析をある程度自動で集計できるよう整備を進めていきました。

不具合チケットを起票していたNotionページをテンプレート化し、入力すべき項目を統一化

クラシルにおける重篤度を定義

重篤度としてはCritical、Major、Normal、Minorの４つを用意し、以下の基準に沿ってエンジニアサイドと調整をしながらクラシルに特化した定義付けを行いました（詳細な定義はここでは割愛します）

重篤度	基準
Critical	発覚から即時の対応が必要
Major	発覚から１週間での対応が必要
Normal	発覚してから１週間〜２週間くらいでの対応が必要
Minor	直近で対応予定のない軽微なもの

JIRA導入に伴って、Notion→JIRAへの不具合チケットの完全移行
1. QAのプロジェクトを整備した時と同様、こちらもJIRAの権限を一時的に借りて以下の整備を行いました
  - カンバンボードの編集
  - チケットステータスの編集
  - チケットプロパティの編集・追加
  - 不具合記載項目のテンプレートの作成
2. それまでNotion側に起票していたこれまでの不具合チケット全てをJIRAに移行しました
JIRAダッシュボードを使用した、不具合の集計と健康状態の可視化
1. ダッシュボードのガジェット*2は以下を使用しました
  - 最近作成された課題グラフ
    - 月単位で作成された課題件数の推移を見れるようにするために使用
  - 2 次元フィルター統計
    - 重篤度と機能の掛け合わせによる集計結果を確認するために使用
  - 課題の統計
    - 件数と割合を項目毎に確認するために使用
  - 検索結果の絞り込み
    - 不具合を一覧で確認するために使用

JIRAのダッシュボードで不具合チケットを自動的に集計できるようになったことにより、以下が可視化できるようになりました。（やはりJIRAは便利ですね）

各月毎の発生件数の推移（過去３年分）
各OS毎の発生件数と解決状況
重篤度毎の発生件数
重篤度×機能毎の発生件数
不具合要因毎の発生件数

ここまでで不具合を分析するための基盤を完成することが出来ました。

さいごに

10ヶ月でようやくQAチームの基盤となる仕組みがある程度システム的に回るレベルまでになりましたが、
まだまだQAチーム自体やプロダクト品質を底上げしていくには課題が多くあります。
エンドユーザーにより品質の高いサービスを提供していけるよう、引き続きQAのチーム体制の効率化＆強化と、QAとして品質という面からアプローチを多くの方面にしていければと思います。