金融取引システムにおけるテストへの投資は、他のシステムを大幅に上回っており、煩雑なテスト手順が繰り返し行われていました。ROI（投資対効果）は著しく低く、プロジェクトや人員の変更に伴い、不可避的に多くのコントロールできない要因が導入されました。よく見られるのは、Aインターフェースからの出力フィールドを修正するとBインターフェースの結果に影響が出るケースです。各バージョンリリースごとにリスクも蓄積されていきます。
理論的知識
- 自動化の価値をどのように測定するか？ 自動テストのROI = (手動実行時間) * (実行回数) / (開発コスト + メンテナンスコスト)
- どのような機能に自動テストを行うべきか？ ユーザーが頻繁に使用し、頻繁に変更されない機能。このようなインターフェースに対して自動テストコードを作成することで、最大の利益が得られます。
- なぜこのタイミングで自動テストを推進するか？ プロジェクトのリリース直前は不適切であり、遠い水の問題を近渴（近隣の渇き）で解決しようとするのは無駄です。自動化は長期的な収益モデルであるため、最も適切なタイミングは、プロジェクトが本番環境で稼働し、安定したリリースサイクルに入っている時点です。
フレームワークの選択
関連の実践経験が不足している状態で、このような自動化テストのタスクを受け取った場合、一般的なスタートは、検索エンジンを開いて、現在のシステム技術スタックで利用可能なツールやフレームワークを探し、マニュアルを読み、一発勝負。適切なツールを見つけられれば、おめでとうございます、完璧なスタートです。
まず「間違っていた」と言っておきながら、関連資料を調べ直すと、これは存在しないわけではなく、むしろフレームワーク自体が複雑で、デプロイに必要なリソースも多すぎることがわかります。初心者にとって必要なのは、小さくて、簡潔で、テストチームの同僚に相談すると、Python 自体構築のフレームワークについて提案され、簡単に言うと、既存のユニットテストフレームワークを自動テストフレームワークとして活用するというものです。
参考となるプロジェクトのデザイン思路：https://github.com/wintests/pytestDemo
フレームが必要な理由
サービスには、開発環境、テスト環境、本番テスト環境など、複数の異なるデプロイ環境が存在します。フレームワークの役割は、これらの環境間の抽象化層を提供することです。テストケースとデータが分離され、それぞれの環境設定に合わせて異なるケースデータを適用できます。また、共通のデータをサポートすることも可能です。
主な目的は、自動化の利用率を向上させることです。より複雑なシナリオでは、異なる環境間でのデータ連携は存在せず、全く関係ありません。ケースデータを設定する際に label 属性を追加し、現在のデータがサポートする環境を指定するだけで済みます。