ローコード開発の「テスト」とは？ 品質向上のポイントを解説

テストでは、開発したシステムやアプリケーションが、要件や設計で定めた内容どおりに動作するかを確認します。ローコード開発では、ツールに用意された機能や部品を組み合わせてアプリケーションを構築できますが、実装した機能に問題がないかを確認するために、従来のシステム開発と同様にテストを行うことが重要です。

この記事では、ローコード開発で行うテストについて理解し、intra-martのツールや機能を活用しながら、効果的にテストを進める方法と品質向上のポイントについて解説します。

ローコード開発でテストがこう変わる

ローコード開発では、ツールに用意された標準機能やプラットフォームの機能を活用してアプリケーションを開発できます。これらの機能は、製品側ですでに動作確認や品質確保が行われているため、アプリケーション側ですべての機能を一からテストする必要はありません。

ただし、標準機能を利用している場合でも、アプリケーションの要件や設計どおりに機能が組み合わされ、正しく動作するかを確認する必要があります。たとえば、認証やアクセス制御などの標準機能を利用する場合でも、アプリケーションに設定した権限や利用方法が要件を満たしているかを確認します。

このように、ローコード開発では、製品側で提供されている機能と、開発したアプリケーション固有の機能を切り分けて、テストの対象や観点を整理することが重要です。テスト内容を適切に見直すことで、必要な品質を確保しながら、テストにかかる工数を削減できる可能性があります。

テストにはいくつかの段階があり、テストを実施するタイミングや対象が異なります。一般的なシステム開発では、要件定義や設計などの上流工程と、各工程に対応するテスト工程をV字モデルで表すことがあります。機能単位からシステム全体まで、それぞれのテストで要件定義書や設計書などをもとに、想定した動作や品質を満たしているかを確認します。

ここでは、ローコード開発ツールを使用することで、従来のシステム開発と比べてテストの対象や観点をどのように整理できるのかについて、詳しく見ていきましょう。なお、単体テストは開発工程で実施する場合もありますが、他のテストとの違いを比較するため、ここでは併せて取り上げます。

内部設計を基に、単体テストを実施する

単体テストでは、モジュールやコンポーネントなどの機能単位で、設計どおりに動作するかを確認します。一般的には、開発工程で開発者が実施し、内部設計で定義した内容をもとにテスト項目を検討します。

ローコード開発では、標準機能を組み合わせて実装する部分については、プラットフォーム側で機能が提供されているため、標準機能そのものに対するテストをすべて行うのではなく、設定した内容や機能の組み合わせが要件・設計どおりに動作するかを確認することが重要です。

一方、独自のデータを扱う処理や、JavaScript、SQLなどを利用して独自の処理を実装した場合は、その実装内容を中心に単体テストを行い、想定した結果が得られるかを確認します。

このように、ローコード開発では、標準機能によって担保されている部分と独自に実装した部分を切り分け、必要なテストに重点を置くことで、テストの効率化につなげることができます。

外部設計を基に、結合テストを実施する

結合テストでは、単体テストで問題がないことを確認したモジュールやコンポーネントを組み合わせ、機能同士が設計どおりに連携して動作するかを確認します。一般的には、テスト工程で開発者またはテスト担当者が実施し、外部設計で定義した内容をもとにテスト項目を検討します。

単体では問題なく動作する機能でも、複数の機能を組み合わせることで、データの受け渡しや処理の順序などに問題が発生する場合があります。そのため、結合テストでは、機能間のインタフェース、データの整合性、処理の連携などを確認することが重要です。

ローコード開発では、ツールが提供する機能を組み合わせてアプリケーションを構築するため、各機能をどのように組み合わせているかに着目してテスト項目を検討するとよいでしょう。ここでは、結合テストの観点を「内部結合テスト」と「外部連携テスト」に分けて紹介します。

内部結合テスト

内部結合テストでは、システム内部の異なるモジュールやコンポーネントを対象として、それぞれの機能が正しく連携して動作するかを確認します。

特にローコード開発では、画面とビジネスロジック、ビジネスロジックとデータなど、ツール間で設定した機能の連携やデータの受け渡しについて確認するとよいでしょう。また、業務プロセスや業務フローに沿って処理が正しく進むか、想定したエラー処理が実行されるかといった点も確認します。

外部連携テスト

外部連携テストでは、開発したシステムと外部システムとの間で、データの受け渡しや処理の連携が正しく行われるかを確認します。

特に、外部システムとのデータ通信やREST APIを利用した連携では、リクエスト・レスポンスの内容やデータ形式が想定どおりであるかを確認するとよいでしょう。また、外部システムとの連携でエラーが発生した場合に、システム側で適切に処理できるかについても確認します。

要件定義（システム要件）を基に、システムテストを実施する

システムテストでは、結合テストで問題がないことを確認した機能をシステム全体として動作させ、要件どおりにシステムが動作するかを確認します。一般的には、テスト工程でテスト担当者が実施し、要件定義で定めたシステム要件（機能要件・非機能要件）をもとにテスト項目を検討します。

システムテストでは、個々の機能だけではなく、実際の利用場面を想定して、システム全体として要件を満たしているかを確認することが重要です。また、本番環境に近い環境でシステムを動作させ、残存するバグや想定外の動作がないかを確認します。

システムテストは、テストする観点によって「機能テスト」と「非機能テスト」に分けて考えることができます。ここでは、代表的なテストについて紹介します。

機能テスト

機能テストでは、要件定義で定めた機能要件をもとに、システムに必要な機能が正しく実装され、ユーザが想定した手順で利用できるかを確認します。

特にローコード開発では、ユーザシナリオに沿ってアプリケーションを操作し、画面・ビジネスロジック・データなど、複数の機能が連携して正しく動作するかを確認するとよいでしょう。また、正常な操作だけではなく、不正な入力や想定外の操作を行った場合に、適切なエラーハンドリングが行われるかについても確認します。

非機能テスト

非機能テストでは、要件定義で定めた非機能要件をもとに、性能・信頼性・セキュリティ・ユーザビリティなど、機能以外の要件を満たしているかを確認します。

ローコード開発では、プラットフォーム側で提供・担保されている機能や仕組みもあるため、プラットフォームの仕様を確認した上で、アプリケーション側で確認が必要な項目を洗い出すことが重要です。たとえば、アプリケーション独自の設定や外部システムとの連携など、開発内容によって必要となるテスト項目を検討します。

要件定義（業務要件）を基に、運用テストを実施する

運用テストでは、実際の業務でシステムを利用する場面を想定し、業務を問題なく進められるかを確認します。一般的には、テスト工程で運用担当者や実際の利用者が実施し、要件定義で定めた業務要件をもとにテスト項目を検討します。

また、システムの機能だけではなく、実際の業務手順に沿って操作できるか、業務上必要な情報を正しく登録・確認できるかといった観点から確認することが重要です。ここで問題が見つかった場合は、公開前に修正や設定の見直しを行います。

ローコード開発では、実際の業務を理解している現場担当者が開発に参加するケースもあります。その場合でも、開発者自身だけで動作を確認するのではなく、開発に参加していない利用者にも実際の業務を想定して操作してもらうとよいでしょう。開発者が想定していなかった操作方法や、業務上の使いにくさなどを発見できる可能性があります。

システムの品質を向上させ、公開後のトラブルを防ぐためにも、プロジェクトの規模に関わらず、実際の利用者による運用テストの実施を検討しましょう。

テストで活用できるintra-martの機能 

ここからは、各テスト工程で活用できるintra-martのツールや機能について紹介します。テストで問題が見つかった場合の原因調査や動作確認などに、intra-martの機能を活用すると、テストや改修を効率的に進めることができます。

ビジネスロジックのデバッグ

ビジネスロジックのデバッグは、主に単体テストや結合テストで問題が見つかった場合に、処理のどこに原因があるのかを調査するために利用します。IM-LogicDesignerでは、処理の内容やデータの値を確認しながらデバッグできます。

たとえば、以下のような機能を活用できます。

• マッピングのデバッグ機能：マッピング設定における入力値と出力値を確認する
• ロジックフローのデバッグ機能：デバッグ用の値を指定してフローを実行し、処理の過程を確認する
• ログ出力機能：実行時のログを出力し、処理の状況やデータの値を確認する

テストで問題が見つかった場合は、これらの機能を活用してビジネスロジックの処理やデータの受け渡しに問題がないかを確認し、原因を特定して修正します。また、修正後に再度デバッグを行うことで、意図したとおりに動作することを確認できます。

画面（アクション設定）のデバッグ

画面（アクション設定）のデバッグは、主に結合テストやシステムテストで問題が見つかった場合に、画面のアクション設定や変数の設定に原因がないかを調査するために利用します。IM-BloomMakerでは、デバッグツールを使用して、変数やアクションの設定、処理の過程を確認できます。たとえば、以下のような内容を確認できます。

• 変数：変数の一覧や変数値を確認する
• アクション：アクションやアクションアイテムの設定を確認する
• ブレイクポイント：アクションアイテムにブレイクポイントを設定し、処理の過程を確認する

テストで問題が見つかった場合は、これらの機能を活用して、画面のアクション設定やビジネスロジックとのデータの受け渡しなどに問題がないかを確認し、原因を特定して修正します。修正後は再度テストを行い、意図したとおりに動作することを確認します。

設計書の出力

テスト計画やテスト項目を検討する際には、実装したアプリケーションの構成や処理を把握するために、設計書を活用できます。intra-martでは、IM-LogicDesignerやIM-BloomMakerから、ビジネスロジックや画面コンテンツの設計書を出力できます。

テスト担当者が開発者と異なる場合は、開発後の最新の設計書を共有することで、実装内容を確認しながらテスト項目を検討できます。また、設計書をもとにテスト対象や確認内容を整理すると、テスト対象の抜け・漏れを防ぎ、効率的にテストを進めることができます。

また、ローコード開発では、設計した内容をもとにツール上で実装を進めるため、実装後の設計書をテストに活用することで、設計内容と実際の実装内容を確認することもできます。テスト工程で設計書を活用し、システムの品質向上につなげていきましょう。

認可設定（ユーザ権限）

認可設定は、ユーザがアプリケーションや機能などのリソースを利用できるかどうかを制御するための機能です。intra-martでは、組織や役職とは別に、ロールという単位でユーザに権限を付与し、リソースへのアクセスを制御できます。

認可設定は、アプリケーションを公開するときだけではなく、テスト工程でも活用できます。たとえば、テスト用のロールを作成してテスト担当者に割り当て、対象のアプリケーションだけにアクセスできるように設定します。これにより、実際の運用を想定したユーザ権限の状態で、テスト担当者にアプリケーションを操作してもらうことができます。

また、複数のユーザや権限による動作を確認する場合は、それぞれのロールに適切な認可設定を行うことで、権限によって利用できる機能や画面が正しく制御されているかを確認できます。

intra-martで始めるテストの流れ

ここからは、実際にintra-martのツールや機能を活用して、テストを進める方法について解説していきます。単体テストは開発工程で実施することが多いため、ここでは結合テスト、システムテスト、運用テストを対象とします。テストの各工程で、intra-martのツールや機能をどのように活用できるのかを見ていきましょう。

Step. 1　テスト対象を明確にし、テスト全体の計画を立てる

テストを実施する前に、まずテストの目的や観点を確認し、何をどこまで確認するのかを明確にします。開発したアプリケーションが要件定義書や設計書に基づいて正しく動作することを確認するため、機能、性能、運用などの観点からテスト対象を整理していきます。

テスト対象を明確にした後、結合テスト・システムテスト・運用テストといった各工程の計画を立てます。工程ごとに、テストの目的や方針、対象、実施時期、担当者などを決め、テスト全体のスケジュールや必要なリソースとあわせて計画書にまとめます。

特にローコード開発では、intra-martの標準機能を利用している部分など、プラットフォーム側で品質が担保されている範囲を考慮してテスト対象を整理することも重要です。必要なテストにリソースを集中させることで、効率的にテストを進められます。

Step. 2　テスト工程ごとに計画を立て、テスト設計を行う

テスト全体の計画を立案した後、結合テスト・システムテスト・運用テストごとに、詳細な計画とテスト設計を行います。テスト設計では、テスト対象の仕様や要件に基づいてテストケースを作成し、テストを実施するための条件や手順を定義します。テスト設計の内容は、テスト計画書やテスト実施要領などにまとめます。  

Step. 3　テスト環境を準備し、テストを実施する

Step. 2で作成したテスト実施要領にしたがって、テストの準備を進めます。intra-martでは、ロールの作成と認可設定の切り替えにより、運用を想定した環境をテスト環境として利用できます。テスト用のロールを作成してテスト担当者に割り当て、認可設定を行うことで、テスト担当者だけが開発中の画面などにアクセスできるようにします。

その他にも、テストシナリオやテスト項目表の作成、テストデータの準備などを行います。準備が整ったら、開発者またはテスト担当者がテストを実施し、結果を報告書などに記録します。

Step. 4　テスト結果を確認し、バグを修正する

テストで問題が見つかった場合は、テスト担当者からバグの報告を受けます。開発者はバグの原因を調査し、問題点や修正内容を明確にした上で、修正を行います。修正後は再テストを実施し、問題が解消されたことを確認します。必要に応じて修正と再テストを繰り返し、システムの品質を高めていきます。

Step. 5　システムを移行し、公開する

テストが完了し、システムの品質に問題がないことを確認した後、移行作業と公開の準備を進めます。移行作業では、既存システムから新システムへの移行や、既存データの移行などを行います。また、必要に応じて試験運用を行い、実際の業務で問題なく利用できることを確認します。

移行や試験運用に問題がないことを確認した後、一般ユーザに向けてシステムを公開します。現在の業務に支障が出ないように、移行方法や公開のタイミングなどをあらかじめ計画し、慎重に作業を進めましょう。

まとめ 

ローコード開発では、どのようなテストを行えばよいのかと疑問に思っていた方も多いのではないでしょうか。ローコード開発でも、システムの品質を確保するために、テストは欠かせません。一方で、ローコード開発ツールの標準機能を利用している場合など、プラットフォーム側で品質が担保されている部分については、テスト内容を見直せる場合があります。開発した機能や利用するツールの特性を踏まえて必要なテスト項目を整理することで、テストを効率的に進めることができます。

ローコード開発ガイドでは、要件定義から保守・運用までの各工程において、intra-martのローコード開発ツールの効果的な活用方法について解説しています。今回は、ローコード開発におけるテストの考え方や、テストで活用できるintra-martの機能、テストをスムーズに進めるためのポイントについて紹介しました。

intra-martのローコード開発ツールを最大限に活用するためにも、ぜひ他の記事もご覧ください。