Skip to content

Testing concept

Jump to bottom
manuelaeschler edited this page Apr 16, 2018 · 7 revisions

Testing concept

Code structure

The product is separated in two parts, a Backend and a Frontend. They are completely non depended and only connected via the API. With this structure we will test backend, frontend and API individually.

Code review

During development the frontend and backend teams do code reviews to ensure the quality of the code and make testing easier.

Integration test / Unit Test

The backend code has to be tested properly. The main purpose of the backend is to deal with the data and send the data via API to the frontend. Theese tests are written with Jasmin:

  • Upload excel file and store it in database - tested with black box approach
  • Provide data for frontend (test API) - tested with black box approach

GUI test

The frontend will be tested separated from the backend. The purpose of the frontend is to pull data and display them on a geographical map. Theese tests are written with Jasmin:

  • Check the incoming data from the backend
  • Testing objects of frontend and their interactions

Usability test

This product is focused on the frontend part. The usability test will determine if the webapp can be used without a manual.

  • Target group: The target group are politicians, employees of insurance companies and every person who's insterested in hospital data. Form: Basically the usability test contains the use cases of the requirements. The user stories will be rewritten to tasks.
  • Pass criterium: If the majority of the test users can complete the tasks without help (manual) the test passes.
  • Due date: 27.04.2018

Functional test

The customer is not set on a fix idea but lets us implement his ideas by best practice based on the requirements. In each customer meeting the functional tests take place by presenting the current status of the product and the evaluation of the customer.

Installation test

Before we transfer the product to the customer we test the installation. This test is not critical but may save us some trouble after the project is finished. To execute this test we will create an installation checklist, by following it and succeeding installing the product the test passes.

Not implemented tests

  • Database test - we use mongoose for mongodb which makes database test obsolete
  • Stress test - the requirements do not expected more than 100 persons per day
  • Acceptance test - no such requirements or covered by functional test

Ohne Dokumentation wären wir alle Tiere.

Clone this wiki locally