75. Who Is MrChecker

75.1. Who is MrChecker?

MrChecker Test Framework is an end to end test automation framework written in Java. It is an automated testing framework for functional testing of web applications, API web services, Service Virtualization, Security, native mobile apps and, in the near future, databases. All modules have tangible examples of how to build resilient integration test cases based on delivered functions.

75.2. Where does MrChecker apply?

The main goal of MrChecker is to standardize the way we build BlackBox tests. It gives the possibility to have one common software standard in order to build Component, Integration and System tests.

A Test Engineer does not have access to the application source code in order to perform BlackBox tests, but they are able to attach their tests to any application interfaces, such as - IP address - Domain Name - communication protocol - Command Line Interface.

75.3. MrChecker’s specification:

  • Responsive Web Design application: Selenium Browser

  • REST/SOAP: RestAssure

  • Service Virtualization: Wiremock

  • Database: JDBC drivers for SQL

  • Security: RestAssure + RestAssure Security lib

  • Standalone Java application: SWING

  • Native mobile application for Android: Appium

75.4. Benefits

Every customer may benefit from using MrChecker Test Framework. The main profits for your project are:

  • Resilient and robust building and validation process

  • Quality gates shifted closer to the software development process

  • Team quality awareness increase - including Unit Tests, Static Analysis, Security Tests, Performance in the testing process

  • Test execution environment transparent to any infrastructure

  • Touch base with the Cloud solution

  • Faster Quality and DevOps-driven delivery

  • Proven frameworks, technologies and processes.

75.5. Test stages

75.5.1. Unit test

A module is the smallest compilable unit of source code. It is often too small to be tested by the functional tests (black-box tests). However, it is the ideal candidate for white-box testing. White-box tests have to be performed as the first static tests (e.g. Lint and inspections), followed by dynamic tests in order to check boundaries, branches and paths. Usually, that kind of testing would require enabling stubs and special test tools.

75.5.2. Component test

This is the black-box test of modules or groups of modules which represent certain functionalities. There are no rules about what could be called a component. Whatever a tester defines as a component, should make sense and be a testable unit. Components can be integrated into bigger components step by step and tested as such.

75.5.3. Integration test

Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered. The software is completed step by step and tested by tests covering a collaboration between modules or classes. The integration depends on the kind of system. For example, the steps could be as follows: run the operating system first and gradually add one component after another, then check if the black-box tests are still running (the test cases will be extended together with every added component). The integration is done in the laboratory. It may be also completed by using simulators or emulators. Additionally, the input signals could be stimulated.

75.5.4. Software / System test

System testing is a type of testing conducted on a complete integrated system to evaluate the system’s compliance with its specified requirements. This is a type of black-box testing of the complete software in the target system. The most important factor in successful system testing is that the environmental conditions for the software have to be as realistic as possible (complete original hardware in the destination environment).

Last updated 2021-03-17 08:55:56 UTC