Skip to main content

Test Strategy

Testing was staged in three layers, each validating a different scope of the system before it reached production.

Unit testing

Backend controllers, services, and authentication logic, exercised in isolation with Jest.

Integration testing

API endpoints paired with frontend services, confirming that user actions land correctly in the database and reflect back in dashboards.

System testing

The full platform exercised end to end — login through application processing and mentor assignment — plus manual interface validation.

Unit testing

Jest was used to test backend functions directly, with particular attention to login and authentication logic since that code path gates every other feature. Objectives for this layer:

  • Verify individual components function correctly in isolation.
  • Confirm authentication, application handling, and role checks behave as expected.
  • Catch errors early, before they compound in integration testing.
  • Validate frontend components and services ahead of integration.

Integration testing

This layer focused on the seams between frontend and backend — the places where most real-world bugs tend to live. Objectives:

  • Verify interaction between frontend and backend components.
  • Confirm data flows correctly between services, database, and interfaces.
  • Confirm combined modules work together as expected, not just in isolation.
  • Surface interface and communication errors between components.

System testing and interface validation

System testing exercised the platform as a whole, validating the workflows that matter most to real users:

  • Role-specific login, including error handling for wrong credentials and wrong-role access attempts.
  • Event visibility and application.
  • Startup idea application, including automatic innovator account provisioning on approval.
  • Application filtering and approval by administrators.
  • Innovator management and mentor assignment.
  • Grouped notifications across user sets.
  • Report generation and filtering by date range.

DeSIC staff acted as real users during this phase, which surfaced usability issues that purely technical testing would have missed.

Performance against non-functional targets

Testing also validated the non-functional requirements defined during design — response time, concurrency, security controls, and uptime — with observed results captured in Results & Analysis.