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

テストでは、開発されたシステムやアプリケーションが、要件や設計書に応じて正しく動作するかどうかを確認します。目的別にさまざまなテストを行うことによって、公開前に不具合（バグ）や誤動作を起こさないかを検証するだけではなく、ユーザが求める操作性、機能、パフォーマンス、セキュリティなどの品質が基準を満たしているかどうかも検証します。

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

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

ローコード開発では、ツールの標準機能を利用して開発を行う場合、プラットフォーム側で担保している機能があるため、一部のテストについては省略できます。たとえば、標準機能に関しては、すでにプラットフォーム側で機能テストを実施しています。セキュリティに関しても、プラットフォーム側で、認証、アクセス制御、データ暗号化などの機能を実装しています。このように、品質管理やセキュリティといった面で、プラットフォーム側に一任できる（テストを省略できる）項目が出てきます。テスト項目を見直し、必要な項目を抽出することで、テスト期間の短縮と効率化を実現できます。

テストにもいくつかの段階があり、テストのタイミングとテスト対象が異なります。テストの種類と開発工程の関係は、以下のようにV字モデルで表されます。機能単体からシステム全体に至るまで、要件定義書や設計書をもとに実施していきます。

ここでは、ローコード開発ツールを使用することで、従来のテスト内容がどのように変わるかについて、詳しく見ていきましょう。単体テストについては、テスト工程ではなく開発工程で実施しますが、他のテストと比較するために取り上げています。 

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

単体テストでは、モジュールやコンポーネントといった機能単位の動作を検証します。単体テストは、開発工程で開発者によって実施されることが多く、内部設計で作成した設計書を基にテスト項目を検討していきます。ローコード開発ツールの基本的な機能だけで実装した場合は、すでにプラットフォーム側で品質を担保しているため、機能に関するテストは省略できます。独自のデータを扱うなど、プログラミングによって複雑な機能を実装した場合は、正しく動作するかどうかを確認するため、実装箇所を中心に単体テストを実施すると良いでしょう。

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

結合テストでは、単体テストで問題ないと判断されたモジュールやコンポーネント同士を組み合わせて動作を検証します。結合テストは、テスト工程で開発者またはテスト担当者によって実施され、外部設計で作成した設計書をもとにテスト項目を検討していきます。単体テストでは問題がなかったモジュールやコンポーネントでも、複数のモジュールやコンポーネントを組み合わせることで、新たなバグが発生することもあります。そのため、結合テストでは、モジュール間のインタフェースの問題、データの不整合、機能的なエラーなど、あらゆる観点からテスト項目を検討していく必要があります。

結合テストは、テスト観点の違いにより、内部結合テストと外部連携テストに分けられます。どちらのテストも、機能と機能同士が正しく連携できているかを確認するという目的は同じです。なお、結合テストにはさまざまな種類やカテゴリが存在しますが、ここでは代表的なものについて紹介しています。

内部結合テスト

内部結合テストでは、システム内部の異なるモジュールやコンポーネント間を対象とし、それぞれの機能が相互に連携して正しく動作するかどうかを検証します。特に、ローコード開発では、業務プロセスや業務フローがシステム内部で適切に機能し、データの流れや処理の統合が正常に行われることやエラー処理が適切に機能することを確認すると良いでしょう。

外部連携テスト

外部連携テストでは、開発中のシステムと外部システム間を対象とし、データの受け渡しなどの処理が正しく動作するかどうかを検証します。特に、ローコード開発では、外部システムとのデータ通信、REST APIの動作確認、データベースとの連携について確認すると良いでしょう。

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

システムテストでは、結合テストで問題ないと判断された機能が、システム全体に実装された状態で検証します。システムテストは、テスト工程でテスト担当者によって実施され、要件定義で定めたシステム要件（機能要件・非機能要件）をもとにテスト項目を検討していきます。システム全体の機能性や品質基準を確認するため、システムテストは総合テストとも呼ばれます。システムテストは、開発の最終段階でもあり、本番環境でシステム全体の動作を確認し、システム全体に残存するバグの発見と修正を行います。

システムテストは、テスト観点の違いにより、機能テストと非機能テストに分けられます。システムテストも結合テストと同様に、さまざまな種類やカテゴリが存在しますが、ここでは代表的なものについて紹介しています。

機能テスト

機能テストでは、要件定義の機能要件がシステムに正しく実装されていることを検証します。ここでは、ユーザが期待している機能が搭載され、直感的に問題なく操作できることが求められます。特に、ローコード開発では、ユーザシナリオに基づいてアプリケーション内の各機能が正しく動作するかどうか、各機能が入力に対して適切に出力をするかどうかを検証することが大切です。その他にも、不正な入力や予期しない操作に備えて、各機能が適切にエラーハンドリングできているかどうかも併せて確認しておきましょう。

非機能テスト

非機能テストでは、要件定義の非機能要件がシステムに正しく実装されていることを検証します。非機能テストの範囲は多岐にわたり、システムの機能性以外の要件がテスト対象となります。たとえば、システムの性能、信頼性、セキュリティなどの要素が挙げられます。これらの要素は、ローコード開発の場合、プラットフォーム側で担保している項目も多いため、要件定義で検討した内容と併せて、必要なテスト項目を洗い出しておきましょう。

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

運用テストでは、実際の運用を想定して、システムが公開した後に正しく運用できるかどうかを検証します。運用テストは、テスト工程で運用担当者によって実施され、要件定義で定めた業務要件を基にテスト項目が検討されます。運用テストは公開直前に行われるため、バグを解消できないと、アプリケーションの運用に影響が出てしまいます。

ローコード開発では、実際のユーザである現場の担当者がシステムを構築すると、運用テストを省略してしまうかもしれません。もし、他にも利用者がいるのであれば、その方に運用テストを依頼することで、予期していなかったエラーを発見できる可能性も考えられます。システムの品質を向上させるためにも、プロジェクトの規模に関わらず、運用テストの実施を検討してみることをおすすめします。

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

ここからは、各テスト工程で利用できるintra-martのツールや機能について紹介していきます。intra-martのツールや機能を上手に活用し、テスト工程を効率よく進めていきましょう。

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

ビジネスロジックのデバッグは、主に単体テストと結合テストで行います。テストでバグが見つかったビジネスロジックに対して、IM-LogicDesignerの各機能を使用して、以下に示すデバッグを実行します。

• マッピングのデバッグ機能：マッピング設定の入力値に対する出力値を確認する
• ロジックフローのデバッグ機能：デバッグの値を指定してフローを実行する
• ログ出力設定とログを用いたデバッグ：デバッグログを出力し、ログ情報を確認する

個々のビジネスロジックが正しく動作し、他のコンポーネントやモジュールとの連携が問題なく行われるように、デバッグによってバグを解決しておきましょう。

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

画面（アクション設定）のデバッグは、主に結合テストとシステムテストで行います。テストでバグが見つかった画面（アクション設定）に対して、IM-BloomMakerのデバッグツールを使用して、変数やアクションの設定を確認していきます。

個々の画面（アクション設定）が正しく動作し、ユーザインタフェースとビジネスロジックとの連携が問題なく行われるように、デバッグによりバグを解決しておきましょう。

設計書の出力

テスト計画やテストケースを作成する際、設計書は重要な情報源として活用されます。intra-martの設定書出力機能を使用して、ビジネスロジックと画面コンテンツの設計書を出力します。テストの種類によっては、開発者以外の方がテスト担当者になる場合もあるため、開発後（単体テスト済）の設計書を最新情報として渡すことが可能です。正しい設計書を渡すことで、開発した機能を漏れなく選定し、より正確なテストを実施できます。システムの品質を向上させるためにも、設計書は重要な役割を果たします。

認可設定（ユーザ権限）

認可設定（ユーザ権限）は、システム内のアクセス制御や権限管理を行うための機能です。intra-martでは、組織や役職とは別に、ロールと呼ばれる単位によって特定のユーザに対して認可設定（ユーザ権限）が行えます。認可設定は、アプリケーション公開時にユーザの権限を追加するだけではなく、テスト工程でも利用できます。テスト用のロールを作成し、テスト担当者に割り当てることで、その担当者のみが対象のアプリケーション画面にアクセスできます。認可設定を切り替えるだけで、公開前の本番環境と同じ環境で、テストを実施できます。

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

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

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

テストを実施する前に、まずテストの目的とテスト観点を確認し、テスト対象を明確にしていきます。テストを実施する主な目的は、システムの品質を確保し、問題を特定して修正することです。テストによってバグが解消されると、システムの品質が向上します。また、潜在的なリスクを特定し、リスクを最小限に抑えることができます。開発したアプリケーションが要件定義書や設計書に基づき動くことを確認するため、機能確認・性能検証・運用評価といった観点で、テスト対象を明確にしていきます。

テスト対象を明確にした後、結合テスト・システムテスト・運用テストといった工程を含めたテスト全体の計画を立てます。テストの工程別に、目的と方針、テスト対象をそれぞれ決めていき、テスト全体のリソース調整やスケジュールなどを計画書にまとめます。

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

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

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

設計で作成した詳細プロトタイプを使用して、ビジネスロジックの詳細設計を進めていきます。intra-martの各ツールとの機能連携や外部システムとの連携などの有無を確認し、複雑な処理についてはユーザ定義タスクを作成します。ビジネスロジックの実装が一通り終了した後は、単体テストとデバッグを行い、バグを解消していきます。  

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

テスト結果に問題があった場合、テスト担当者からバグの報告をしてもらいます。開発者はバグの原因を探り、問題点や改善点を明確にしてから、修正していきます。修正した後は再テストを実施し、バグが発生しなくなるまで、修正とテストを繰り返します。  

Step. 5　業務・システム移行と公開設定

テストが完了し、システムの品質に問題がないことが明らかになった後、移行作業に進みます。移行作業には、ユーザ業務の移行、既存データの新システムへの移行、現在使用しているシステムから新システムへの移行が含まれます。移行計画を立て、公開前に試験運用を行います。運用に問題がないことが確認できた後、一般ユーザに向けて公開します。現在の業務に支障が出ないように、綿密に計画を立て、慎重に移行作業と公開設定を行いましょう。

まとめ 

ローコード開発では、どのようなテストを行うと良いのかと疑問に思っていた方も多いのではないでしょうか？ システムの品質向上の観点からもテスト工程は欠かせません。各テスト工程では、そのテストの項目を一部省略できることもあります。たとえば、ローコード開発ツールの標準機能だけを使用して、簡易的なアプリケーションを作成した場合、プラットフォーム側で品質を担保できていると確認できる項目については省略しても良いでしょう。ローコード開発ツールの機能から必要なテスト項目を抽出することで、従来のシステム開発よりも大幅にテスト期間を短縮することが可能となります。

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

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