Excelテスト手順書が幅を利かせるのは「コマンドで実行できて人間向けに変換できるテスト手順書フォーマット」が存在しないから

新社会人の皆様へ

Excelは表計算ソフトです。

大事なことなのでもう一度言います。

Excelは表計算ソフトです。

— ぷり (@pu_ri) 2019年4月4日

上記ツイートをみて激しく同意するところがあるので筆をとりました。

（私のブログ記事から加筆つき転載です）

悪夢の言葉： Excelテスト手順書

注記１：当記事にExcelを悪く言う意図はありません。Excelを表計算ソフト意外の用途で使うことに意を唱えているだけです。わかりやすいからExcelの名前を使っていますがSpreadSheet、ドキュメントツールなど全部同罪です。

昨日勢いで書いた記事を深く考えて纏めました。

ターゲット

• リポジトリ単位のテスト
• 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
 # 繰り返し

nameの下に、purposeとかdescriptionとか入れる予定です。

なぜテストフォーマットが必要になるか

• 開発者が開発中にAPIが正しく動いていることを常に確認するため
• 開発の出戻りの発覚を減らすため
• QAエンジニアの負担を減らすため
• QAエンジニアがいなくてもなんとかするため

まとめ

誰か作ってくれと思ったら自分が作るべきなので自分で作ります。
既存のものはちょっと要件を満たしてくれませんでした。

追記

興味が合ったら私のプロジェクトを見たり、連携している連絡先から連絡をしたりしてください。
まだ、ドキュメント化は未着手ですすみません。