Webディレクターが考える「テスト」の大事さについて

こんにちは。Webディレクターのともぞうです。
今回はテストについて書いていきます。

前提のお話

テストといっても、エンジニアリングなテストの話ではありません。わたしはWebディレクターなのでコードをちゃんと書けないからです！

ユニットテストや単体テストとかの話はきっと別の誰かがしてくれるはずです。後述になりますが、Webディレクターが書ける機能テストについて書いていきます。

テストの種類

Webディレクターができる・書けるテストは大きく3つに分類できると考えています。

1. デザイン再現テスト
2. ブラウザ表示テスト
3. 機能テスト

それぞれどんな内容かというと……

デザイン再現テスト

デザインPSDの再現度をテストする作業です。PSDとブラウザを重ねてズレがないか？　というテスト。全端末、全ブラウザに対しておこなうことは非現実的なので、ベストビューというものを定義して、限定したテストをおこないます。

ブラウザ表示テスト

IE11やAndroidなど各ブラウザで崩れがないかの表示確認をするテストです。

機能テスト

リンク先は間違っていないか？ 表示件数や期待する表示内容になっているか？ CMSで入力した内容が正しく出力されているか？ を確認していくテストです。

……というものだと考えてます。このなかの、機能テストについて書いていきます。

機能テストの必要性とメリット

必要性

品質管理の観点から必須なものだと思います。あらかじめテスト項目があるということは仕様が固まっているはずで、そのテストをおこなうことで仕様通りにサイトは動いていることを確認できます。我々制作側がWebサイトを納品するうえで必要なものです。

メリット

プロジェクトを理解していない人でもテストに参加できる

テスト項目がしっかりと書かれていれば、プロジェクトメンバー以外にテストを依頼することも用意です。仕様書を読む必要もなく、各テスト項目がOKかNGだけを見てもらうだけになるためです。

バグチケット起票の手間を省ける

テストの結果がNGであれば、そのテスト項目がOKになるように修正すればいいだけなので、機能テストに関してはバグチケットを起票することを省略できます。これだけでも結構な時間と面倒くささを解決できると思います。

仕様が明らかになっていく

テストを書く際に改めて仕様を見直す必要が出てきますし、仕様が決まっていない場合は詰める必要が出てきます。そのため、仕様策定漏れなどの発見ができます。

テストを書くにあたっての準備

前述のメリットの部分でも少し触れましたが、テストを書く場合は仕様が固まっている必要があります。何が正しい状態なのか？ が明確でないとテストの合否が分からないためです。

極論、ものすごく細かい仕様書があれば、テストを書く必要はなく、仕様書のとおりに動いているか？ を確認すればいいだけになります。

テストの書き方

わたしはテストを書くときはChibinekoというサービスを利用することが多いです。

Chibinekoはソフトウェアテストを得意としている株式会社SHIFTが運営しているサービスです。とても手軽にテストを書いていくことができます。弊社バックエンドエンジニアのまさくにに教えてもらいました。

書き方

• 記事一覧へボタンを押下で /media/ へ遷移する
• 記事詳細へのリンクが公開日の降順で5件表示されている

みたいな感じで書いていきます。

動作や場所に対して期待する内容を書いていくとテストになります。

こういったテスト項目を各ページに対して書いていきます。しかしページ数が多いサイトだと重複したテストが増えていって大変なことになります。なので、わたしはまず共通パーツのテストを書きます。

各ページに対してのテストでは共通パーツを除くそのページ固有のテストのみを書くようにします。

弊社サイトリニューアル時に書いたテストの一部

下記のよう記法でChibinekoに書いていくと図のようになります。

# ページ名
## コンポーネント名
### モジュール名
テスト項目

さいごに

テストってとても大事なもので、実施することで品質担保もできるし、考慮漏れも少なくなるのでいいことだらけです。

今年の４月に弊社サイトのリニューアルのWebディレクターを担当したのですが、そこでは1,000項目を超えるテストを書きました。(これが多いのか少ないのかはわかりませんが……)

書いていくうちに仕様が詰まっていないところの早期発見につながりました。

また、テストが最初からOKになるようにエンジニアの方にセルフチェックしてもらい、ダブルチェックでわたしが実施する、といった動きもでき、仕様を定義したものに対しては効率よく品質を担保できて、テストのメリットを感じました。

まずはモジュール単位で切り出して小さくテストを書いていくといいと思います。もしくは運用・保守などの比較的小さいものとかはうってつけですので試してみてください。

そして本当の最後に……マサカリが飛んでこないこと祈ります……。