テスト観点を一覧化してテスト設計で悩まないようにする
こんにちは！kazuhiraと申します。
今回はシステム全般で使えるテスト観点を
- 仕様のテスト観点
- 構造のテスト観点
- 経験のテスト観点
3つの観点で一覧化し、テスト設計で使えるようにしてみました。
筆者はWebエンジニアなので、偏りがあるかも知れない点にご注意ください。
細かい観点を述べると長すぎて見なくなってしまうので、連想できる程度に抽象化しています。
記事の背景
自分のテスト設計のクオリティがその時の自分のパフォーマンスと相関していることに気付きました。
他人のテスト設計のクオリティもその人のパフォーマンスに依存しています。
※（それはそう）
PR/MR毎にテスト設計で消耗していませんか？
テスト設計を安定して消耗せずに実践していきたいですよね。
普段何気なくテスト設計してきましたが、私の今の視座で観点を一覧化してみました。
備忘録やテスト設計のヒントとして活用してもらえると嬉しいです。
仕様のテスト観点
単体レベルと結合レベルに切り分けて考えてみます。
単体レベル
- 仕様を網羅しているか？
- 外部環境が落ちている場合のケースが考慮されているか？
- 権限管理は適切か？
- 並行処理するとどうなるか？
- 複数回処理するとどうなるか？
-
バリデーションは適切か？
- 境界値、最大値、異常値、正常値
- テストは独立しているか？
結合レベル
- 業務フローをなぞっているか？
- UI・UXに違和感がないか？
- 同じデータを使っていないか？
-
状態を変化させるとどうなるか？
- 過去/未来
- フェーズ
- リトライ
-
ヘビーユーザの利用に耐えられるか？
- 最大でどの程度のトラフィックが予想されるか
- システム連携で疎通しているか？
- セキュリティ対策は適切か？
-
リリース手順が適切か？
- 人員確保がしやすいか？
- システムメンテナンスで停止させる必要があるか？
- 障害で切り戻した場合に正常に動作するか？
- 絶対に落とせない導線の確認手順があるか？
- スモークテストまたは見極め手順はあるか？
構造のテスト観点
モジュールの実装レベルの観点です。
ソフトウェアでいうプログラムそのものの構造に着目します。
- テストコードは落ちていないか？
- 条件分岐を網羅しているか？
- 設計思想・方針、言語・FWのベストプラクティスに沿っているか？
- 命名・機能が一意か？
- DRY・YAGNIか？
- ファンクションレベルで冪等性があるか？
- 必要最小限の情報を取り扱っていて余分な情報はないか？
経験のテスト観点
結合テストではカバーしきれないシステム全体をカバーします。
ミッションクリティカルな処理の担保やデグレードしていないことを確認します。
- システム障害が高頻度で発生している箇所はあるか？
-
並行稼働させてテストする必要があるか？
- 絶対に落とせないシステム
- 関連機能がデグレードしていないか？
-
システム全体をテストする必要があるか？
- システム基盤のバージョンアップなど
実践
私の場合は上から順というわけではなく、
- 仕様
- 構造
- 仕様（再度）
- 経験
の順番でテストすることが多いです。
仕様レベルのテストを先にやっておくと開発初期でバグの洗い出し効率がいいんですよね。
まとめ
私はどうにも経験に頼ってしまう癖があるようなので、
自分がすぐに答えられる範囲でアウトプットしてみました。
書いていて思ったんですが、非機能要件、プロダクト特性、システム特性、etc.を考慮するとテスト観点はもっとありそうです。
Zennでは初めての記事投稿でした。参考になれば幸いです。
Zenn CLI、便利ですね。Zenn公式さんの解説記事も非常にわかりやすかったです。
ここまで読んでいただき、ありがとうございました！
Discussion