自動テストの時代に手動テストのことを考える #テスト

テストコードがないプロジェクトはありませんか？
そんなプロジェクトに限ってテスト仕様書がフリーフォーマットだったりします。
（GitHubにテスト用のissueを作って、フリーフォーマットでテスト項目書く、みたいな）

テスト仕様書を書いたことがない人がそのプロジェクトにJOINしたときに、わかりにくいテスト項目を書かれると、テストするほうはもちろん、テスト書いたほうも質問攻めになって生産性ガタ落ちです。

で以下のようなことに注意すれば、だいたい問題ないんじゃないかという考察。

テンプレート化

例えば必須の見出しを決める（テスト概要（目的） テスト対象（画面、バッチなど） テスト内容）
かっこつけて、概要、目的、対象、詳細とかするとわからなくなるからもっとカジュアルに崩す

どんな問題か

これはまあissue見ればわかるから明記する必要はない
issueに書かれている内容以外にも関連する問題を対応したとかあれば追記する

どう対応したか（issueから読み取れない場合）

issueに仕様のやり取りがあっても、長かったら追うの大変なので、簡潔に結果をまとめる
- 例えば、issueは単に「○○が一覧で見たい」だったとして
  - どの画面に追加するか、CSVで出力でいいのか、どんな項目があればいいか、検索条件は、とかの話し合いが行われていると、結局どうなったかわからない
  - その状態でつらつらテスト項目書かれても、どんな注意を払ってテストしていいかわからないから
  - 例えば検索条件を新規に追加したとしても、テスト者は新規かどうかわからないから、境界値テストとか抜けてしまう

どのあたりを注意して（中心に）みてほしいか

テスト項目並べただけだと機械的に実行してしまうため
細かく指定する必要はない
- 例えば、速度改善の対応だけど、SQL変更したから、変更前後で出力結果が変わらないこともみてほしいとか

どうやってテストすればいいか

粒度はテスト項目作成者にまかせる
上から順に流せるように書く
- なにも考えずに羅列すると、テストできないデータになっているかもしれない
  - フラグが変わった、作成日付が登録された、など
- 必要があれば、もう一度新規でデータを作り直す 直接DBのフラグを書き換える などの一言を入れる
何をするか、実行手順をしっかり書く
- 例えば変更前後の出力結果を見てほしいって上記で書いたからと言って、実行手順は省略しない
- わるい例：
  1. バッチを実行して結果を確認　←これだけだと手順が省略されているのできつい
- よい例：
  1. ブランチをmasterに切り替える
  2. 次のコマンドでバッチを実行する → xxx.sh xxx xxx
  3. あとで比較するので、出力結果をどこかにコピーしておく
  4. ブランチをXXXXに戻す
  5. 2と同様のコマンドを実行する
  6. 3でとっておいた出力結果と比較して、同じ結果になっていることを確認する
- テストコードを埋め込んでもらう必要があるときは、きっちり行数を指定するより、行数はざっくりで前後のコードを記述する ↓

例えば、
102行目に次のコードを追加

var_dump($saveData);

よりも、
100行目あたりを以下のように変更

$saveData = [
    'userId' => $userId,
    'data' => $this->getSaveData($userId),
];

var_dump($saveData); // ← ここを追加

if ($data = $this->TestModel->find('first', ['conditions' => ['userId' => $userId]])) {
    $saveData['count'] = $data ['TestModel']['count'];

のように指示したほうがわかりやすい。

結果がどうなればOKなのかを書く
- 例えば、
  - ○○をクリックする → ○○をクリックし、エラーなくCSVがダウンロードされることを確認
  - 画面を確認する → ××画面を開き、対応内容が反映されていることを確認
- ～が正しいこと は人によっては文句を言ってくるので注意
  - 一般的にはエラーなく、デグレなく、改修内容が反映されていることと思うけど
  - 「正しい」とはどうなれば「正しい」のですか？って言ってくる人はいる

最後に

私がフリーフォーマットでテスト項目書くときに気を付けているのはこんなところです。
これ以外にも思いついたら追記するかもしれません。
他に何かあれば、コメントお願いします。