Integration Testing

As the components are constructed and tested they are linked together to
make sure they work with each other. It is a fact that two components that
have passed all their tests, when connected to each other, produce one new
component full of faults. These tests can be done by specialists, or by the
developers.
Integration testing is not focused on what the components are doing but on
how they communicate with each other, as specified in the “System Design.”
The “System Design” defines relationships between components.
The tests are organized to check all the interfaces, until all the components
have been built and interfaced to each other producing the whole system.
System Testing
Once the entire system has been built then it has to be tested against the
“System Specification” to see if it delivers the features required. It is still
developer focused, although specialist developers known as systems testers
are normally employed to do it.
In essence, system testing is not about checking the individual parts of
the design, but about checking the system as a whole. In fact, it is one giant
component.
System testing can involve a number of special types of tests used to see if
all the functional and non-functional requirements have been met. In addition

to functional requirements these may include the following types of testing

for the non-functional requirements:
Performance - Are the performance criteria met?
Volume - Can large volumes of information be handled?
Stress - Can peak volumes of information be handled?
Documentation - Is the documentation usable for the system?
Robustness - Does the system remain stable under adverse
circumstances?
There are many others, the need for which is dictated by how the system is
supposed to perform.

(I) W hat’s the difference between System Testing

and Acceptance Testing?
Acceptance testing checks the system against the “Requirements.” It is
similar
to System testing in that the whole system is checked but the important
difference is the change in focus:
System testing checks that the system that was specified has been delivered.
Acceptance testing checks that the system will deliver what was requested.

Severity 1 (showstoppers): These kinds of defects do not

allow the application to move ahead. So they are also called
showstopper defects.
Severity 2 (application continues with severe defects):
Application continues working with these types of defects,
but they can have high implications, later, which can be more
difficult to remove.
Severity 3 (application continues with unexpected results): In
this scenario the application continues but with unexpected
results.
Severity 4 (suggestions): Defects with these severities are
suggestions given by the customer to make the application
better. These kinds of defects have the least priority and
are considered at the end of the project or during the
maintenance stage of the project.


an you explain requirement traceability and its

importance?
In most organizations testing only starts after the execution/coding phase of
the project. But if the organization wants to really benefit from testing, then
testers should get involved right from the requirement phase.
If the tester gets involved right from the requirement phase then
requirement traceability is one of the important reports that can detail what
kind of test coverage the test cases have.
The following figure shows how we can measure the coverage using the
requirement traceability matrix.
We have extracted the important functionality from the requirement
document and aligned it on the left-hand side of the sheet. On the other side,
20 Software Testing Interview Questions
at the top, we have mapped the test cases with the requirement. With this
we can ensure that all requirements are covered by our test cases. As shown
we can have one or more test cases covering the requirements. This is also
called requirement coverage.
Figure 25 Requirement Traceability
Note: Many professionals still think testing is executing test cases on the
application. But testing should be performed at all levels. In the requirement
phase we can use the review and traceability matrix to check the validity of
our
project. In the design phase we can use the design review to check the
correctness
of the design and so on.
ow did you define severity ratings in your
project?
Note: Severity ratings vary from organization to organization and project to
project. But most organizations have four kinds of severity rating as shown.
There are four types of severity ratings as shown in the table:
Figure 64 Test cases from the above decision tables
Figure 65 Severity rating in projects
60 Software Testing Interview Questions
Severity 1 (showstoppers): These kinds of defects do not
allow the application to move ahead. So they are also called
showstopper defects.
Severity 2 (application continues with severe defects):
Application continues working with these types of defects,
but they can have high implications, later, which can be more
difficult to remove.
Severity 3 (application continues with unexpected results): In
this scenario the application continues but with unexpected
results.
Severity 4 (suggestions): Defects with these severities are
suggestions given by the customer to make the application
better. These kinds of defects have the least priority and
are considered at the end of the project or during the
maintenance stage of the project.



What is a maturity level?
A maturity level specifies the level of performance expected from an
organization.
(B)
