Webサイト制作におけるテスト工程の難しさを考えます

Webサイトって、もはやアートじゃない？

こんにちは。バックエンドエンジニアのまさくにです。
子供の娯楽だった漫画、アニメの一部がアートと呼ばれるようになり、同じく大規模なゲームの全体や要素がアートとして遜色ないのと同様、ドキュメントを共有する技術であったWebも、もうアートの域に入っていると思いませんか？

僕は入っていると思うんです。良くも悪くも。弊社はそのアートを請け負って開発しています。特にデザイナーとフロントエンドエンジニアがデザイン部分を請け負うのですが、作業中の彼らの鋭い目は完全に絵筆を持った画家のそれ。

ささいな色差を何パターンも試行し、1pxを合わせ、0.1秒のアニメーションの違いをすべての要素に対して考える。デザインとアートの違いは議論を呼びそうですが、そのこだわりと熱度は僕から見て「アーティスト」なんです。

そこでバックエンドエンジニアたる僕は、彼らの作り出した創作物をWebサーバーに組み込みながら、どこかさめざめと残りの開発工程を思い、ふと考えるわけです。

「アートのテストって無理じゃね？」と。

そんなことを思う。たしかに思うけれども、しかし、Webサイトの実体はシステムだというのも動かしがたい事実。テストをすることは不可避。悲しきさだめ。僕がエンジニアである限り、テストに立ち向かわなくてはなりません。そうです。リリース作業は僕がする。

本稿では僕個人の「現代のWebサイト制作のテストは困難である」という勝手な仮説を立証すべく、ウォータフォール開発で行われる一般的なテストを振り返りながら、Webサイト制作における弊社でのテストへの取り組みをご紹介し、その困難性を洗い出したいと思います。

なお、ここではリリースするまでの機能側面のテストを述べることとし、グロースするためのテスト（A/Bテストなど）は含みません。また、ざっくりですが、Webサイト制作は「静的ページやWordPressなどを使用して、開発する機能数が少ないサイトを構築すること」とします。それと相対するものとしての「Webサービスのテスト」については、よく記事を目にしますし、ここでは述べません。

開発の一般的なテストについて

まずは比較のために、Webサイト制作に限らず開発の一般的なテスト工程を挙げます。ウォータフォールでいわゆる「テスト工程」と言ったら、だいたいこれだろうと思います。Vモデルの概念でもあり、安定感があり、長年世界で成功例を作り続けている手法です。

単体テスト

単体テストのテスト対象はモジュールやクラス、functionなどで、コード上の細かい粒度のかたまりが仕様通りに正しく動作するかどうか、In/Outが期待通りか、などのテストを行うものです。「ユニットテスト」とも言います。

ここ数年はTDD（テスト駆動開発）が普通に行われますので、コードよりも先に、この単体テストをテスト用ツールを使って書いておくことも多くなりました。各言語、各フレームワークで単体テストを行うためのツールが用意されています。

理想を言えば単体テストは、テスト対象以外のクラスやfunction、他のシステムからの影響を排除すべきです。例えばデータベースに入っている値でテスト結果が左右されてしまったりすると、テストになりません。そのため、データベースやAPIにテスト用のモックを作ったり、テストデータをあらかじめ用意したりして、対象とするコードのみをテストするようなお膳立てをします。

特にWebの分野ではそういったテスト用ツールが発達してきたこともあり、意図的に深いデバッグをするとき以外、手動や目視で確認するということはなくなってきたと思います。十数年前の組み込み開発や汎用機での開発では、「この時点での変数の値は何か」という情報をブレークポイントやログでひとつひとつトレースしたりしていました。魂の純度を上げるための作業だったと理解しています。

結合テスト

結合テストのテスト対象はモジュールやfunctionを組み合わせてできる結果の「機能」です。モジュールやfunctionが連携することによって、機能が仕様通り正常に、期待通りに動くかを確認します。

例えばWebサイトに「お問い合わせ機能」があるのであれば、「フォームを開き、正常に入力したら確認画面が表示され、メールが送信される」という、設計で定めた一連の機能をテストします（もちろん正常系だけではなく異常系も含め）。

このあたりは、企業やプロジェクトによっては「Selenium」などで結合テストの自動化を進めることも多くなったのではないでしょうか。しかし、テストが非常に楽になる反面、テスト作成にかける時間が増加してしまうことも考えられます。

システムテスト

システムテストの対象は、文字通り「システム全体」になります。例えばストレステストや負荷テストなど、非機能要件に関わる性能のテストを行うほか、他システムと連携した時に正しくデータの授受ができるかなど、外部連携の挙動をテスト。システムとして本番稼働に問題がないか、意図通りのものができあがっているかをチェックします。

検収

検収は発注者がプロダクトを受領する際のテストです。「受け入れテスト」や「ユーザーテスト」とも呼ばれ、発注した要件通りのものができあがっているかのテストを行います。魂の純度が低かったり、普段の心がけが悪いと、だいたいここで問題がおきます。

ただ多くの場合、発注者はシステムの専門家ではないため、検収のテストと言われても何をしていいかわかりません。そのため、開発したシステムのレクチャーや用意したドキュメントで「要件を満たしているか」の判断を行ってもらったり、本番運用をしばらく共同で行うなどの措置が取られます。

LIGではどのようなテストを行うか

現在のVモデルができあがったのが2005年だそうです。そこから13年経ちましたし、それ以前にも開発をしていたので、テスト手法は洗練され、失敗が少なくなったはずです。つまりこの手法に沿えば、Webサイト制作におけるテストの確実性も上がるはず。そのためLIGでも基本的にこのVモデルを意識してテストを行っています。

テストの計画を立てる

「Vモデルを意識して」と言っておきながらアレですが、基本的にWebサイト制作においては単体テストは作成せず、自動テストはほとんど構築できません。コーディングが終わったあと、結合テストとシステムテストを行うことになります。設計が実現されているか、要件が実現されているかということをテスト観点とし、手動での確認がほとんどになっています。弊社にはWebサイト制作における「いつものテスト」のような骨子があるので、その骨子に対して要件に沿った肉付けをして、テスト項目を作成します。

また弊社では要件定義をディレクターが行うため、テストの際も必然的にディレクターが多く動きます。しかし僕個人としては、Webサイト制作のテストは単体テストを省いていることからも「エンジニアが担保すべき部分が多い」と考えており、テスト項目の挙げだしと実施は自分がメインで動くようにしています。誰がテストを行うかはケースバイケースでしょう。

ただ、アニメーションのテストにはデザイナーとフロントエンドが必要だったり、ブラウザのバリエーションのテストは単純に人手が必要だったりするので、その都度適切な人員をアサインできるように事前調整を行っておきます。

このように、「何を」「どうやって」「誰が」テストをするか、あらかじめ決めておくのです。

テスト項目を挙げだす

設計、及び要件定義から、Webサイトがあるべき姿になっているか、冷静にテスト項目を洗い出していきます。書き出す場所はスプレッドシートかChibinekoを使用することが多いです。膨大な数になると思いますが、怯んではいけません。思いつくかぎりを書き出すことになるので、一度マインドマップで思いついたテスト対象を吐き出してから、整理して項目を作るのがおすすめです。

Webサイトが実現する機能として、下記に代表的なものを並べました。この程度の粒度で、ざっと数百〜千のテストを行うことになります。文字数や数値の境界値や同値のテストはわかりやすいと思いますが、「データが0件だったとき」、「相当数保存されていたとき」のテストが注意していないと逃しやすいです。基本的にこれらのテストを、事前定義したデバイスそれぞれに対して行います。気が狂いそうなんですが、世の中のみんなはどうやっているのでしょうか。

インフラ

サーバーの基本設定

• タイムゾーンはAsia/Tokyoになっているか
• 言語は日本語が設定されているか
• PHP7.2がインストールされているか
• 必要なPHPモジュールがインストールされているか
• nginx1.12.*がインストールされているか
• SSL接続が問題なくできるか

など。

デーモンのテスト

• chronyが自動起動し時刻設定がされるか
• php-fpmは自動起動しWebサーバーが立ち上がるか
• nginxは自動起動しWebサーバーが立ち上がるか

など。

セキュリティの設定

• firewallによって22、443以外のポートは閉じられているか
• sshのパスワード認証は不許可になっているか
• sudoはユーザーに許可されていないか

など。

ストレステスト、負荷テスト

• トップページへの秒間30リクエストでパケットのロストは起きないか
• リクエストによりCPU使用率が30％を越えた時、スケールアウトが発生するか
• どの程度のリクエスト数が一定期間あると、Webのレスポンスに1秒以上かかるか
• どの程度のリクエスト数が一定期間あると、システムがクラッシュするか

など。

アプリケーション

• WordPressのバージョンは4.9.5が稼働しているか
• S3 Offloadプラグインがインストールされ、有効化されているか
• 3時にバッチが起動し、日時集計が完了するか

など。

Webサイト

通常ページ

• メインビジュアルに設定された画像が表示されるか
• ヘッダーのアイコンからトップページへリンク遷移ができるか
• 投稿された記事が投稿日降順で3件表示されるか
• 投稿された記事のアイキャッチが表示されるか
• 記事名はhtmlエスケープされているか
• 「もっと見る」で記事一覧ページに遷移するか
• プライバシーポリシーが問題なく表示されているか
• （境界値）記事一覧ページで記事が19件以上の場合ページネーションが表示されないか
• 記事一覧ページで記事が20件以上の場合ページネーションが表示されるか
• 記事が1000件保存されている時、記事一覧ページは遅延なく表示されるか

など。

管理画面

• 記事投稿時画像がアップロードされ、S3に保存されるか
• 予約投稿設定した記事が、指定日時を過ぎると公開されるか
• 権限を持たないユーザーに対して、設定メニューは表示されないか

など。

フォーム

• （境界値）フォームの氏名欄が空白でPOSTされた場合、バリエーションエラーが表示されるか
• フォームの氏名欄が10文字でPOSTされた場合、確認画面に遷移するか
• （境界値）フォームの氏名欄が11文字でPOSTされた場合、バリエーションエラーが表示されるか
• （境界値）年齢に数値以外がPOSTされた場合、バリエーションエラーが表示されるか

など。

アニメーション

何が正解かが判断できないので、デザイナーとフロントエンドエンジニアが二人三脚でチェックを行っていきます。位置の調整、スピード、変化のチェックなどを行います。

• トップ画面から記事一覧ページへの遷移
• トップページのログインボタンホバー
• 一覧ページ記事アイキャッチのホバー

などなど。

精神を整える

テストから逃げ出そうとする自分、ずるをしようとする自分を戒め、これから何百、何千項目というテストに挑む自分を励ます必要があります。マジで。これは本当にマジで。次のように考えると整ってきます。

自分は心をなくした冷酷なアサシン。思考、感覚、スキルは極限までに冴え渡り、プログラムという広大な暗黒街に潜む醜悪な憎きバグを、一つ、一つ、この手で掴み取り、プチプチと無残にすり潰すのが唯一の快楽なのだ。それが自分の生きる意味。そのために生まれ、そのために殉じる。

静かに整ってきませんか？

そうでもないですか。

テストの実施

テストは無心で実施していくのみですが、一人のアサシンとして気をつけていることがあります。僕は、原則的にテストは「できた（OK）」か、「できなかった（NG）」かの二つしか選びません。ペンディングや対象外、ある意味でできている、というような曖昧さを残すことを許さないようにしています。

曖昧さを残すとテストがいつまでたっても完了しなかったり、自分の中で自信を得られなかったりするためです。「できた」か「できなかった」か、もしくはテスト項目が誤っているか、しか許さないことで、テストに確実性を持たせています。

また、「設定がそうなっているからOK」というわけでもなく、実際に動かしてみることが重要です。タカをくくっていると実際にやってみたとき、絶対に動きません。

バグや障害を修正する

ここまでで、バグや障害がたくさん洗い出されると思います。それらをチケット管理して、重要度や優先度の高い順から潰していきます。心理的にもバグに対して容赦ない対応が必要となりますし、理想的を言えばテスターと修正対応者が別々の方が望ましいと思います。

また、修正した箇所の影響がほかのページやロジックに影響を与えていないか、リグレッションテストを必ず行いましょう。直ったと油断をしていると思わぬ場所からプログラムが火を吹きます。

リリース＆検収

すべての人事を尽くしたら、Webサイトが完成します。ステージングでテストをするか、本番環境しかないかは場合によりけりですが、本番環境をお客様に渡して、検収を依頼しましょう。大なり小なり必ず問題は起きますのでめげないでください。絶対に何か言われますが、それはサイトができあがった証でもあります。「自分は要件通りのものを制作し、ちゃんとテストをした」という誇りをもって、お客様商売なので可能なかぎりの要望に答えていきます。

これがLIGのテスト工程です。

Webサイト制作でテストが困難な理由は何か

それでは、ここまでの内容をふまえて「Webサイト制作のテストが困難である理由は何か」を抽出したいと思います。

すべてのテストを行えない

弊社のほとんどの案件を占めるWordPressのサイト制作は、ビューの占める割合が大きく、単体テストにしては他モジュールへの依存が大きくなってしまいます。またほとんどの案件は一度作り終わるとお客様の手に渡るため、CIでビルド環境などを構築する必要性をあまり感じられません。このため単体テストが省かれがちになります。

さらに機能数も少ないことから、結合テストはシステムテストと同一視されることも多いです。この場合、Webサイトの組み込みが終わったあと、システムテストにてすべてのテストをまかなうということになります。総合的なテストの数は変わりませんが、段階を踏まないことで、手戻りなどが多くなる、仕様のミスが最後の工程に露呈する、などの事態が発生しえます。

ステージングが用意できない

最近はそのような事例も減りましたが、ステージング環境がコストの関係から作れないという条件はときどき発生します。特に、LPを作るだけなどの小規模な制作時にこの形式が多いのではないでしょうか。この場合は本番でテストをしなければならず、当然、稼働してからは十分なテストを行うことができません。このためテストが十分にできず、さらにデグレーションも発生しやすいという悪循環が生まれてしまいます。

テストデバイスが用意できない

弊社ではWebサイトを構築するにあたり、あらかじめ対応OSやブラウザのバージョンなどを定義します。ですが、全てのデバイス、OS、ブラウザのバージョンのテストを行うことはどうしても現実的ではありません。このため代表的なデバイスを用いてテストを行うのですが、やはり定義に入っていないデバイスもテストの必要性が出てきたり、そのバリエーションの多さからテスト工数がどうしてもかさみます。

テストの期待値を定義できない

Webサイト制作は「正常に表示されること」といった曖昧な結果がテストに用いられたりするのですが、「正確に表示されている、って何をもって正解なの？」と定義や粒度に迷うことが多いです。特にアニメーションのテストについては、感覚的な判断に左右され、こだわるあまりにテストが終わらなかったり、逆に必要な部分を見逃してしまったりします。

この辺が冒頭で「Webサイトはアートなんじゃないか」と思った所以です。
修飾のためのアニメーションのテストを緻密に定義するには、要件定義段階で絵コンテなどを作成しておく必要があるのではと思うのですが、もうそこまで行くと全く現実的ではありません。実際はデザイナーとフロントエンドが目で見て判断するしかなくなっています。

現代のWebサイト制作のテストは困難だが希望はある

問題を大別すると、Webサイト制作を困難たらしめているものは、「コスト」と「アート性」に帰結するのではないかと気がつきました。

Webサイトがさらにインタラクティブになったことにより開発コストが増えたものの、テストのコストは据え置きになっている気がします。また、芸術性が大幅に表現できるようになった弊害としてシステム的なチェックができなくなってしまった、そのことに慣れていないのだと推察します。

まずコストについては、テストには開発したものに相応なコストがかかると再認識したいところです。僕はWebサイト制作を業務で行うようになったのは割合最近のことなのですが、もしかすると、数年前と比べてコード量やロジックも増えているのではないでしょうか？

これだけコンテンツ設計をし、UX/UIを設計し、ユーザーの動きによってインタラクティブに動作するサイトを作れるようになりましたが、テストの手法や期間は足りているのでしょうか？　機能性が少なく、作成コストに見合わないと考えているのは錯覚で、単体テストや自動化なども、もしかしたら実施した方が全体のコストを押し下げられるかもしれません。思えば、Webサービスのテスト手法はどんどん先鋭化されていますし、Webサイト制作のテストも同様にトライ＆エラーをすべきです。

ただ、アート性については、最後の最後でアレなんですが「本質的な改善はない」と感じました。ここにもトライ＆エラーは必要ですが、諦めて適切な人員を投入し、許される限りクリエイティブに没頭できるよう、スケジュールを前のめりで確保するのがクリエイター集団にとって正しいアプローチである気がします。やはり「アートのテストって無理じゃね？」ということになりますが、同時にこのアート性こそが時間をかけるべき弊社の強みの一つではないか、と感じます。ほかのWebサイト制作会社はどのようなアプローチを採っているのか気になるところです。

弊社も今年で12期目、最新のVモデルと同い年くらいWebサイト制作を行ってきたことになります。LIGでの「いつものテスト」はその歴史の中で、失敗を避けられそうなこと、コストとのバランスが保てそうなことを実施し、残ってきたものなのでしょう。これはこれで大事なナレッジの一つではありますが、エンジニアとして脱皮は常に続けなければなぁと思いました。

とは言え、しばらく手動と目視でのテストは続くでしょうし、コストとの兼ね合いから諦めざるを得ないテストもあるのでしょうね。それでは、アサシンでした。

LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。

Webサイト制作の実績・料金を見る