第一回「仕様書はテストの道しるべ」

 
初めまして。
タロスカイでテストと庶務方を担当している佐藤と申します。
最近では、ディレクター職の先輩さんのアシストなどもしています。俗にいう、ADという奴です。
 
さて、自己紹介でも触れて”いない”ように、私はエンジニアではありません。
遠い過去にはIT企業で「エンジニア/プログラマー」として働いていたことはありましたが、その数年間では、１行のコードを書くこともなく終わりました。
そのため、技術的なことは全然わかりませんし、専門用語が出てきても、まずインターネットで調べるところから始まります。

何しろIT業界は日進月歩、すぐに新しい技術や単語が出てきますから。
 
今回から始まるエントリーでは、そんな私がテスト業務の主担当として携わるにあたり、気を付けていることや失敗談を綴っていきます。
これを読んでいる方に、「ソースコードが１行も書けない人間でも勤まるんだよ」ということをお伝えできればいいな、と考えています。
 

初回は、そもそもテスト業務とは何か、ここに触れるところから始めていきましょう。
 
まず大前提として存在するのは、人間とはミスをする生き物だということです。
いきなり哲学的な物言いから入りましたが、異論のある方は少ないんじゃないでしょうか。
もちろん、多くの方は何かをする時に完璧を目指しているでしょうが、完璧な結果を出すことは容易ではありません。

例えば、買い物をしようと街まで出かけたのに財布を忘れたり、財布は持って行ったけれどポイントカードを出し忘れたり。

これは実作業においても同じで、開発部門の方々は顧客や企画部門からの要求仕様を実現すべく、頑張ってソフトウェアやwebサイトを作ってくれているわけですが、残念ながら完璧とは限りません。
不具合が潜んでいることがあるのです。

そこで、意地悪にも「ちゃんとできていますか？」ということを検査するのがテスト業務であり、私のようなテスト担当のお仕事なのです。

それでは、私が日ごろ気を付けているチェックポイントを見ていきましょう。

仕様を確認する

「えっ、それって当たり前じゃないの？」なんて声が聞こえてきますね。はい、その通りです。
webサイトの開発のみならず、製品開発全般において言える共通の観点です。
そんな当たり前のことをわざわざ挙げたのは、それが確認作業の基本であると共に、しばしば「仕様」を起点にした不具合が検出されるからなのです。
 
「仕様を起点にした不具合」の中で、「仕様未達」については恐らくもっとも数多く、誰もが想像しやすいケースですが、せっかくなのでここでは「仕様達成のチェック」の裏側に潜む危険なポイントにスポットを当てていきます。

 
それは、大きく分けてこの三つ。
 

　１．仕様で定義されているのか

　２．要件ではどこまでの範囲をカバーしているのか

　３．要件が実現された時に、どういうアウトプットになるのか

これらをざっくり言うと、
 
１：仕様で定義されているのか

自社または開発部門に判断を任されている要件についてはこちらで決めますが、「こうしてほしい」という要望がある場合、見た目や数値についてちゃんと決めなければ、正誤の判断ができません。

曖昧な要望の場合、頑張って実現させても、後から細かい修正指示が飛んできたりするのです。最初から決めとけよ、て思いますよね。

２：要件ではどこまでの範囲をカバーしているのか

これは１の延長です。ここでは、webサイトのボタンを新デザインに変更する場合を例にとります。

「内部実装的には別の機能なんだけど、表示上は同じボタンを使っている」という箇所で、新しいボタン表示を適用させるのかどうか、ということです。

顧客（または企画部門）は見た目の同じボタンは全て置き換えることを要求していたのですが、仕様に明記していなかったため、開発者は「機能上別なので対応しなかった」ということが起こってしまいます。

３：要件が実現された時に、どういうアウトプットになるのか

開発とは「顧客や企画部門の要求を、期日やクオリティを守りながら実現する」作業で、そこに至るまでの取り決めが少ないことも多いのです。

そこで、仕様には載っていない部分、「何をどうすれば要求達成の確認ができるか」や、「新しい挙動はどうなるのか」ということを意識しなければなりません。
もちろん、見た目の変化も。

 
というわけで、
テスト業務における仕様確認の大切さという観点について綴ってまいりました。
 
続きまして第二のチェックポイントは……と行きたいところですが、長くなりましたので今回はここまで。
次回は「テレビを直したら水道管が破裂した話（仮）」をお届けします。
 
お楽しみに。