小規模なWebシステム開発案件でしっかりと総合試験してみました

小規模なWebシステム開発案件でしっかりと総合試験してみました

総合テストとは、システム開発におけるプログラムの検証作業の中でも、構築したシステムが全体として予定通りの機能を満たしているかどうかを確認するテストのことである。開発者側の最終テストのことである。
総合テストは、個々の機能や仕組みを総合した全体像としてのシステムを対象として、設計のとおりにプログラミングされているか、機能間の連携は取れているか、機能や性能は仕様書の通りになっているか、といったことを検証する。システムアドミニストレータ(システム開発の管理責任者)を参加させ、実際の使用環境に近い形で動作させる、開発の現場における最終検査である。
総合テストとは – Weblio辞書

こんにちは、らいかです。とある案件で設計工程くらいから制作進行をしていた時に「総合試験せずに納品するの?やべぇ」っていう素朴な疑問から、プロジェクトを巻き込んで品質担保のために総合試験をしっかりと実施してみました。
小規模Webシステム開発の現場で十分機能したので、納品後にバグが見つかって「ギャー!」となるくらいなら開発期間中に総合試験初めてみませんか?すごく長いですが、そんなエントリです。

総合テスト、総合試験と書くとハードな印象を持ってしまう方が多いんじゃないでしょうか?わたしは過去に何度も総合試験工程への参画経験があるため、特にハードな印象を持ってしまいます。
そんな印象が原因しているのか純粋に工数が足りないのか、Web業界全体としてWebシステム開発において総合試験を工程として意識して、実践しているプロジェクトは少ないように思います。
元SI業界出身の身として、ある程度のロジックをコーディングしたからには品質担保のためにしっかりと試験を行うべきという考えがあるので、フロントエンドエンジニア・バックエンドエンジニアが自分で確認をするだけで「良し」とする文化に疑問を感じていました。

そんな品質に対する疑問を頂いたまま納品するのは会社としては良いとしても、個人的に納得がいかないので、Webシステム開発の現場でしっかりと調整をした上で総合試験を実施し、概ね良い結果を残せました。

外部設計書がない現場で総合試験をするには?

小規模Webシステム開発の現場では「外部設計書」なるものを作成しないところが多いんじゃないでしょうか?わたしの会社では作りません。たとえ作ったとしても細かい変更が多いので誰もメンテナンスしなくなり陳腐化します。
多くのWeb制作を行っている会社は同じような理由で外部設計書を作りません。

しかし、外部設計書がなければ総合試験を行うための試験項目を抽出できないので、総合試験が始められません。

ITパスポートや基本情報技術者の勉強をしたことがある人はご存知だとは思いますが、システム開発には「V字モデル」というものがあります。

小規模なWebシステム開発案件でしっかりと総合試験してみました

システム開発の工程をコーディング工程を折り目としてV字に配置することで、設計書に対する試験工程と試験工程の試験項目抽出のためのインプットを可視化する有名なモデルです。

総合試験では、外部設計工程の成果物である「外部設計書」をインプットとして試験項目を網羅的に抽出します。言い換えれば「外部設計書に書いてあることを試験するのが総合試験」です。
しかし、今回わたしがアサインされた案件のように外部設計書がないプロジェクトの場合、どうやって試験ってすればいいんでしょうか?

工程が制作段階まで入っているのに外部設計書を作るなんて、どこかの炎上案件じゃあるまいし…。そんなことせず、システムの入力情報を全て可視化して入力情報から総合試験項目を抽出することにしました。システムの入力情報は特に制約を設けずユーザーが入力する項目から、マスター情報として登録するCSVファイルなどをターゲットにします。
この際、入力情報に例外を設けてしまうと例外の拡大解釈や矛盾が生じてしまうので入力情報については全て対象とします。

入力情報を全て総合試験項目の抽出材料とすることで総合試験を実施する訳ですが、総合試験としての最低限の体裁を保つために7つの注意点があります。
逆に言えばこの7つの注意点を満たせば、非常に質の良い総合試験が出来るのです。

試験範囲が明確であること

外部設計書があれば、「外部設計書に書かれてあること全て」を試験対象にするだけで済みますが、外部設計書も期間も人員も無いプロジェクトでは、いかに余分な試験を行わないかに注意する必要があったので、「入力情報全て」という全員がブレることなく共通認識をもてる要素を試験対象とします。

試験範囲が明確で共通認識できているのであれば、考え方の違いから「これは試験する?しない?」という無駄な議論を生み出す可能性が無くなります。小規模開発では「出来る限り無駄なことはしない」を徹底することが非常に重要になると今回強く感じました。

試験範囲の明確化に関する経験則

試験範囲は「試験データ」に関するものだけではありません。総合試験には様々な試験が包括されています。「運用試験」や「性能試験」、「長期安定化試験」など試験スコープはシステムだけでなくハードウェアや運用手順などシステムの外にも及びます。試験範囲を明確に区切ることはこういったシステムの外にも目を向けて「しなくてもいい試験は何か」を洗い出す必要があります。
これらの試験は相当工数に跳ねる部分であるため、見積もり段階から検討しておきクライアントと事前に実施するかしないかの認識合わせをしておくべきです。後から実施するにはあまりにもリスクが大きい。

試験内容が明確であること

これもわたしの経験からきているのですが、内容が分かりにくい総合試験には「前提条件がゴチャゴチャ」という共通点があると思っています。当然試験を行うには前提条件が複雑に絡み合うものも存在していますが、実はそれって作り(プログラム)を知っている人だからゴチャゴチャした前提条件を書いてしまうだけなんですよね。
「xxxというインプットに対して画面上にzzzと表示される」ことが本当に確認したいもので、ゴチャゴチャした前提条件は試験を行う上では全く必要ありません。(バグ切り分けやバグ対応を行う場合は重要です)

試験項目表の書き方の話になりますが、試験内容が明確であることの条件としてインプットとアウトプット以外の条件に関する言葉を一切省略する。ことで試験内容が簡潔に明確となり、項目表作成にかける時間や試験担当者の試験内容の理解にかかる時間を大幅に削減することに貢献できます。

試験結果良好の条件が明確であること

「何を満たせば試験結果良好なのか」が一目で分かる様に書くべきです。
一番効果を発揮するのが否定形を使わない条件記述を徹底することです。

良い例:生年月日に入力された内容から計算して未成年であれば保護者同意欄が表示されること

悪い例:生年月日に入力された内容から計算して未成年でないときのみ保護者同意欄が表示されないこと

なんとなく言いたいことが伝われば嬉しいのですが、否定形(not)を使うと日本語はややこしくなってしまいます。普段生活する中でもややこしいと感じる言葉を試験結果良好の条件記述に使った日には、試験効率はがっくりと下がります。そうならないために条件の記述は肯定形のみで統一します。
ちょっとした工夫ですが、非常に効果があります。「何を満たせば試験OKなの?」という疑問がほぼ発生しなくなります。

ブラックボックステストであること

少し触れましたが、Webサイトの作り(プログラム)部分を知っていると試験内容がややこしくなったり、本来試験すべきではないところまで試験を行い工数だけかけてしまう。そんなことが起きます。

別のプロジェクトからアサインすることが理想ですが、最低限意識したいのが、試験項目の作成担当者と試験実施担当者は別人であることです。
さらに、試験担当者は出来る限りそのプロジェクトに対する知識や理解度が低い人の方がユーザー目線で思いもかけないUIの改善ポイントを指摘してくれる可能性があるのでブラックボックステストになるように意識します。

試験の網羅性担保が明確であること

「これで仕様の漏れない?全部?」という問いに自信をもって回答できます。外部設計書がない状態で「全て」を証明するものは入力情報しかありません。その入力情報を全て網羅したのであれば「全て」と言わずして何と言うか。くらいに説得力があります。

総合試験完了条件が明確であること

「何をもって試験完了とするの?」この問いのアンサーとなります。入力情報全てから抽出した試験項目全ての試験が完了し、全項目の試験結果がOKとなった時です。
網羅性を担保していると、案件を管理しているマネージャの精神的にも優しい。

ゴールをしっかりと決める。という点においてはどんな作業にも共通していえることですね。

短期間で完遂できること

小規模開発では最も重要なことですが、短期間で完遂できることが重要です。どれだけ精度の高い試験が出来るといっても納期をオーバーしては意味が無いので、短期間で実施するための工夫や施策をどんどん取り入れて実践する気持ちが重要です。特にわたしの場合は期間が短かったので上記で挙げた工夫ポイントを駆使して、試験計画から試験完了までわずか4日で完遂することができました。

総合試験の実績

  • 納品から1ヶ月。目立ったトラブルは一切無く非常に高い品質でWeb制作が出来た
  • 心理的にも「バグ発生しないかな?」という不安を払拭できた。
  • ブラックボックスだからこそ、UIの改善フィードバックを得れた
  • 完了条件が明確なのでメンバーのモチベーションが下がることなく試験を完遂できた

改善点

次回以降に同じ様なことを考える時に、事前に検討・対策したいなと思うこと

  • 試験項目表の作成には時間的コストが結構かかる。見積もりへの計上や作業分担の検討などを事前にしておく必要があります
  • 試験項目レビューが欲しい

総合試験を計画・実施してみたまとめ

らいか
「小規模だから」「Webシステム開発だから」という変な理由で範囲や項目をしっかりと定めた総合試験を行わないことは品質低下の原因になる。社内のリソースをフル活用して第三者に総合試験を実施してもらうことを前提に、さらに高い品質に到達できる仕事ができれば、社内だけじゃなく社外からの評価も必ず上がるはず。
小規模なWebシステム開発案件でしっかりと総合試験してみました

ABOUTこの記事をかいた人

工業高等専門学校を卒業後、NTTグループのSI企業に就職。数々の炎上案件を鎮火するために日本各地を5年間転々とする。2015年に一般ユーザ向けのWebシステム開発案件のチームリーダとして業務に従事し、改めて"Webのものづくりの楽しさ"に気付きWeb制作会社に転職。Web制作やアクセス解析を使ったオウンドメディアの運用改善などを行っていく中で、もっとユーザー目線でWebをただ制作するだけではなく企画や運用まで幅広い領域で仕事がしたいと感じるようになり、Webディレクターのキャリアを目指す。日本中のビジネスホテルに詳しく、犬や猫よりも鳥派。