Excleは表計算ソフトであることを注意喚起するツイートがバズっていました。
Excelテスト手順書対策を書こうと思います。
悪夢の言葉： Excelテスト手順書
注記１：当記事にExcelを悪く言う意図はありません。Excelを表計算ソフト意外の用途で使うことに意を唱えているだけです。わかりやすいからExcelの名前を使っていますがSpreadSheet、ドキュメントツールなど全部同罪です。
昨日勢いでQiitaで書いた記事を深く考えて纏めました。
ターゲット
- リポジトリ単位のテスト
- CIを用いて一日に何度も実行するテスト
- フロントエンドのないテスト（今回はAPIの機能テストに限定）
（E2Eテストのようなフロントを含むものはスコープから外します。まずはRESTfulAPIから）
なぜExcel手順書は忌み嫌われるか
- 手動実行を前提としていることが多いから
- たとえ自動化しても、テスト手順書と実行コードの二重管理が生まれるから
- 実行頻度が低くなりがちだから
つまり
- テスト手順書を機械的に実行できればいい
- 非エンジニアが読みづらいって言ってきたら、人間向けに出力できるようにしておけばいい
表計算ソフトでテスト手順書を書くの辞めましょう
普通の.xlsx形式を実行してもテストは走りません。Cleverなスクリプトを書いて自動化している人はいそうですが、レアケースだと思います。
テスト仕様書からテストデータを作るのではなく、テストデータから仕様書を作る
よく考えれば当たり前のことです。
実運用中のソフトウェアでテスト仕様書とテストに齟齬があり、テストを書き換えると本体が動かなくなるという事件が発生した際に、この原因は二重管理にあります。たぶん片方しか変更しなかったのでしょう。
一元管理しないと問題になります。テスト文書からテストを作るより、テストを元にテスト仕様書を自動生成するのがラクなので後者を選びます。
「コマンドで実行できて人間向けに変換できるテスト手順書フォーマット」の要件
- 手順書通りに実行できるソフトウェアが作れる
- そのソフトウェアをCIで実行できる
- エンジニアにとって可読性が高い
- テストの順番を指定できる
- コメントを書ける
- テスト手順からテストドキュメントを作成できる
テスト手順書の前提
- APIのテストはコンピュータが行うものである。間違ってもキーボードと目視で行うべきではない。
- 日に何度もテストが行われるべきである。
- 要するにCIで使える必要があるので、軽くて速いことが望ましい。
- テストは順序だって行われる。
- テスト手順書から「テスト手順書（非エンジニア向け）」を作成できる必要がある。
私が作成中の例
version: '0'
config:
timeout: 120
testcases:
# test GET
- name: "Test case 0"
url: http://api:8080/
method: GET
retry: -1
want:
statuscode: 200
bodypath: ./txt/getwant.txt
# test 400
- name: "Test case 1"
url: http://api:8080/api
method: GET
want:
statuscode: 400
bodypath: ./txt/empty.txt
# 繰り返しなぜテストフォーマットが必要になるか
- 開発者が開発中にAPIが正しく動いていることを常に確認するため
- 開発の出戻りの発覚を減らすため
- QAエンジニアの負担を減らすため
- QAエンジニアがいなくてもなんとかするため
まとめ
興味が合ったら私のプロジェクトを見たり、連携している連絡先から連絡をしたりしてください。 まだ、ドキュメント化は未着手ですすみません。