2019年9月27日 / 最終更新日時 : 2020年9月3日 user 事例・ソリューション

テスト可能なHTMLの設計

「うちの HTML はあまりテスト可能な状態ではない」と企業や組織が結論付けることがあります。大抵の場合、これが意味するところは以下の意見の集合であると言えます。

初歩的なエラーが、テストプロセスをすり抜けたことがある
すべてのスクリーンショットにOK を出した後に、シニアマネージャーが、自分の作業端末（Blackberry、iPad、Internet Explorer 9）上での見た目に文句を言ってきた
HTML は本当のプログラミング言語ではないから、テストできないんでしょう?
Webブラウザ内の画像が常に動いている

これらの状況に対する最良の対応は「HTML (HyperText Markup Language) はテストできない」と諦めて結論付けないことです。

今回は、HTML を上手くコントロールするために、開発チームで実施できる 6 個のアクションについて説明します。

姿勢の問題

HTML のテストの可能性における「最もソフトな」部分は、「コードとツール」よりも「姿勢」に関係します。「姿勢」とは、HTMLのテストに対して責任をもって取り組むことであり、HTMLのテストを継続的に実施するための熱意と、目標の明確化にあります。

以下のような、簡単なHTMLを例に考えてみましょう。

<html>
<body>
<h1>An Example</h1>
<p>This is only a test.</p>
</body>
</html>

このようなケースでは、「テスト」が何を意味するかについての合意が非常に重要です。

一方では、成功するテストは「ある特定のブラウザーで表示される画面のすべての画像が、設計文書に定義されたプロセスに一致していること」が要求されます。

しかし、もう一方では、成功するテストは「人が画面を見て“読める”と認めること」というくらい寛容な場合もあります。

HTMLのテストにまつわる混乱の大部分は、ターゲット/状況/条件に適したツールや技術を正しく使用していないことで発生します。成功する組織は、プロジェクトの目標について明確でなければなりません。

ただし、目標を明確にすることは、それだけでは十分ではありません。 HTMLのテストはとても難しいものであり、高い確率で最初の数回は問題が発生します。明確な目標を作り、その目標が視野に入り続けるようにしましょう。そして、テストが失敗する道筋を観察して修正しましょう。すぐに完璧を求めてはいけませんが、徐々に完璧に近づくことを期待しましょう。

ときには徐々に目標に近づくのがベストです。組織によっては、完全に自動化された「継続的テスト」システムが適切かもしれません。同時に、理想的な自動化が実現されるまですべてのテストを延期するよりも、自動と手動が混在した継続的テストシステムを早期に試すほうが生産的でしょう。

さまざまな技法

実務的な「姿勢」を整えたら、次は何でしょう? 組織は具体的にどのようなテストを最初に作成すべきでしょうか ?

顧客に関係するビジネス上の経験に目を向けてみましょう。顧客が発見したHTMLの欠陥はどのようなものでしたか？日本語のコンテンツ表示がおかしかったことはありますか？それは HTML 以外のエラーかもしれないので、最良なエラーの修正方法について開発者に相談しましょう。ブラウザーによって表示のされ方が異なりますか？その手の問題は静的解析で簡単に修正できるかもしれません。

HTML の「静的解析」とは何でしょう。そして「静的解析」はどのようにブラウザーの問題に対応するのでしょうか。

簡単に言うと、静的解析は HTML インスタンスの構文的な正しさにフォーカスします。ブラウザーは、HTML の小さな間違いに対して寛容なことで悪い意味で有名です。

たとえば以下のコードでは、多くの場合、ブラウザーは 1 番目のブロックを、本来の意図であろう 2 番目として解釈します。

作成された HTML

<p>First paragraph
<p>Second paragraph</li>

ブラウザーによる解釈

<p>First paragraph</p>
<p>Second paragraph</p>

しかし、ときにはこれらの欠点が積もり積もってブラウザーを混乱させることもあります。そして、その混乱はブラウザーに依存します。たくさんの小さな矛盾を簡単に解消する方法のひとつは、HTMLをスキャンして構文上の正しさをチェックすることです。

無料または低価格のスキャンツールが存在します。そのひとつは、World Wide Web の規格に対して責任を持つ組織 の W3C Markup Validation Service です。いくつか試して、組織のワークフローに最適なものを探しましょう。標準に適合するよう、すべての HTML をきれいにし、その後、HTML にほとんど問題が残っていないことを確認しましょう。

完璧な画像

HTML の構文の検証は比較的「軽量」です。コストが低く、多くのワークフローでそのまま適用できます。その対極の HTML テストは、表示される Web ページを参照用の「スナップショット」と比較する手法です。この手法は、「脆弱性・コスト・困難」の 3 点をさまざまな割合で結びつける傾向があります。たとえば、以下の 1 番目がテスト基準であると仮定します。

テスト基準

This is only a test.

バリエーション 1

This is only a test.

バリエーション 2

This is only a test.

文字のフォントや色のバリエーションは一致していますか ?

有用な回答は、前段の「姿勢の問題」で説明した「目標の明確化」です。上記のバリエーションの全組み合わせに対してテストを作成することは、技術的には可能です。しかし、フォントと色の詳細を HTML テストプログラムに組み込む価値があるかどうかを判断するのは、ビジネス上の決定であり、技術的な決定ではありません。

画像が少し異なることにユーザーは気付くでしょうか ?

組織のブランドとインパクトにとって重要なのは、ビジュアルなデザインですか ?

内容ですか ?

あるいはその両方ですか ?

最小化

ソフトウェアの品質を改善する上で最も確実な方法のひとつは、行数と複雑性を削減することです。HTML をシンプルにするための最も良い方法として、スコープを狭める方法があります。

できる限り、HTML ではなく CSS (カスケーディングスタイルシート) を使ってスタイルを指定します。CSS を使用すると、HTML がシンプルになるため、テストも容易になります。
同様に、JavaScript を .js ファイルに分けます。スタイル指定を CSS に任せる場合と同じように、 JavaScript を別ファイルに分けると、保守が容易になります。
組織の全般的なソフトウェア技術に適した、あらゆるテンプレート化や前処理の機能を利用して、さらに HTML の行数と複雑性を削減します。

こういった手法を採用することは、CSS とJavaScript をテストするという負荷が増すことを意味しますが、良い面として、たとえばテストツールを利用できることが挙げられます。

隠れたフック

前段の「最小化」では、単純な HTML はテストツールを利用するうえで有利であると説明しました。ただし、この一般化には大きな例外がひとつ存在します。すなわち、HTML ソースの個々のタグに ID を用意すると、多くの場合に有益だということです。前述の「姿勢の問題」セクションの HTML と以下の HTML を比較してみてください。

<html>
<body>
<h1>An Example</h1>
<p id = ‘p1’>This is only a test.</p>
</body>
</html>

どちらの HTML も、従来のブラウザーではまったく同じように表示されます。
上記の HTML は、明らかに「姿勢の問題」の HTML よりも複雑です。なぜなら、上記の HTMLにはid 属性が追加されています。
上記の HTML の場合、多くのテストツールが ID “p1” を使ってコンテンツを容易に参照できます。

ID は一部のテストツールでは非常に有用であるため、タグに自動的に ID を付けることで大きな効果を得ることができます。たとえば、一般的にスクリプトツールは、エンドユーザーの振る舞いをシミュレートする一連のアクションの一部として「ID が submit1 のボタンを押す」あるいは「ID が pay-one-thousand のラジオボタンを選択する」といったアクションを表現できます。

ID の追加によって得られるメリットは、使用するテストツールによって異なりますが、一般的にシンプルな HTML が望ましいとされる中、ID の使用は重要な例外であるため、前もって開発チームで話し合う必要があります。

「プロジェクトの初期・開始時に戦略的に ID を組み込む」方が、「プロジェクトの最終段階になってやっとテスト部門まで到達してから“外科手術”を実施しなければならない」状況よりもずっと良いといえます。

ツールを組み合わせる

最後に、HTML テストではツールとワークフローを組み合わせて使う必要があるかもしれないことを意識してください。開発チームは、自動検証用の静的アナライザーに頼ると共に、たとえば IE Tab などの助けを借りた、人間によるきめ細やかな検査に頼ることもあります。自動と手動の 2 種類のテストは互いを補完し、一般的に違う種類の HTML エラーを特定します。その一方で、QA 部門は Ranorex Studio のようなUIテストツールを使ってユーザーインターフェイス全体を検証することができます。

個々の HTML テストについても複数のツールの連携が必要になることがあります。多くの組織は標準的な HTML を記述しません。代わりに、そのソースは (たとえ front_page.html のようなファイル名であっても) 実際には HTML テンプレートを使用しています。Flask、Rails、Velocity などを含め、一般的な Web 構築テクノロジーにはこの方法が採用されています。基本的な静的解析ツールは、標準的なHTMLを解析することを期待されており、HTML テンプレートに関しては常にノイズの多い指摘をレポートします。このようなケースでは、短いパイプラインを作成することで最適な結果が得られます。すなわち、はじめにHTMLテンプレートを標準的なHTMLにレンダリングし、次にこのHTMLを静的アナライザーに渡して検証します。

まとめ

HTML は単純な言語として定評があり、そのため、「テストに値しない」「テストできない」と判断されることが多々あります。しかし、HTML は上手くいかないケースも多いことから、どの組織も固有の HTML の使用に対するビジネスの実例を分析するべきであり、HTML ソースの少なくともある一面をテストする明示的な計画を作成するべきです。

HTMLの利用をHTMLが得意な分野に制限することでHTMLをシンプルにします。しかし、必要な場合にはIDでタグ付けをしましょう。設計が良いテストは、信頼できる結果を皆さんや顧客に提供するのに役立つだけでなく、ソースの一貫性を保ちます。その結果、アプリケーションまたはコンテンツの生涯にわたった保守が容易になります。

作者について:

Cameron Laird は、受賞歴のあるソフトウェア開発者であり著作者です。業界のサポート団体や標準化団体に参加しており、Python Software Foundationの投票メンバーでもあります。長年テキサス湾岸に居を構え、お気に入りのアプリケーションは農業自動化向けのアプリケーションです。

（この記事は、開発元 Ranorex 社 Blog 「Design HTML to be Testable」2018年8月23日の翻訳記事です。）