9.3 システムの形態/開発体制などと適したテスト手法
静的なWebサイトに比較すればシステムを扱う業務まで踏み込んだWeb構築の場合には、いずれにしてもより詳細なテストを行う必要がありますが、前節でもふれたように開発手法によってもテスト内容は異なってきますし、対象のシステムがどのようなシステムなのか、どのような実装方法によるものなのか、あるいはどのような開発体制でどのような能力の人間がテスト計画・テスト実施するのかによっても適したテスト方法が異なってきます。
a. SaaSやノーコードツールを用いたシステムの動作検証
前節までのテストに関しての考え方は、基本的に一般的なシステム開発/Web構築をイメージして記載した内容ですので、SaaSやノーコードツールなどを用いる場合は異なる面があります。単一のSaaSサービスやノーコードツールを用いてシステムを実現する場合には、単体テストや結合テストなどは不要ですし、総合テストのような動作検証は行うべきですが、SaaSやそのノーコードツールで保証されている機能についてはテストする必要はありませんので、自分たちが行った各種設定が適切なものだったかの動作確認を行えばよく、一般的なシステム開発よりは手軽な動作検証で十分です。
ただし、複数のSaaSを組み合わせてシステムを実現したり、SaaSの機能を補強するためにAPIやWebフォームなどをSaaSの外側に開発して連携して動作させるような場合には、ひとつのSaaS内の処理でそのSaaSの機能を利用している部分については手軽な動作検証でも問題ありませんが、複数のSaaSが連携する処理の部分や外部のAPIやWebフォームの動作検証についてはよりきちんと行うことが必要となります。
b. テストケースの作成
テストケースとは、テスト打鍵するケースを洗い出して、それぞれの操作手順およびその結果としての期待される結果と打鍵結果を記録できるEXCELなどで作成した一覧表ですが、テスト打鍵するケースとして漏れなく洗い出されているか確認を行うとともに、テスト打鍵結果を納品物として提出することができるように整理した形にしたものでもあります。
テストケースの作成は、当該システムの要件/仕様/設計がきちんと把握できている人でないと漏れのないきちんとしたものを作成するのは難しいです。どれだけの画面が存在するかということだけでなく、システム内容の状態としてどのような状態を取り得て、その状態に従ってシステムの動作がどのように変化するのか把握した上で、それぞれの状態にしてシステムの動作を確認するケースを作成する必要がありますので、システムがどのような仕組みで要件を実現するように作られるか、その仕様/設計まで把握できている必要があります。
要件定義/システム設計を行った人間がテストケースの作成もできるのであれば問題ありませんが、役割分担を行う必要がある場合は、テストケースを作成する人間がケース作成までに、十分にシステムの要件/仕様/設計について把握できるように、要件定義や設計段階からプロジェクトの一員として加わっている必要があります。
c. フリーにテスト打鍵することの意味
テストケースをきちんと漏れなくケースを作成することができるのであれば、そのほかにフリーにテスト打鍵を行うようなことは必要ないはずですが、実際には、可能であればフリーにテスト打鍵することも行うと好ましいことが多いです。特に、システム開発に対して豊富な経験をもっている人間にテスト打鍵してもらうことができると、そのような人は、これまでの経験から、このようなシステムであればこのような状況の場合にこのような操作をした場合にもきちんと動作するだろうかと、往々にしてきちんと実装されないことが多い状況を推測して打鍵してくれるので、テストケースでは網羅しきれないような不具合を見つけ出すことができます。テストケースをひとつひとつ漏れなく作成していくプロセスと、フリーで打鍵するプロセスは、不具合を探そうとする観点が異なるので、可能であれば、両面から動作検証できると信頼性は上がると思います。
Webディレクタとして次のステップをさがしている方たちへ
これからのWeb構築・Webディレクションとして、業務にまで踏み込んでディレクション/プロデュースすること、それが近年のバズワードであるDXにもつながること、そしてWebの進化とともにWeb構築の各種ツール/サービスやSaaSが広がってきていることにしたがって、業務とシステムの両面からWeb構築・運用していく人間が求められていくこと、そのためにどのような知識や能力を身に着けていくとよいかについて解説している「マガジン」です。