こんにちは、キノトロープアカデミーです。

「キノトロープアカデミー」は、Web業界のトップランナーである株式会社キノトロープの社員が講師を務めるオンラインアカデミーです。リモートワーク時代に不可欠な「個のスキル」を高め、職人のような「匠」を目指す人を増やしたい。そんな願いを込め、基礎から経営判断、業務フローまで、一生モノのナレッジを惜しみなく公開していきます。

＜中級編 第21回＞
【Webエンジニア向け】企業価値を高めるWebサイト開発手法 の第６回をお届けいたします。

担当は高橋です。

本記事では、Webエンジニアに向けて、プロジェクトの成果や目標とのギャップをなくすための実践的な「動作テスト手法」を解説します。

またシステム構築で重要となる機能テスト、外部連携テスト、受入テストの3つを取り上げ、それぞれのフェーズで陥りがちな不具合の原因や、開発環境と本番環境の相違に起因する根本的な問題を解説します。

これらの課題を克服するために、テストコードの段階的な導入や相互参照によるテストケースの網羅、さらには要件定義の背景に基づいた「サービス・成果達成チェック」の実施など、少しずつ確実に品質を改善しWebサイトの企業価値を高めるための具体的な施策とアウトプットを紹介している内容となっています。

”企業価値を高めるWebサイト開発手法”をテーマに、
今日お伝えしたいことは3つあります。

まずは機能テストについてです。ここでいう機能テストとは、「システム内のある機能について、要件を満たした動作が実現できているか」、「想定外の操作が行われた場合でも、適切にキャッチして安全にエラー処理ができているか」のテストを指します。

「Webサイト公開後、ある機能の改修を行ったら別の機能に不具合が発生した」という経験はありませんでしょうか。

システム開発の現場でよく聞く話ですが、このようなことが起こる原因は非常に明確で、「テストパターンの洗い出しが不足している」ということです。

改修対象の機能のテストだけを実施して公開してしまっていて、共通のプログラムを利用している他の機能についての影響が考慮されておらず、従ってテストもされていない状況です。

それは「プログラムの影響範囲を網羅した機能テストができていない」というのが根本的な問題です。

「前任者から何も引き継ぎがなかったので影響範囲がわからない」、「負の遺産を抱えていてテストに時間を割くことができない」というような状況もよくあることです。

ですが、それらの事情はすべてクライアントやWebサイトを利用するお客様にはなんの関係もないことです。

Webエンジニアの皆さん、愚痴を言っていても状況は何もよくなりませんので、気持ちを切り替えて少しずつでもよいので改善していきましょう。

その改善のための具体的な手法とは、「テストコードを書く」ことと「影響範囲を網羅したテストパターンを作成する」ことです。

まずは、プログラムひとつひとつの入出力パターンを網羅したテストコードを書き、プログラム自体の自動テストをパスさせましょう。

そうはいっても、もともとテストコードが存在しないシステムの場合、全機能のテストコードを書くためのまとまった予算や時間が取れないことがほとんどです。

なので、ある機能の改修案件の見積を依頼されたタイミングで、「その機能のプログラムのみのテストコーディング工数」と「今回の機能改修の影響範囲がどの範囲なのかの調査工数」を「テスト工数」として見積内に含めるのです。

こうすれば、改修案件予算内で、少しずつ自動テスト可能な範囲を増やしていくことができ、影響範囲も少しずつ可視化していくことができます。

もちろん、もともとの機能改修自体もテストコードがなかったときよりもより堅牢で高品質なものとなります。

影響範囲が少しずつ明確になってきたら、テストケースの項目に落とし込みましょう。

機能ごとのテストケースを網羅したテストシートはどのプロジェクトでも作成しているかと思いますので、機能ごとのテストシート間で、影響が出る可能性がある他の機能のテストケースへの参照を行います。

文章だけではわかりづらいと思いますので、検索フォームの改修を例に挙げてご説明します。

検索フォーム機能の概要は以下の通りです。

改修内容は以下の通りです。

ここで想定される機能テストの失敗例として、次のような状況が挙げられます。

新規の検索項目入力欄を追加しようとして、検索機能自体のテストシートに新規項目分のテストケースを追加し、検索機能自体のテストシートだけを実施した状態で公開してしまうケースです。

この場合、新規項目のみ検索条件の保持を実装できていないという不具合が発生してしまいます。

そのような失敗を防ぐために必要な機能テストのベストプラクティスが以下になります。

これらを実施することで、新規項目に必要な機能の実装とテストが確実に実現できます。

いかがでしょうか。大規模なシステムではとても無理、と思われる方も多いかと思いますが、すべてを一度に完璧にしようとするといつまでたっても着手できません。大事なのは「少しずつ、けれど確実に」改善していく日々の心がけです。

次に、外部連携テストについてです。ここでいう外部連携テストとは、「他のシステムとのデータ受け渡しが発生する機能について、要件を満たした動作が実現できているか」、そして「想定外の操作が行われた場合でも、適切にキャッチして安全にエラー処理ができているか」のテストを指します。

「外部連携テストが完了しているのに、本番稼働時に不具合が発生した」という経験はないでしょうか。

この原因も、機能テストの場合と同様「テストパターンの洗い出しが不足している」ことが原因ですが、外部連携テストの場合に多いのはテストケースの見落としではなく、以下のようなケースです。

「本番環境で連携される画像サイズが規定通りでなく、表示崩れが発生した」、「本番環境だけで稼働しているバッチ処理の影響を受け、処理速度が低下した」等、テスト環境のデータやインフラが本番環境と異なることに起因する不具合です。

それは「連携先システムの本番環境またはそれに近いデータやインフラを使ったテストができていない」というが根本的な問題です。

「規定外の画像が送られてくるなんて想定していなかった」あるいは「裏でバッチ処理が実行されているなんて知らされていなかった」といった声が聞こえてきそうです。

しかし、いくら自分に責任はないと主張したところで起きてしまった状況は何一つ改善されません。厳しいようですが、事前に本番環境のデータやインフラの状況を自ら確認していれば、十分に回避できたトラブルかもしれないのです。

外部連携テスト改善のための具体的な手法についてお話しします。ポイントは「本番環境に近いデータ環境で外部連携テストができるように進行する」ことと「本番環境に近いインフラ環境で外部連携テストができるように進行する」ことです。

システムのテスト環境は通常、本番環境よりもサーバスペックが低いことがほとんどです。したがって連携先システムに「本番環境のデータをテスト環境に全部入れてください」とお願いしても、スペック上不可能な場合も多々あります。

そのような場合は、エンティティ毎にサンプルを抜き出してテスト環境に反映していただくよう依頼してください。ダミーのテキストや画像だけでは必ず本番反映後に想定外の不具合が発生します。そのような事態を避けるために、強い意志をもって調整に臨んでください。

インフラに関しても、スペックの相違により、完全に同じ稼働環境にはできないことが多いです。

その場合は、連携先システム側にはできる限りのことをしていただき、あとは、なるべく本番環境と同じ性能条件となるよう、こちらのシステム側で可能な限り調整を行います。

性能テストであれば、本番環境とテスト環境のスペック差を考慮し、本番稼働時と同じ負荷量となるよう計算して調整します。

上記２点を実施したうえで、アウトプットとして外部連携テストのデータ環境、インフラ環境についての定義を「外部連携テスト条件定義書」としてまとめましょう。

最後に、受入テストについてです 。ここでいう受入テストとは「システムの納品時に、発注者の本来の目的や意図通りに稼働するかどうか」のテストを指します。

機能テスト、外部連携テストは、システム構築を行っている会社のテスト担当エンジニアが実施します。

これに対して、受入テストはシステムの発注を行ったクライアント企業の担当者が実施し、受入テストをパスすることがシステム検収の条件となることが多いです。

「受入テスト段階になって、要件を満たしていないとクライアントから指摘された…」 という経験はないでしょうか。

機能テストもすべてパスしている、本番環境に近い状況での外部連携テストも完了している、要件通りに動作しているはずなのに、いったいなぜこのようなことが起きるのでしょうか。

受入テストの定義をもう一度見直してみましょう。受入テストでチェックされるのは、「発注者の本来の目的や意図通りに稼働するかどうか」です。

あるWebサイトリニューアル案件の要件定義書を例に挙げます。要件定義書が次のような目次で構成されているとします。

１．リニューアルの背景
２．リニューアルの成果・目標
３．機能要件
４．非機能要件
５．スケジュール

いかがでしょうか。もしあなたが、1や2にまったく興味がわかなかったり、いきなり3の「機能要件」から読み始めたりしているとしたら、まさにそれこそがトラブルを引き起こす根本的な原因なのです。

エンジニアは、0か1かではない定性的な内容を軽視してしまいがちです。

しかし、プロジェクトの背景を理解することは「なぜこのプロジェクトを実施するのか」を理解することであり、プロジェクトの成果・目標を把握することは「このプロジェクトで達成すべきこと」を把握することです。

これらの理解や把握なしに、クライアントが最も求めている要件、Webサイトを利用するお客様に最も提供すべきサービスを達成することはできません。

それは「サービス・成果を想定したテストができていない」というのが根本的な問題です。

機能テスト、外部連携テストが完了した段階では、まだ完全にテストが行われていないことを認識してください。

企業価値を高めるWebシステムとして機能するためには、必要なサービスを提供できているかどうか、なしえるべき成果を達成できているかどうかのテストが必要です。

受入テスト段階で失敗しないためには、「サービス・成果達成チェックを実施する」ことが重要です。

要件定義で定めたプロジェクトの成果・目標をもとに、「サービス・成果達成チェックシート」を作成します。機能テスト、外部連携テストが完了した段階で、受入テスト前に自社内で「サービス・成果達成チェック」を実施しましょう。

案件によっては、これがそのままクライアントの「受入テストシート」として利用できる可能性もあります。

最後までご覧いただきありがとうございました。

の３点についての内容でした。