テストの諸々のドキュメントをテキストベースで作ってみるにはどうすれば良いかを考えてみた。
空気も冷たく、朝布団から出て行くのが億劫な季節となりましたが、みなさまいかがお過ごしでしょうか？
私、なそはアドベントカレンダー 19日目の記事を元気に書いております。
@akiyama924さんの次の日と知り、緊張で押しつぶされそうです。
と言っていても、始まらないので元気に始めましょう♪
今日の趣旨はタイトルの通りです。
アジェンダ
- テキストベースとは？
- なぜ、そんな恐ろしいことを思ったのか？
- 何を対象にドキュメントを作成するか？
1. テキストベースとは？
*.csv や *.txtといったメモ帳やサクラエディタ、秀丸とかで編集するファイル形式です。
2. なぜ、そんな恐ろしいことを思ったのか？
テストに関わるドキュメントは長い間、最強のツールExcelによって運用されています。いまでも最強のツールとして君臨しています。使いやすいですよね。
とはいえ、最強のツールは最近Googleのスプレットシートに置き換えられることもあります。結局、表計算ソフトを使っているんですよね。
そんな最強のツールではなく、テキストベースで作ってみることを検討しているのは、ドキュメントのバージョン管理をしたい。
例えば、開発ではPlantUMLを用いてテキストベースでUMLを記載することが増えてきています(なそ調査、サンプル数1)。しかし、テストのドキュメントをテキストベースでバージョン管理を目論んでいるのはそんなにいないのではないでしょうか？
大きく分けて理由は３点あります。
- なぜ、修正したのかを明確に記載したい
- 1つのドキュメントをメンテナンスし続けたい
- Gitにコミットしたい
1. なぜ、修正したのかを明確に記載したい
バージョン管理を行うとコミットログを残すことができます。Excel等々では取り消し線を引いて赤字でホゲホゲみたいなローカルルールに従う必要がないです。また、修正理由や変更点にJIRAとかのチケットのURLを書いても大丈夫です。運用設計は必要になりますが、ドキュメントは常に最新に保つことができます。
2. 1つのドキュメントをメンテナンスし続けたい
アジャイルテストを行う場合に、実際にあったのが「テスト計画_SprintXX」といったファイルがそれぞれ作られ続けていました。これってSprintXXとSprintXX+1の差分をみるとかはあると思いますが、ファイルが増え続けます。そうではなくて「テスト計画」として1つのドキュメントで常に最新にしてクリーンな状態にしておくとどのファイルを見れば良いかが明確になります。
では、SprintXXの時のテストのドキュメントを確認したくなったらどうするのかというとSprintの終わりにTagを切ってSprintXXとしておけば良いのではと思っています。
3. Gitにコミットしたい
Excel Onlineやスプレットシートはオンラインでも使えます。それならGithubとかで管理するのも別に良いのでは？というかテストコードを書き始めるとバージョン管理が必須になります。それなら先にやって慣れておいてもいいんじゃないですか？
あとコミットするとなんか終わった感するんですよね。私だけですかね？
コミットすることでバージョン管理ツールのレビュー機能が使えたりと開発と同じ土俵で考えることを進めることができます。
という感じで、ドキュメントをバージョン管理するメリットとして差分を確認できます。それを行うためにはテキストベースである必要があります。手段が先か目的が先かという話はあります。しかし、「やってみたい」は大事な気持ちです。
3. 何を対象にドキュメントを作成するか？
今回は、テスト計画 → テスト設計 → テストレポートをテキストベースのドキュメントを考えてみましょう。
| ドキュメント名 | テキストベース |
|---|---|
| テスト計画 | マークダウン形式 |
| テスト設計 | CSV形式 |
| テストレポート | マークダウン形式 |
テスト計画
テキストベースなので、書き方もシンプル。罫線とかはもちろん気にする必要がありません♪
# title
## Test Base
カラオケシステム http://karaoke/system
## Risk
この辺不安
## Test 端末
iOSを中心にテストする
・・・
と言った具合に別にExcelじゃなくても書けるんですよね。
大きな表はかけないですが、表も書くことができます。
テスト設計
テスト設計で書かなくちゃいけないことってなんでしょうか？
私はシンプルに
- テストでみるべきポイント
- 操作手順
- 期待値
- 実行結果
- 実行時に気が付いたことを書く備考
このくらいでも良いのではないかなと思っています。当然、会社の方針によっては大分類、中分類、小分類と記載することもあります。
テストでみるべきポイント,操作手順,期待値,実行結果,実行時に気が付いたこと
カラオケの電源,左下の電源ボタンを押下する,電源がONになること,OK,
テストレポート
テスト結果をレポーティングすることになります。これも壮大なドキュメントを作成する必要はないと思っています。
# テストレポート
## スケジュール
2019/12/19 - 2019/12/20
## 今回の品質について
ばっちり👌
## 発見された障害
| やばいやつ | 10 |
| そこそこやばいやつ | 2 |
## 所感
やばいやつが多く、リリースするために十分なテストが実施できていない
このように、記載する内容をシンプルにして何を伝えるかを明確にすることでテキストベースでテストのドキュメントを作っても運用できそうなイメージがつきました。
今使っているテストのドキュメントをテキストベースにしてみるためにどうすれば良いかをこの年末考えてみると良いのではないでしょうか？断捨離することで本当に必要なテストのドキュメントが作れると無理せずに生産性が高まり、働き方改革に繋がるかもしれません。
重厚なドキュメントも重要ですが、今一度身軽なテストを考えみるといかがでしょうか？
さいごに
おすすめのマークダウン形式でかけるテキストエディタ
Typora はてなブログと同じように見たまま編集ができる。
それでは、本日はなそがお送りしました。
