テスト要件テンプレート

acceptance.md

簡易テストスライダー(オプション)

💡 どこまでテストを実施すればいいかの基準にする(記入しなくても良い)

		1	2	3	4	5
機能のリリース期日	期日を伸ばせる						期日が伸ばせない
不具合時に業務が止まるか	止まらない						止まる
影響範囲	狭い						広い

満たすべき要望

💡 PRDをそのまま貼り付けても良い

テスト対象外事象

💡 今回の受入テストではあえて対象外にすることを書く

Scalebase下流の動作確認

💡 対象機能がScalebaseの下流の機能の操作の前段階の場合はその機能を書く

可逆性の観点

💡 その機能を実行した後にオペレーターが自分で元の状態に戻せるかどうかを確認する

テスト終了条件

💡 何ができていればStaging環境にリリースしても良いのかを書く

テストシナリオ

メインシナリオ

💡 実際の画面上で行う操作を具体的に記述する

分岐対象

💡 メインシナリオ内で分岐する条件がある場合は記述する 組み合わせがある場合、可能であれば表も作成する

シナリオ終了時期待値

💡 メインシナリオが終わったときの具体的なアウトプットの形を記述する 可能であればDBの内部のデータのことまで記述する

追加確認事項

💡 確認が漏れがちな部分の確認 (確認必須ではないです)

• 契約
  • 一括請求オプション
  • ディスカウント
  • 請求予定
  • 複製した契約で後続が同じ挙動するか
• 改定
  • 契約数変更
• 請求
  • 請求周期
  • 使用量の契約
• 会計
  • BQ連携の互換性
  • テーブル構成や概念が大きくかわる
• 分析
  • テーブル構成や概念が大きくかわる
• connect
  • 見積書
  • 申込書
  • 契約を参照
• 非機能要件
  • デッドロック
  • 大量データによる集約のout of memory
  • 権限ある時の操作/権限ない時の操作

特記事項

💡 受入テスト時に考慮漏れがあった場合等は追記

functional.md

簡易テストスライダー(オプション)

💡 どこまでテストを実施すればいいかの基準にする(記入しなくても良い)

		1	2	3	4	5
機能のリリース期日	期日を伸ばせる						期日が伸ばせない
不具合時に業務が止まるか	止まらない						止まる
影響範囲	狭い						広い

PRD・ユースケース

• (リンクを貼る)

テスト対象

💡 何をテストしたいのか、何を確認したいのかをフリーフォーマットで記述する (「正しいこと」や「正常なこと」のような曖昧な表現はなるべく避ける)

ユーザーシーン

💡 「どこで(Where)」「誰が(Who)」「いつ(When)」「結果(Then)」がわかるように記述する ex.) 担当者編集画面でオペレーターが担当者を編集する時に担当者情報を編集できる

テスト目的

以下の中から選択してください(複数選択可)

(下記の部分はNotionのテンプレートで展開されるようになっています)

+アクターの操作シナリオのテストがしたい

+網羅的な動作確認をしたい

+新機能開発時に後方互換が壊れないか確認したい

+インシデントの起因になった部分をテスト化したい

+性能要件が問題ないか確認したい

テストしたいシナリオ・プロセス

テスト方法

以下の中から選択してください(複数選択可)

(下記の部分はNotionのテンプレートで展開されるようになっています)

+特定の手順の動作確認をしたい

+機能を網羅的にテストしたい

+負荷テストをしたい

テスト対象外事項

💡 別のシナリオで確認する等で意図的にこの要件から外した項目を記述する ex.) 担当者のfreee取引先IDはfreeeと連携しているプロバイダの要件としてテストする

テストシナリオ

💡 実際に画面で実行する手順を記述する

how_to_use.md

【重要】テストドキュメントについて

テストドキュメントの作成は必須ではなく、あくまで「推奨」です。

これらを記述することを義務化したいのではなく、チーム内でテストの内容が議論・共有されることを目的としています。

そのため、チーム内でそれらが出来ている場合はこれらのフォーマットに則らなくても問題ありません。

あくまでガイドとして活用ください。

受け入れテスト要件

目的

QAにリリースされる前の機能テストで「何がクリアできていたらStagingにリリースできるのか」をチーム内で共有するために作成します。

書くかどうかの基準は？

機能が大きく、開発に時間がかかるような場合は作成を推奨します。

事前に作成することで、終了時期や機能の詳細加減の共通認識を取れると思います。

誰が書くの？

基本はPdMに記述をお願いしています。

いつ書くの？

デザインと要件が確定したら仮のゴールを置くためにもまずは記述をお願いします。

メンテするの？

QAリリース準備完了になるまでは内容を都度修正しながら使ってください。

目指すべき指針として使うイメージです。

機能テスト詳細

目的

テストの内容、手順等をテンプレートに則って作ることでやることを明確にするために作成します。

書くかどうかの基準は？

テストの内容に迷ったら記述をお願いします。

機能が複雑で怪しいと思ったらテンプレに沿ってみると良いかもしれません。

誰が書くの？

開発チームであれば誰でも書く可能性があります。

いつ書くの？

機能開発前でも終わった後でも必要になったタイミングで記述します。

メンテするの？

基本はメンテをしません。

一度使ったら捨てるつもりで大丈夫です。

ただし、ユニットテストやAutifyのシナリオ等の残る形でテストを作成する場合はドキュメントのリンクを紐つけておくと後から修正時に意図を汲みやすくなるかもしれません。