ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

TABOK粗読による自動化の座学 - カテゴリー5「自動テストのフレームワーク設計」(2)

TABOK テスト自動化 テスト管理
　カテゴリー5をさくっと読み終えましょう。

5.3　 フレームワークのディレクトリ構造の決定

　自動化フレームワークの一式を他のマシンに移動したりすることもあるので、各種スクリプトやライブラリを配置するディレクトリ構造を、事前にしっかり決めておきましょう。
　・・・えっ、終わり？

5.4　実装の標準ルールの策定

　カテゴリー4で見たように、自動化のレベルが上がっていくと、適用の範囲がどんどん広がっていくんでしたね。
　よって、各種ルールを決めておかないと、フレームワークの中でバラバラな道具が乱立してしまいます。

コーディング規約

　たとえばスクリプト名。TABOKでは、トレーサビリティなどの観点から、手動テストと自動テストのスクリプトの名前が対応づいているのがよいとしています。
　他には、変数名のつけ方、スクリプトに記載するヘッダの書式やコメントのルールなど。普通のプログラミングと同じと考えてよさそうです。

構成管理の基準

　これも通常のSoftware Configuration Managementと同様、ソースコード・ドキュメント・要件などのバージョン管理を行います。

手動→自動の移行基準

　フレームワークの運用に関わるルールです。
　すべてのテストを一気に自動化することはできないので、できるところから徐々に自動化していくことになります。そのとき、手動テストを自動テストに移行するための判断基準があるといいですね。その基準の結果、自動化できないという判断なら、それを妨げる要素も記録しておかなくてはなりません。
　また、ソフトウェアの変更によって、自動化したテストが一時的に使用できなくなることがあります。メンテが必要になった自動テストにはしるしをつけておいて、その間は手動テストに返るといったルールもいります。

結果の記録の基準

　結果を適切に分析するためには、テストの成否から始まって、レイアウトやファイルタイプといった、ログのフォーマットを共通化しておく必要があります。

　ん？前回「残り3つ」と書きましたが、5つ目の「自動テストの作成」はないですね。2つに分けて書く必要もなかったな・・。