JaSST東北が終わって息をつく間もなく開催した勉強会。
今月のお題は「テスタビリティの高い仕様書を書こう！ 」でした！！
場所はコワーキングスペースのソシラボさんをお借りしました。
集まった参加者は14名でした。いつもありがとうございます。
機能仕様書
https://docs.google.com/file/d/0B8LNxxiwFnpiLWR2dXJnQ1JENmM/edit?usp=sharing
サイト
http://kanbanlistfortohokutest.herokuapp.com/
今回は機能仕様書のテスタビリティということで考えてみました。
実は「テスタビリティ」というのは、仕様書のレビュー時の観点の1つでもあります。
以前の勉強会でレビューを実施したときに、参加者の一人がテスターの立場でレビューすると指摘が沢山でましたと言っていたので、今回はもう少し突っ込んで考えてみようと思いました。
「テスタビリティ（テスト容易性）」ってそもそもなんでしょう？
近頃だとテスト開発駆動でよく使われるのを聞きますね。
またソフトウェア自体の品質の1つとしても使われることがあります。
それでは「機能仕様書」の「テスタビリティ」ってなんでしょう？
自分が考えた答えは以下のようになりました。
「その仕様書から、実施するテストが想像できるか？」
そもそも機能仕様作成のときにテストケースを考える必要あるのか？ってことですが、答えは「必要あります！！」です。
先日行われたJaSST'13東北の基調講演で湯本さんも開発の全ての段階でテストを意識すると言っていました。
「開発したので、テストお願いします」という時代は既に過ぎ去っているのですね！
また「ずっと受けたかった要求分析の基礎研修」という本には以下のような記述があります。
皆さんは、テスト項目を抽出するとき、無意識のうちに「完成したシステムの姿を強くイメージしながら要件を見直す」という行動をしています。完成したシステムの姿を強くイメージすることは、要件の漏れや矛盾を見つけ出すことに繋がります。（P207）
テスタビリティを考えるということは、そのシステムについてより深く考えることになるのです。
ということで、早速例題をやってみました。
例題1
以下の、3つの仕様のうちどれがテストが想像しやすいでしょうか？
実際にテストケースを考えてください。
① Passwordが不適切な場合は以下のメッセージを表示する
② Passwordが短過ぎる場合は以下のメッセージを表示する
③ Passwordが6文字より短い場合は以下のメッセージを表示する
これは簡単だったと思いますが、①、②は明確になっていないですね。
でも日本語としては間違っているわけではありません！！
なので、設計やテスタビリティを意識しないで読むと何にも問題ないように見えちゃうんです。
もちろんお客さんに見せる機能仕様であれば①や②でもいいのかもしれません。
機能仕様書の目的、使う相手によっても違うということです。
機能仕様書のテスタビリティをあげるための活動①
「曖昧さを回避する」
曖昧さを回避するということで、以下の例題を実施してみました。
例題2
以下の、仕様にはどのような問題点があるでしょうか？
「本モジュールでは，電源がONのときの初期化処理、電源ライト点灯処理を実施する。」
この例題は「理系のための文書作成術」から引用させてもらっています。
http://www.kumikomi.net/archives/2010/08/ep23doc1.php?page=2
読み取り方が違ったり、単語の使い方など色々問題点がありそうですね。
このサイトは本当にいいこと書いてあるので一読することをお勧めします。
続きまして、『曖昧』な単語を挙げてみるというグループワークをやってみました。業務の経験がある人はバシバシだしてましたね。
面白かったのは「（仮）」という単語。まだ決まっていないときに使うらしいのですがいつ決まるんでしょうか？
大抵いつまでも決まらないんですよね（笑）
さらに今回の仕様書の4.1.5と4.1.6で考えてみます。
①実施するテストが想像できるか？
②『曖昧な単語』に当てはまるものは無いか？
『等』、『すぐに』、『適切に』などはすぐに見つけれたようです。
気になったのは以下の『リアルタイム』の記述。
仕様：残り文字数はリアルタイムに左上に表示される。
今回は文字入力を確定した時点、または文字を削除した時点で文字数が更新されるので不適切だと思います。リアルタイムって書かれると周期を想像しちゃいますよね？
次いで非機能要求は結構厄介という話をしました。
非機能要求は人の感覚によることが多いので、テストはできないです。
そのため機能仕様書に、顧客からヒアリングした非機能要求をそのまま書くとテストができなくなります。
なのでテストできるように仕様を決めてあげる必要があります。
例えば・・・
非機能要求）タスク一覧をすぐに開くこと
↓
機能仕様） タスク一覧が0.5秒以内に開くこと
仕様を決めた後で0.5秒以内に開く場合に想定ユーザが「すぐ」と感じるかどうかは確認の必要があると思います。0.5秒でも遅いと感じる人がいるかもしれません。
機能仕様書のテスタビリティをあげるための活動②
「理解しにくい条件や条件のモレはないか？」
これまた個人ワークからグループワークの流れで、4.1.3のちょっと理解しにくいログインの条件を整理してもらいました。
Emailが登録済みである、かつ登録されていたPasswordと入力されたPasswordが一致しない、または、メールアドレスが登録されていない場合は、入力されたパスワードの文字列を削除し、再入力を促す。
整理の仕方は自由としたので、どんな風に書くのかちょっと楽しみでした。
参加者の書いているのを見ていると、箇条書きで書いている人、表で書いている人、図を使っている人様々でした。
自分が一番分かりやすいなぁと感じた参加者の図はこんな感じになります。
感覚的にはCFD技法の図に近いですね。
CFD技法＆ツールも近いうちにテスト勉強会で取り上げようと思っています。
CFDについては以下のサイトが参考になります。
http://softest.cocolog-nifty.com/blog/cfd/
機能仕様書のテスタビリティをあげるための活動③
「表や図を活用する」
今度は4.1.7の状態の変更の仕様を表または図を描いてもらいました。
タスクはドラッグ&ドロップでTodo（High / Middle / Low）、Doing、Waitingの状態へ移動できる。
Done以外のタスクのチェックボックスにチェックをつけるとDoneへ移動する。
Doneのタスクのチェックを外すと、Todo（Middle）に移動する。
自分の回答例は状態遷移表と状態遷移図を描きました。
参加者の学生から「この仕様が読み取れないんですけど・・・」って言われたので、それは図や表を描いた効果だよと話しました。上の仕様をぼんやりと読んでいるだけでは決して分からないことです。
機能仕様書を読みやすくするための活動
「能動態を用いる」
テスタビリティではないのですが、仕様書を読みやすくするという点で受動態の文章は気をつけなければいけないです。運営の福島さんからは「受動態で書いているうちは、どっか他人事」という意見をもらいました。なるほど確かにそうかもしれませんね。
（受動態）タスク削除前に確認のメッセージボックスが表示される。
（能動態）タスク削除前に確認のメッセージボックスを表示する。
ということで、最後は恒例になりつつあるJoJo〆めです。（ちょっと変更しました）
機能仕様書を書く時、仕様もはっきりしない、
条件も読みにくかったり、漏れているようでは
テストできないのは確実なんじゃ！
ジョセフ・ジョースター
今月もありがとうございました！
この仕様はテストできるかな？と考えるだけでもかなり効果あると思います。
何か1つでも現場で実践してみてください。
Toggeter 今回のまとめ
理系のための文書作成術
http://www.kumikomi.net/archives/2010/08/ep23doc1.php
QAの革新なくしては、世界水準のソフトウェアはつくれない
http://www.itmedia.co.jp/enterprise/articles/0501/14/news003.html
テストをどう考えていますか？
http://www.itmedia.co.jp/enterprise/articles/0412/28/news032.html