System testing and component testing

System testing :

System testing, also referred to as system-level tests or system-integration

testing, is the process in which a quality assurance (QA) team evaluates how
the various components of an application interact together in the full,
integrated system or application.

System testing verifies that an application performs tasks as designed. This

step, a kind of black box testing, focuses on the functionality of an application.
System testing, for example, might check that every kind of user input
produces the intended output across the application.

With system testing, a QA team gauges if an application meets all of its

requirements, which includes technical, business and functional requirements.
To accomplish this, the QA team might utilize a variety of test types,
including performance, usability, load testing and functional tests.

Additionally, each individual type of system test reports relevant metrics of a

piece of software, including:

 Performance testing: speed, average, stability and peak Response

times;

 Load testing: throughput, number of users, latency; and

 Usability testing: user error rates, task success rate, time to complete
a task, user satisfaction.

System Testing is Blackbox

Two Category of Software Testing

 Black Box Testing

 White Box Testing
Types of system testing

Types of System Testing

There are more than 50 types of System Testing. For an exhaustive list of software
testing types click here. Below we have listed types of system testing a large
software development company would typically use

1. Usability Testing – mainly focuses on the user’s ease to use the application,

flexibility in handling controls and ability of the system to meet its objectives
2. Load Testing – is necessary to know that a software solution will perform
under real-life loads.
3. Regression Testing – involves testing done to make sure none of the
changes made over the course of the development process have caused new
bugs. It also makes sure no old bugs appear from the addition of new
software modules over time.
4. Recovery Testing – is done to demonstrate a software solution is reliable,
trustworthy and can successfully recoup from possible crashes.
5. Migration Testing – is done to ensure that the software can be moved from
older system infrastructures to current system infrastructures without any
issues.
6. Functional Testing – Also known as functional completeness
testing, Functional Testing involves trying to think of any possible missing
functions. Testers might make a list of additional functionalities that a
product could have to improve it during functional testing.
7. Hardware/Software Testing – IBM refers to Hardware/Software testing as
“HW/SW Testing”. This is when the tester focuses his/her attention on the
interactions between the hardware and software during system testing.

Acceptance testing:

Acceptance Testing is a method of software testing where a system is tested for

acceptability. The major aim of this test is to evaluate the compliance of the
system with the business requirements and assess whether it is acceptable for
delivery or not. Standard Definition of Acceptance Testing:
It is a formal testing according to user needs, requirements and business
processes conducted to determine whether a system satisfies the acceptance
criteria or not and to enable the users, customers or other authorized entities to
determine whether to accept the system or not.
Acceptance Testing is the last phase of software testing performed after
System Testing and before making the system available for actual use. 
 
Types of Acceptance Testing:
1. User Acceptance Testing (UAT): User acceptance testing is used to
determine whether the product is working for the user correctly.
Specific requirements which are quite often used by the customers are
primarily picked for the testing purpose. This is also termed as End-
User Testing.
2. Business Acceptance Testing (BAT): BAT is used to determine
whether the product meets the business goals and purposes or not.
BAT mainly focuses on business profits which are quite challenging
due to the changing market conditions and new technologies so the
current implementation may have to being changed which results in
extra budgets.
3. Contract Acceptance Testing (CAT): CAT is a contract that specifies
that once the product goes live, within a predetermined period, the
acceptance test must be performed and it should pass all the
acceptance use cases. Here is a contract termed a Service Level
Agreement (SLA), which includes the terms where the payment will be
made only if the Product services are in-line with all the requirements,
which means the contract is fulfilled. Sometimes, this contract
happens before the product goes live. There should be a well-defined
contract in terms of the period of testing, areas of testing, conditions
on issues encountered at later stages, payments, etc.
4. Regulations Acceptance Testing (RAT): RAT is used to determine
whether the product violates the rules and regulations that are defined
by the government of the country where it is being released. This may
be unintentional but will impact negatively on the business. Generally,
the product or application that is to be released in the market, has to
go under RAT, as different countries or regions have different rules
and regulations defined by its governing bodies. If any rules and
regulations are violated for any country then that country or the
specific region then the product will not be released in that country or
region. If the product is released even though there is a violation then
only the vendors of the product will be directly responsible.
5. Operational Acceptance Testing (OAT): OAT is used to determine
the operational readiness of the product and is non-functional testing.
 It mainly includes testing of recovery, compatibility, maintainability,
reliability, etc. OAT assures the stability of the product before it is
released to production.
6. Alpha Testing: Alpha testing is used to determine the product in the
development testing environment by a specialized testers team usually
called alpha testers.
7. Beta Testing: Beta testing is used to assess the product by exposing
it to the real end-users, usually called beta testers in their
environment. Feedback is collected from the users and the defects are
fixed. Also, this helps in enhancing the product to give a rich user
experience

Use of Acceptance Testing:

To find the defects missed during the functional testing phase.


How well the product is developed.

A product is what actually the customers need.

Feedback help in improving the product performance and user

experience.
 Minimize or eliminate the issues arising from the production.
Advantages of Acceptance Testing :
 This testing helps the project team to know the further requirements
from the users directly as it involves the users for testing.
 Automated test execution.
 It brings confidence and satisfaction to the clients as they are directly
involved in the testing process.
 It is easier for the user to describe their requirement.
 It covers only the Black-Box testing process and hence the entire
functionality of the product will be tested.

What is meant by component testing?

Definition: Component testing, also known as program or module testing, is done after unit testing. In
this type of testing those test objects can be tested independently as a component without integrating
with other components e.g. modules, classes, objects, and programs. This testing is done by the
development team.
 (picture)

The Goals of Component Testing

The primary purpose of executing the component testing is to validate the input/output
performance of the test object. And also makes sure the specified test object's
functionality is working fine as per needed requirement or specification.

Let's see some of the other vital goals of component testing:

o Reducing Risk
o Identifying defects/bugs in the component
o Validate whether the functional and non-functional performance of the
component is as expected
o Developing confidence in the component's quality
o Stopping defects from escaping to higher test levels
 ( The goal of component testing)

o Reducing Risk

The implementation of components testing validates every single unit of the application.
And helps the developers in order to identify the bugs in the code and fix them. Thus,
we can say that component testing diminishes the possibilities of risk at a fundamental
level.

o Identifying defects/bugs in the component

Another essential purpose of performing the component testing is to identify errors in

the source code. Furthermore, it also validates control flow, functions, data structure,
etc., which are used in the program.

o Validate whether functional and non-functional performances of the

component are as expected

The purpose of executing the component testing is to verify that the functional and
non-functional features of the component are functioning correct or not.
In other words, we can describe that the execution of component testing guarantees
their design and specifications are performing as expected.

It may involve functional features such as the correctness of calculations and non-

functional features like exploring memory leaks.

o Developing confidence in the component's quality

As we understood from the definition of the component testing, it has occurred on the
unit level, and most of the errors are identified and fixed while coding itself.

The components testing plays a crucial role in building confidence in the component,
which means fewer bugs or defects in the additional testing.

o Stopping defects from escaping to higher test levels

Conclusively, in Component testing, the coding errors are identified and fixed by the
developers. And as an outcome, component testing diminishes the existence of errors in
the higher level of testing.

Who performs Component Testing?

The component testing is performed by test engineers or the developers who write
the codes with IDE help. As we already knew, Unit Testing is executed by the
developers to perform the testing of the particular features or methods.

Component Testing Process

The process of component testing can be completed in the following seven steps, as we
can see in the below image:
(component testing process image)

Let's discussed them one by one for our better understanding:

Step1: Requirement Analysis

The first step of component testing is requirement analysis, where the user
requirement associated with each component is detected.

Step2: Test Planning

Once the requirement analysis phase is done, we will mov to the next step of
component testing process, which is test planning. In this phase, the test is designed to
evaluate the requirement given by the users/clients.

Step3: Test Specification

Once the test planning phase is done, we will move to the next phase, known as test
specification. Here, we will identify those test cases that needs to be executed and
missed.

Step4: Test Implementation

The forth step in the component testing process is Test implementation. When the test
cases are identified as per the user requirements or the specification, then only we can
implement the test cases.

Step5: Test Recording

When all the above steps have been completed successfully, we will go to the next step
that is, Test Recording. In this step of the component testing process, we have the
records of those defects/bugs discovered during the implementation of component
testing.

Step6: Test Verification

Once the bugs or defects have been recorded successfully, we will proceed to the test
verification phase. It is the process of verifying whether the product fulfils the
specification or not.

Step7: Completion
After completed all the above steps successfully, we will come to the last step of the
component testing process. In this particular step, the results will be evaluated in order
to deliver a good quality product.

When do we need to perform the Component

testing?
When the unit testing is done on the particular application, we can proceed with the
component testing. The components are tested once they are developed; thus, the
output retrieved from a component under test depends on other components that are
not created so far.

According to the development lifecycle model, component testing might be executed

in segregation with other system components.

And the segregation is performed to stop the outside effects. Therefore, we will
use Stubs and Drivers to pretend the interface between software components to test
that component.
Why Is Component Testing Essential?
In Software Testing, component testing plays an essential role. Let's understand this with
the help of the following points:

(why component testing is essential image )

Allows Detailed Examination

The execution of components testing is allowing the detailed examination once each
module or component has been acquired.

It can be tested entirely or exhaustively for all the possible bugs or errors on actual web
servers. And this fact is entirely exceptional to the Component Testing as we compared
to the Unit Testing where every unit is not tested on live servers.

Early Error Detection

As we understood from the above explanation of Component Testing, it can be
implemented at any stage, which helps us identify and fix those errors relatively soon,
and as a result, we save both money and lots of time.

And the development team can test the component for all the preventable bugs or
defects before giving it over to the quality assessment team.

Certifies Contract
The implementation of Component Testing will help us to certify the contract, which
implies that the component testing is repeatable.

So, we can say that component testing is the best way to authenticate our module,
which delivers the whole thing that it promised. And as a consequence, any integration
with the given software can be performed without any uncertainties and doubts.

The Different test strategy of Component Testing

The Component Testing is separated into the following two types, based on the testing
level's complexity.

1. Component Testing in Small (CTIS)

2. Component Testing in Large (CTIL)

(different test stragety of componennet testing image)

For our better understanding let's discussed them one by one:

1. Component Testing in Small (CTIS)

Some component testing may be performed with or without other modules in the
particular application or the software under a test. If the component testing is executed
in the segregation with other modules is signified as component testing in
small, which is also denoted as CTIS.
Let see one sample example, where we can clearly understand how Component testing
in small works.

For Example: Suppose we have one website, which includes five different web pages.
Therefore, testing each webpage individually and with the isolation of other
components is signified as Component testing in Small.

2. Component Testing in Large (CTIL)

The component testing in large is testing, where we execute the component testing
without segregation with having other modules of the software.

This type of testing has occurred when there is a dependency on the performance flow
of the modules, and consequently, we can't separate them. Those components on which
we have the dependency are not created yet, and then we use the replicate modules
instead of the actual modules or components.

Let us see an example of component testing in large for our better understanding.

For Example

Let us assume that we have a web application containing three different

modules: Module P, Module Q, and Module R.

Here, the developer has created Module Q, which needs to be tested.

However, to test Module Q entirely, some of its features are reliant on Module P, and
some of its features are reliant on Module R.

So that, performance flow of the particular modules are as follows

Module P → Module Q → Module R

This performance flow implies that there is a dependency to Module Q from

both Module P and Module R. As we can see in the below image, we have Stubs and
Driver where stubs are called as the called function, and the drivers are called as
the calling function.
(module image )

But the Module P and Module R have not been established until now. So, in this
scenario, if we want to test Module Q entirely.

Thus, we can interchange Module P and Module R with the help of Stub and

Drivers as per the requirement.

Hence, Module P and Module R are primarily changed by stub and Driver that are
performed as a replica object until they are created.

Suppose we have a web application containing three different modules as Login,

Home, and User.

The first module (Login) is installed in the testing environment, but the other two
modules, Home and User, need to be called by the Login module that is yet to be
finished.

For testing purpose, the developer will add a segment of code that replicates the call
methods of the remaining modules. And this specific segment of code is known
as Stubs which is considered a top-down approach.

If second module (Home) and third module (User) are ready, but the Login module is

yet to be developed, from where both components get their return values, the
developer will add a code that replicates the Login module.

And this specific segment of code is known as a Drivers, which is considered a bottom-
up approach.
Conclusion
In this section, we have discussed the in-depth knowledge of Component Testing. And,
we can conclude that it is an exact way of estimate the functioning of any module at any
stage of development.

In software development, component testing is cost-saving and saves an unnecessary

headache at a future stage by removing all avoidable bugs.

Al last, we can say the Unit testing and Component testing are executed

simultaneously. As opposed to Unit testing executed by the development team, the
Component/module testing is executed by the Testing team.

It is always suggested to have complete Component testing performed before starting

the Integration testing. Because if the Component testing is accurate, we will identify
more minor defects during the integration testing.