関連記事
【開発実況シリーズ】Web日報登録システムを作る #16 リファクタリング
2021.03.21
2022.01.31
【開発実況シリーズ】Web日報登録システムを作る #17 検証フェーズ編
この記事の動画版はこちら（画像クリックでYoutubeに飛びます）
チャンネル登録お願いします！
今回は、開発実況シリーズ「Web日報登録システム」の第17回ということで、前回の続きを進めていきたいと思います。
前回は・・
前回までで、①の企画フェーズ、②の設計フェーズ、そして、③の開発フェーズまでが完了しました。
現段階で、アプリとしては動くものが出来上がっています。
しかし、製品として世に出すためには忘れてはならない大事な工程が残っています。
それが、④の検証フェーズです。
作成したアプリを色々な角度からテストすることでバグを洗い出し、リリース後に不具合が発生しないようにしたり、アプリがユーザーにとって使いやすいものになっているかどうか？ということをユーザー目線でテストしていくことが目的です。
この工程は「Quality Assurance（品質保証）」を略して「QA」とも呼ばれ、開発会社によっては、QA専門のエンジニアや部門が設置されていたり、専門の会社に外部委託するようなケースもあります。
個人開発では疎かになってしまいがちな工程ですが、アプリの最終的な品質に大きく関わってくる部分なのでしっかり実施していくようにしましょう。
また、クライアントにプログラムを納品するような場合は、実施したテストの項目が分かるような「検証報告書」を一緒に提出すると良いですね。
それでは今回は、最終工程の「検証フェーズ」を進めていきましょう！
検証フェーズの流れ
検証フェーズはこのような流れで進めていきます。
まずは、テスト計画として「どんなテストを実施するのか？」ということを決めていきます。
設計フェーズで決めた各機能の仕様や、サポートするブラウザの種類を考慮しながら、テストすべき項目を洗い出していきます。
洗い出したテスト項目は「検証仕様書」という形でまとめます。
検証仕様書が作成出来たら、テスト項目に沿って実際にテストを実施していきます。
テストした結果、問題が無ければ「OK」、問題があれば「NG」と検証仕様書に書き込んでいき、問題が見つかった場合は、具体的な現象をバグ管理システムに登録します。
そして、テストが一通り終わったら、洗い出されたバグを修正していきます。
工数やスケジュールとの兼ね合いで、どのバグを優先的に修正すべきか？ということを検討しながら行っていきます。
あとは、品質がリリース可能レベルになるまで、②と③を繰り返していく。
といった流れですね。
では、上から順番に進めていきましょう。
テスト計画
テスト計画の作成方法は、人によって色々なやり方があると思いますが、僕の場合、まずは設計書を見ながら基本的な機能要件を書き出していきます。
例えば、社員側の機能なら
【基本機能テスト】
・社員IDとパスワードでログインが出来ること
・業務時間（出勤／退勤／休憩）が登録出来ること
・出勤／退勤時間の打刻ボタンをクリックすると現在の時刻が自動入力されること
・業務内容が自由入力で登録出来ること
・月別の一覧表示が出来ること
・登録した業務内容を後から変更出来ること
こんな感じで「このように動くべき」という機能要件をテスト項目として書き出していきます。
基本機能を書き出したら、次は実際の画面を見ながら、画面周りの細かい要件も書き出していきます。
例えば、
【画面表示テスト】
・日報登録モーダルの初期値は、出勤／退勤／業務内容は「空欄」、休憩は「01:00」になっていること
・年月選択プルダウンは当月を含めて過去12ヵ月分が設定されていること
・月別リストの日付／曜日が正しく表示されること
・時間は「HH:mm」で表示されること
・業務内容に20文字以上入力された場合は省略表示されること
・faviconが表示されていること・DevToolのコンソールにエラー等が表示されていないこと
また、システム的な要件だけでなく、出来るだけユーザー目線に立って
・シンプルに使いやすいアプリになっているかどうか？
・ユーザーがやりたいことが迷わず行える操作性になっているかどうか？
・操作している中でストレスを感じるような部分はないか？
といった点もチェックし、気になる部分があればテスト項目に加えていきます。
さらに、どのWebアプリにも毎回行うような「共通のテスト項目」も追加します。
これは、講座の学習時に使用している検証仕様書のテンプレートですが
画面にレイアウト崩れがないかどうか？といった基本的な項目から、不正な文字を入力された場合のチェックなどが記載されています。
そして最後に、「考えられる異常な動作」も洗い出していきます。
例えば、
【異常操作テスト】
・間違ったパスワードを入力したら、ログイン出来ないこと
・ログインしていない状態でログイン後のURLに直接アクセスしたら、ログイン画面へ遷移されること
・業務時間に不正な形式を入力しても異常なデータが登録されないこと
・URLを改変して、存在しないパスを指定した場合にエラー画面が表示されること
・URLパラメーターを不正に改変した場合にエラー画面が表示されること
こんな感じで、検証仕様書の縦軸にテスト項目を洗い出したら、横軸にはテストするブラウザの種類を列挙していきます。
サポートするブラウザについては、アプリの利用形態や、利用するユーザー層、開発工数などを考慮して、最適なものを決めていきましょう。
これで、検証仕様書の作成は完了です。
テスト実施
次は、作成した検証仕様書に沿って実際にアプリをテストしていきます。
対象ブラウザごとに上から順番にチェックを行っていきます。
テスト作業は結構根気のいる作業ですが、画面表示周りや、JavaScriptを使用している箇所は
ブラウザによって挙動が異なる場合があるのでしっかりチェックしていきます。
このように、問題なければ「OK」
何か問題があれば「NG」と記載していきます。
NGが出た場合は、具体的な現象と再現手順をバグ管理システムに登録します。
バグ管理システムは、プロジェクトで決められているものがあればそれを使いますが、特に決まっていない場合は、GitHubのIssues機能が便利です。
バグのタイトルや詳細情報の登録、担当者のアサインやステータスの管理など、基本的なバグ管理が手軽に行える上、GitHubのリポジトリと連動しているため、「このバグを直すためにソースコードのどの部分を修正したか？」といった情報も確認することが出来ます。
バグ修正
全ブラウザでのテストが一通り終わったら、Issuesに登録されたバグを確認しながら、修正の優先順位を検討し、バグを修正していきます。
修正すべきバグが全てクローズされたら、再度テストを実施します。
これを、全てのテスト項目がOKになるまで繰り返します。
全てのテスト項目がOKになれば、検証フェーズはクリアとなり、いよいよリリースとなります。
完成したソースコードやドキュメント一式をクライアントに納品したり、本番サーバーを構築してローンチするといった形ですね。
もちろん、ここでは「初期バーション」が完成しただけですので、これから実際に運用されていく中で、不具合が発生したり、使い勝手の悪い部分を改善したり、さらに新しい機能を追加したりと、今後もバージョンアップを重ねていくことになりますね。
アプリの完成
ということで、これで今回のアプリの開発工程は全て完了です。
今回のシリーズでは、全くのゼロの状態から、Web開発のワークフローに沿って「Web日報登録システム」を作ってみましたが、いかがだったでしょうか？
現在Webアプリを作っている方や、これから自分でもWebアプリを作ってみたいと考えている方に向けて、Webアプリはこういう流れで作っていくんだ、というイメージが少しでも伝われば嬉しいなと思います。
実際の仕事案件ではないとしても、このように時間があるときに色々なアプリを作っておくことで、自分の開発実績やスキルアップにもつながりますし、実際に似たような仕事案件が合った場合にも、実績をアピールしながら、素早く提案することが出来ます。
今回作成したWeb日報登録システムをベースに、それぞれの企業にあったカスタマイズをして納品するといったシステム商品を作ることも出来ますね。
基本部分はすでに出来上がっているので、素早く、安価に対応することが出来ます。
皆さんも是非、自分の実績／資産となるアプリを作ってみてくださいね。
徳田 啓（トクタ ケイ）
Webプログラマー暦20年。自分で使うツールは、基本的に1人でゼロから自作。オールマイティなプログラミングの知識とスキルを学べる「フルスタックエンジニア マスター講座」を開講中。生徒さん1人1人に合わせてしっかりサポートしていきます！
プログラミングの実践的なノウハウを発信中！
ぜひフォローしておいてください。
ぜひフォローしておいてください。
