SQuBOKの実装の技法をテストに適用してみる妄想

SQuBOKv2の3.7章に「実装の技法」というものが定義されています。今日社内で読み合わせをしていた際に、ソフト開発の技法をソフトウェアテストに適用すると何か生まれるかもね、という話になったので、やってみようと思います。

コーディング規約

いろいろありそうですね。テスト手順仕様書の書き方がまず最初に思いつきます。例えば、テスト手順の各ステップの書式、命名規則、コメントの書き方など。テスト手順を形式的に書けば書くほど、ここに関わってきますね。実際ちゃんと形式化されたテストスクリプトはコードそのものなので、そりゃ規約も大事だよね、と思います。

リファクタリング

これもいろいろありそうですね。テストケースの集合である（VSTePでいう）テストフレームや、その集合である（VSTePでいう）テストコンテナの作り方を再構築する、というのがテストの全体構造設計においては、がリファクタリングに該当しそうです。また、テストスクリプトレベルでは、テストスクリプトの構造化、共有化（関数化）、データ駆動化によって保守性や移植性を上げる活動も該当すると思われます。

契約による設計

これはちょっと難しいかもしれません。多分本質を理解できていないです。僕が。責務を明確にして設計する、であれば前述のテストコンテナの作り方などが該当しそう（例えば結合度や凝集度）ですが、そんな単純な話でもなさそうです。

IDE

これはテストの統合開発環境ですね。テストがコードらしくなっている状況では、開発における統合開発環境が利用できます。テスト設計などの文脈であれば高機能なテスト設計支援ツールはIDEに該当するでしょうか。実態としてはあまり多く提供されていないのが事実でしょうか。

CI

テストにおけるCIは難しいですね。テストをテストする、とか、テストを統合して整合を取る、とかが何らかの手段で実現できればありえそうです。考えてみるのも面白いかもしれません。

というわけで、テストのCI、というのはもしかしたら何かが生まれるかもしれませんね。機会があれば考えてみます。