うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

テスト全体の良い書き方について。 #swtest_jp

概要

テストをつくるときにどうやって書いたらいいのか困るという話をよく聞きます。とても簡単な例ですが、これをするだけでもずいぶんと違うという意味で、自分がよく使う例を書いてみます。(実際にはリスクベースドテストとして成立させるために更に項目を追加したものを使っています。ですが、基本はこの形であり、ここにある考え方が重要だと思っています。

つまり、ツールを使えばもっと綺麗に出来るけど、まずはMarkdownでもExcelでもなんでもいいからやれる感じで整理できる方法というところです。

僕がこの考え方を気に入っているのは、プロジェクトのリスク管理手法とあまり違わないので、別にテストではなくて、例えば「こういった人が必要」とか「こういったツールがいる」とかになるという点です。

まとめすぎると「BDD-Styleに対して、リスクという親要素を加える」というくらいです。

構成のテンプレ

基本的に3段構成です。

冒頭の「BDD-Style」と言っているのは、「回避していることを保証する手段,デシジョンテーブルなどのパラメタライズ」の部分が該当します。

例示すると(悪い例かもしれないですが、イメージを伝えるために)

  • はてなユーザーが投稿後のブログを再編集できないリスク
    • 管理画面から投稿後のブログを再編集する

      利用ブラウザ 文字数 文字種 記法 結果
      Chrome 3x 2000 日本語 Markdown 編集できる
      IE 8 50000 ギリシャ文字 Markdown 編集できる
      IE 6 50000 アラビア文字 Markdown 編集できない
    • xxxxx

      xxx xxxx
      xxx aa
      yyy bb

使うツール

これを書くためにはツールは非依存ですが、テーブルを綺麗に表示できるものがあるといいでしょう。(ライブプレビューでもいいし、表を綺麗に書けるものでもいい 例えば、MarkdownやAsciidocでやるなら、Atomなんかがいいかもしれません。別にExcelでも構わないと思います。

ちなみに僕はOrg-Mode一択です。

それぞれの説明

簡単ですが、3つそれぞれについて説明します。

回避したいリスク

トップレベルにくるのは「このプロダクトにおいて何を回避しなければいけないか」というリスクを書きます。ゴール指向などではゴールを書くべきところなのですが、それは何かを生み出すという視点で有効です。僕のような何かを安全に保つという視座においては「何が起きてはいけないのか」というリスクで書くことが有効でした。

例えば、「登録ができる」だとそれしか確認しない事が多くて、 「登録できないリスク」と書かれていると逆のパターンである「登録できる」はすぐに思いつくので、「登録できる」「登録できないって事は起きない」の両方の視座で確認しやすかったのです。

また、このリスクは「単体テスト不可能になるリスク」とかも書けますし、「チームのコアデベロッパーが来月でいなくなる」とかも書けます。

リスクのフォーマットについてはリスクベースドテストやリスクマネジメントの本で書かれているようにいろいろあります。 なんとなく考えてみる分には「誰にどんなことが起きる」というイメージでまずはいいと思います。

回避していることを保証する手段

リスクには「それを回避する手段」がひも付きます。「それが起きないことを確認する方法」であればテストになります。

これはいわゆるテストスイート名やシナリオのタイトル、ユースケースのタイトルが該当します。どのような手段をとっているかがわかれば、別に2,3の単語でもいいとは思います。わかれば。

テストではない場合、つまり先の「チームのコアデベロッパーが来月でいなくなる」とかだと「コアデベロッパーはデベロッパーと代わる代わるペアプロする」とか「コアデベロッパーが参考にしている情報をWiki化する」とかでしょうか。

デシジョンテーブルなどのパラメタライズ

テストコードでいわゆるパラメタライズされているとか、テストの組み合わせ表とか、CucumberなどでのExamplesが相当しそうなところです。 この表でどこまでを書くかはチームやシナリオの書き方に依存します。ですが、個人的にはシナリオのステップをテーブルにはあまり書かないようにしています。 だいたい次の4つに分類できます。

  • 直接入力するもの
  • 環境として入力になるもの
  • 直接出力するもの
  • 環境に出力するもの

いいところ

例えば、POだったり顧客だったりPMだったりが「プロジェクト後半に爆発しないようにテストしたいな」とか「最低限リリースできるラインは保証されているのかな」とか「何が保証されているのか」といって見たいときにはだいたい「回避したいリスク」の一覧を見ると議論できました。

これは設計であって、実装ではないというところ

先にも書きましたが、工夫をすることでももっとよくなります。リスクはタグで分類するとか、テーブルに書く内容をライブラリ化するとか。

この方法論では、書くときの考え方の補助と議論しやすい見え方の補助を目的としています。なので、「テストを実行するときに面倒になるかもしれない」ということには対応していません。 例えば「リスクAとリスクBに対応している手段Xがあるから、手段Xでそれに紐づくパラメタライズをうまくマージすれば、テストを実行する時間が短くなる!」とかはよくある話しです。 この辺はテスト実行の最適化と僕は読んでいて、いわゆるJITコンパイルみたいなものだと思っています。 それを簡単にできるようなツールを開発するのが、いまの僕のちょっとした目標です。

リスクを思いつく方法

今まで出してきたバグやチームの状況を見て、推測するのがいいと思います。ですが、何か初めてのことがあると急にできないのもよくあると思います。

そんなあなたに本当に素晴らしいものがあって、鈴木三紀夫さんの「意地悪漢字」というやつです。いわゆるガイドワードなのですが、達成したい要求やプロダクトライフサイクルとこの意地悪漢字を組み合わせるといい感じにリスクがぼんぼん見つかります。ぜひご活用ください。

意地悪テストのブログ

意地悪テストのスライド

意地悪テストのスライド

推奨書籍

体系的ソフトウェアテスト入門

体系的ソフトウェアテスト入門

ソフトウェアテスト12の必勝プロセス-テストの計画・準備・実行・改善を究めるために

ソフトウェアテスト12の必勝プロセス-テストの計画・準備・実行・改善を究めるために

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)

セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)

まとめ

ほとんどのテストはリスクベースドテストなんだから、テストの書き方からして、リスクベースドにするのが早いです。明確にしておかないと、なんのためのテストかわからない(わからなくなる)し、自信を持ってリリースするためには、自分だけがわかればいいっていうのは少ないほどうれしいはず。