System testing is concerned with the behavior of a whole system/product as defined by the scope of a development project or programme. Here, the test environment should correspond to the final target or production environment as much as possible in order to minimize the risk of environment-specific failures not being found in testing.
This testing may include tests based on risks and/or on requirements specifications, business processes, use cases, or other high level descriptions of system behavior, interactions with the operating system, and system resources.
It should investigate both functional and non-functional requirements of the system. Requirements may exist as text and/or models. Testers also need to deal with incomplete or undocumented requirements. System testing of functional requirements starts by using the most appropriate specification-based (black-box) techniques for the aspect of the system to be tested. For example, a decision table may be created for combinations of effects described in business rules. An independent test team often carries out system testing.
Difference between System testing and Integration testing
Integration Testing Activities
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This would encompass the QA verification of the developed modules and as new modules are delivered to QA teams they are integrated with the tested modules in a bottom up integration method. The completion of testing (sign off) for all the integrated modules marks completion of Integration testing.
System Testing Activities
~~~~~~~~~~~~~~~~~~~~~~~~~
System testing phase encompasses clean pass testing (if any) that is planned and end to end testing of the system. Performance testing is also in this phase.
Some measurements for monitoring test status during system test?
-How many were run?
-How many passed?
-Any of the ones that failed critical?
-How many defects total?
-How many closed?
-How many still open?
-Any of the ones open critical or show stoppers?
Difference between ST vs User Acceptance testing
System Testing (ST) usually occurs before Acceptance Testing (UAT). . UAT ideally, is a demonstration of the as-built system and is intended to show that:
- The user is getting what they expected.
- The user is not getting what was not expected.
- The user is confirming that they can do their job with the application.
ST is validation intended to prove that the system works and performs as-specified / as-designed / as-built. Furthermore ST is intended to detect system architectural and/or End-To-End defects - if all "ends" are available during ST. ST is validation and the expectation that surprises are detected and fixed, or - workarounds are provided before UAT. UAT is demonstration - with no surprises expected.
Types of system testing
The following examples are different types of testing that should be considered during System testing:
Usability testing : The capability of the software to be understood, learned, used and attractive to the user when used under specified conditions. [ISO 9126]
Performance testing : The process of testing to determine the performance of a software product. See also efficiency testing.
Compatibility testing : The process of testing to determine the compatibilityy of a software product.
Error handling testing : The degree to which a component or system can function correctly in the presence of invalid inputs or stressful environmental conditions. [IEEE 610]
Load testing : A test type concerned with measuring the behavior of a component or system with increasing load, e.g. number of parallel users and/or numbers of transactions to determine what load can be handled by the component or system.
Volume testing : Testing where the system is subjected to large volumes of data. See also resource-utilization testing.
Stress testing : Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements. [IEEE 610]
User help testing : Test the various guides and tutorials comes with the software or product.
Security test : This is used to determine the security of the software product.
Scalability testing : Testing to determine the scalability of the software product.
Smoke testing : A subset of all defined/planned test cases that cover the main functionality of a component or system, to ascertaining that the most crucial functions of a program work, but not bothering with finer details. A daily build and smoke test is among industry best practices. See also intake test.
Exploratory testing : An informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests.
Ad hoc testing : This is carried out informally; no formal test preparation takes place, no recognized test design technique is used, there are no expectations for results and arbitrariness guides the test execution activity.
Regression test : Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed.
Reliability testing : The process of testing to determine the reliability of a software product.
Maintenance testing : Testing the changes to an operational system or the impact of a changed environment to an operational system.
Accessibility : Testing to determine the ease by which users with disabilities can use a component or system.

| < Prev | Next > |
|---|