Skip to end of metadata
Go to start of metadata

Functional testing

The functional testing is performed in order to compare the actual processes and overall system state, against their functional specifications. Upon differences between the specifications and the actual system, suggestions and recommendations are to be made for the resolution of those differences. This type of tests is planned for each state and version of the project development.

Goal: To check all functions of the system, according to the current specifications regarding the complete functionality of each module, including navigation, data entry, processes and their repetition.
Technique: Execution of the full set of written TCs, using valid and invalid data for each of the parameters, in order to be able to confirm:
  • The expected results, when valid (according to the functional specifications) data is entered.
  • The presence of informational message and the overall system state when invalid/wrongly entered data is given.
Criteria for successful completion:
  • All planned and written TCs are executed.
  • All bugs/defects found in the process of testing are documented.
Responsible: Tester

Load Testing

The purpose of this type of tests is to check the system state when loaded. The time needed to create a request from the user until the end result is received and shown in the portal is to be examined. The execution of these tests will take place after the first version is completed.

Goal: To check the functionality of the system against a predetermined duration under load.
Technique: Create TCs, that will confirm the correct actions of the tested functionality.
The change of the number of simulated calls and the time to execute each of them.
Criteria for successful completion:
  • Single user: the successful completion of TCs with no errors and identical to the expected result, according to functional specifications.
  • Multiple simulated calls: the successful completion of TCs with no errors and identical to the expected result, according to functional specifications. Documenting all arising bugs/defects.
Responsible: Developer

Regression Testing

Using regression testing, the previously discovered bugs and defects are to be examined, in order to make sure that they do not reappear in the upcoming versions. This type of tests will take place after each version of the product is launched, in order to maximize effectiveness and quality control.

Goal: Make sure that documented bugs/defects are corrected. If they reappear, document them again.
Technique: Use the TCs, previously created for the functional tests.
Criteria for successful completion:
  • All planned and written TCs are executed.
  • All documented bugs/defects are retested. When bugs/defects reappear in the process of testing, they are documented anew.
Responsible: Tester

User-interface testing

The performing of these tests will determine the level at which the user uses the services of the portal with maximum ease. Furthermore, the user-interface testing are to take place in order to determine the ease of browsing the portal, as well as whether all menus and options are easily accessible to the user, and whether they are logical.

Goal: Confirmation of the following parameters:
  • System navigation corresponds to the business and process logic.
  • All objects correspond to the standards, including the menus, size, space and positioning.
Technique: The tests are executed for all screens, in order to confirm any misplacement on the screen, switch of objects and fields. Browsers with different cores are used – Internet Explorer and Mozilla Firefox.
Criteria for successful completion:
  • Each screen corresponds to the standards and specifications.
  • No difference in the design, when using different browsers.
Responsible: Tester
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.