underscore42rina.hatenablog.com の続きです。
目的（何のためにやるのか）
一般的？に言う「テストをおこなう」のがココになります。
システムによって、いろいろなテストをおこなっています。
スクリプトテスト＋探索的テストって？
システムのテストは、わたし一人でおこなうことが多く テストの割り振りをすることがほとんどありませんでした。
それもあって、スクリプトテストとか、探索的テストという切り分けをすることもありませんでした。
わたし的には「オール探索的テスト」なんだと思っていましたが、
スクリプトテストと探索的テストとわけたほうが、理解はしやすそうなので、エントリーではわけています。
スクリプトテスト
スクリプトテストと書きましたが、わたしがおこなうスクリプトテストは
「３日前にどこまでテストしたか忘れないため」にテストケースを残している。くらいのものです。
*1
次に作っているドキュメントなどをご紹介しますが、いずれもテスト実施中に書きます。
なので、設計時間というものが存在しません。
一回書く時間は、分単位じゃないかなーと思います。（何時間も、は、よっぽどじゃないとかからないはず）
スクリプトテストでは、「テスト仕様書兼結果報告書」と呼んでいるExcelファイルを作成しながらテストを実行します。
テスト仕様書兼結果報告書とは
Excelファイルを作成していました。完全ではありませんが、どこかから持ってきたのをいい感じに変更していったら、こんな形になりました。
フォーマットは以下のとおり*2
- 大項目(feature: 概要)
- 中項目(Scenario:シナリオ)
- 小項目
- 事前準備(given: 前提)
- 項目/テストパターン(step)
- テスト結果/(then: ならば)
- テスト者
- 日付
- OK/NG
- 備考
括弧をみるとお気づきの方もいるかと思いますが、
一時期turnipの導入を検討していて、勉強した際にこの形にしました。
実際は概要といいつつ、メニュー名だったりしてまったく文章ではなく単語になっていたりします。
スクリプトテストのテストケース
また別の機会に書くかもしれませんが、 テストケースは、「忘れない」レベルのものしか書いていません。
例えば、ログイン画面だったら
- 正しく表示できること*3
- ログインできないこと
- ログインできること
くらいしか書いていません。 （実際テストするパターンはその数倍のケースになるはず・・・）
図におこすもの
UMLがほとんどわかっていないままなのですが、
仕様の整理が必要になる場合に、いくつかの図を書いています。（書くのはリストならExcel、図ならノートに手書きが多い）
私は文章よりも図で理解する（イメージを沸く）方が得意のようです。
- 状態遷移図
- デシジョンテーブル
- シーケンス図のような何か（時間軸が発生する場合）
が多いと思います。
とくに状態が複数でてくるものは、状態遷移図で理解するようにしていますし
「年度」が出てくるようなものは、図を書かないと理解できないので、
図に書いて、それでもわからないとか質問があったりするとその図を見せて教えてもらったりします。
テストデータ作成
わたしは手動テストしかしないのですが、同じようなデータを複数作成するときはSlenium IDEを愛用しています。
以前はExtentionでXMLのデータを順次読み込んで動作させることが可能でしたので
必要があれば、テストデータも作成していました。（とくにクレカ系のパターン違いとかはよかった。あと都道府県とか）
こちらは数分ではできなくて、数時間かけたりしていました。
探索的テスト
探索的テストをはじめるタイミング
タイムボックスなどでスクリプトテストと探索的テストの時間をわけていないので、気になる動きがあれば探索的テストのはじまりです。
でパターンわけしていますが、Dパターン・・・になるのかな。きっと。
探索的テストってなんぞや？
探索的テストについては、資料やブログも公開されていますので読んでみるとよいと思います。
資料を読むと、私はこれらとまた違ってそうだったりします。。
- 探索的テストってなんぞや？が書かれているSlide
www.slideshare.net
www.slideshare.net
- 探索的テストを勉強会でやってみる ameblo.jp
どんなテストをしているのか
PHPカンファレンス福岡2018で、実際にテストしてみましたのでご紹介します。
「Testing Live!!!」 フクダリナ - YouTube
（4:25くらいからテスト実行をしています）
ただ、こちらの場合、先ほどのテストケースも全くなくやっているのですが
普段は前述のテスト仕様書を見て、項目を決めてテスト実行しています。
といっても、動画のように気になりはじめたらどんどん横道それてIssue書くこともままあります。
いろんな視点から整合性を確認する
www.slideshare.net
資料に掲載していますが、私のテストは「整合性がとれているかどうかをいろんな側面から確認する」感じです。
- 前の画面と同じか
- 上の情報と同じか
- 他の権限と同じか
- 他のメニューと同じか
規則性があるかを探している感じなのかもしれないです。*4
Issueの確認
テスト中に出た不具合やカイゼン案は、すべてインシデントレポートを作成します。
Issueの書き方
以前Issueの書き方勉強会をしたときのブログとSlideが参考になると思います。 underscore42rina.hatenablog.com
エンジニアから戻ってきたIssueの確認方法
対応してもらった（または却下された内容）を読んで、
そのとおりに改修されているか確認します。
基本的には、そのとおりに動いていればCloseするのですが、いくつかテストを増やすときがあります
- 改修内容が想像と違った場合
- 改修内容で他の機能や画面にも影響がありそうな場合
- 計算などでIssue以外に前回OKしたテストケースをもう一度実行したくなる
- 他・・・・
ぱっと思いついたのがこんな感じなので、また別のエントリーに書くか、加筆すると思います。
テスト仕様書兼結果報告書
Issueを発行するときに、OK/NGの欄に「NG」と入力します。
ただし、エンジニアから戻ってきたIssueの確認時には、このNGのところはまだ残したままにすることが多いです。
*5
このNGは3回目のテストで使用します。
