見出し画像

アジャイル的な開発の中でのテストドキュメント

Shogo Nameki

こんにちは、アルプでQAエンジニアをしている nametake です。

今回はテストドキュメントについてお話します。

QAチームから開発チームに「ステージング環境にデプロイされるまでに必ずPdMの受け入れテストをチーム内で終了させる」というお願いしています。

ただ、いきなり「受け入れテストを終了させる」という取り決めを作ってもどういう基準で終わらせればいいのかが曖昧な状態ではそれらは実施されません。そこで、QAチームではその受け入れテストを終了させるにあたり必要なテストドキュメントのテンプレートを整備し、それを使ってテストドキュメントを作成するのを推奨しました。

※弊社のテストプロセスの詳しい内容はこちらの記事を参照ください

ドキュメント文化とテストドキュメント

アルプは創業当初からドキュメント文化が強くあり、

  • 顧客の要望からプロダクトに対する要求を記述するプロダクト要求定義書(PRD)

  • システムが具体的にどういう振る舞いをするのかを定義するユースケース

の2つは今でも継続して書かれ続けています。

しかし、そのドキュメントはテストではあまり活用されず、開発者が機能に対していきなり網羅的なテストを始める流れになっていました。

テストをやっていること自体は良かったのですが、作成した機能に集中してしまい顧客の目的にフォーカスが当たりづかったり、いきなり網羅的に行おうとしていたためテストの数が多くなってしまう状況になっていました。

「顧客に対する機能の妥当性の確認」と「機能の想定に漏れがないかの確認」はそもそも目的が異なると思ったため、

  • 受け入れテスト要件(顧客に対する機能の妥当性の確認)

  • 機能テスト要件(機能の想定に漏れがないかの確認)

の2つに分けることで、目的を明確にしたドキュメントを作れるように整備しました。

受け入れテスト要件のテストドキュメント

  • 満たすべき要望

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

  • テスト対象外事象

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

  • Scalebase下流の動作確認

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

  • 可逆性の観点

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

  • テスト終了条件

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

  • テストシナリオ

    • メインシナリオ

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

    • 分岐対象

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

    • シナリオ終了時期待値

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

    • 追加確認事項

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

受け入れテスト要件はざっくりと満たすべき要望、テスト終了条件、テストシナリオの3つを記述するフォーマットにしています。

主に「なぜ」の部分や抜けがちな観点を広く確認するために使います。

満たすべき要望の欄は基本的にはPRDにかかれていることを前提にしているため、PRDのリンクを貼るようにしています。

特に背景がひと目でわかりづらいScalebase下流の動作確認と可逆性の観点とテストシナリオの追加確認事項の項目について説明します。

Scalebase下流の動作確認

Scalebaseが提供している業務には下記のように流れがあります。

Scalebaseのオペレーション

オペレーターはこの流れに沿って日々オペレーションをしているのですが、機能開発をしているとどうしても単一の機能について集中してしまいその下流の動作に目が行かない傾向があります。

この辺りを受け入れ要件として記述しておくことで、「機能開発をしたことで顧客の業務を止める」という最悪の事態を事前に意識することができます。

可逆性の観点

新しい機能を作成して、それの下流の動作が正常だったとしても、その機能を間違えて使われてしまうことは必ず起こります。

そんな時、その機能に可逆性が考慮されていない場合、その対応の負荷はCSの方々にかかってしまいます。

機能によっては必ず可逆性を作ることはできないですが、可逆性がないことを事前に検知することで、CSの方々が事前に準備をすることができるようになり、負担を減らすことができます。

テストシナリオの追加確認事項

これはCSの方の今までの経験をヒアリングしつつ課題になりがちな部分をリストアップしています。

こちらは全部チェックするというわけではなく、引っ掛かりポイントを作るのが目的です。

機能テスト要件のテストドキュメント

  • PRD・ユースケース

    • (リンクを貼る)

  • テスト対象

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

  • ユーザーシーン

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

  • テスト目的

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

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

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

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

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

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

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

  • テスト方法

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

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

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

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

      • 負荷テストをしたい

  • テスト対象外事項

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

  • テストシナリオ

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

機能テスト要件は受け入れテスト要件に対して手段を決めるために使用しています。

適切なテスト技法は目的によって変わるため、Notionのテンプレート機能を使って目的と手段を選ぶようにすることで、書き手の負担を減らすのが目的です。

各テストドキュメントの書き方のドキュメント

受け入れテスト要件、機能テスト要件のテストドキュメントのテンプレートは用意しましたが、同時にテンプレートを使ってどうテストドキュメントを作成すれば良いのかというドキュメントも用意しました。

内容も、なぜその文章を書くのか、という目的をメインで記述するようにしています。

またドキュメント文化があるとはいえ強制的に書かされるようなものにすると根付かないため、ドキュメントを書くのはあくまで「推奨」という形にしています。

まとめ

今回作成したテストドキュメントを掲載したGistを貼っておきます。

受け入れテスト要件

機能テスト要件

テストドキュメントの書き方

冒頭でもお話したように、かなりアルプの運用に寄ったテンプレートのため、そのまま使うことはできないと思いますが、何かの参考になれば幸いです。

アルプではQAエンジニアを募集しています

もしこの記事を見てアルプに興味が出た、もしくは話を少しでも聞いてみたいという方は、お声がけください。


この記事が気に入ったらサポートをしてみませんか？