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