Testing Shows The Presence of Bugs
Testing Shows The Presence of Bugs
The Waterfall Model was first Process Model to be introduced. It is also referred to as a
linear-sequential life cycle model. It is very simple to understand and use. In a waterfall
model, each phase must be completed fully before the next phase can begin. This type of
model is basically used for the project which is small and there are no uncertain
requirements. At the end of each phase, a review takes place to determine if the project is on
the right path and whether or not to continue or discard the project. In this model the testing
starts only after the development is complete. In waterfall model phases do not overlap.
Diagram of Waterfall-model:
Advantages of waterfall model:
It is easy to manage due to the rigidity of the model each phase has specific
deliverables and a review process.
In this model phases are processed and completed one at a time. Phases do not
overlap.
Waterfall model works well for smaller projects where requirements are very well
understood.
Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
Not suitable for the projects where requirements are at a moderate to high risk of
changing.
A starting point is determined for the work. All the information available is gathered together
in an attempt to get an idea of what the new system will be expected to do, and how it can be
done.
A rudimentary first-generation system is put together, based on the information gathered and
the ideas formulated in the first step.
The first-generation system is tested to see how it performs, what it can and cannot do, and
what might be done to improve it.
A second-generation system is developed from the first one, based on the improvements
proposed in the previous step.
The second-generation system is tested, as was the first. Its performance is evaluated, and
possible improvements determined.
The process is repeated as many times as necessary to obtain user satisfaction, or until it is
decided that the project is unworkable.
Routine maintenance is carried out on a continuing basis to prevent large-scale failures and
to minimize downtime.
The basic idea in Prototype model is that instead of freezing the requirements before a design
or coding can proceed, a throwaway prototype is built to understand the requirements. This
prototype is developed based on the currently known requirements. Prototype model is a
software development model. By using this prototype, the client can get an actual feel of
the system, since the interactions with prototype can enable the client to better understand
the requirements of the desired system. Prototyping is an attractive idea for complicated and
large systems for which there is no manual process or existing system to help determining
the requirements.
The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spirals, starting in the planning phase, requirements are
gathered and risk is assessed. Each subsequent spiral builds on the baseline spiral.
Planning Phase: Requirements are gathered during the planning phase. Requirements like
BRS that is Business Requirement Specifications and SRS that is System Requirement
specifications.
Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and
alternate solutions. A prototype is produced at the end of the risk analysis phase. If any risk
is found during the risk analysis then alternate solutions are suggested and implemented.
Engineering Phase: In this phase software is developed, along with testing at the end of the
phase. Hence in this phase the development and testing is done.
Evaluation phase: This phase allows the customer to evaluate the output of the project to
date before the project continues to the next spiral.
Logging phase: In this phase the issues and the defects that have been identified during the
preparation step are logged page by page.
Discussion phase: If any issue needs discussion then the item is logged and then handled in
the discussion phase.
Decision phase: At the end of the meeting a decision on the document under review has to be
made by the participants, sometimes based on formal exit criteria.
Structural testing takes into account the code, code structure, internal design, and how
they are coded.
The fundamental difference between structural testing and static testing is that in
structural testing tests are actually run by the computer on the built product, whereas
in static testing the product is tested by human using just the source code and not the
executables or binaries.
Structural testing entails running the actual product against some predesigned test
cases to exercise as much of the code as possible or necessary.
Code coverage was among the first methods invented for systematic software testing.
There are a number of coverage criteria, the main ones being:[5]
Function coverage Has each function (or subroutine) in the program been called?
Statement coverage Has each statement in the program been executed?
Branch coverage Has each branch (also called DD-path) of each control structure (such as
in if and case statements) been executed? For example, given an if statement, have both the
true and false branches been executed? Another way of saying this is, has every edge in the
program been executed?
Condition coverage (or predicate coverage) Has each Boolean sub-expression evaluated
both to true and false?
Lower the Program's cyclomatic complexity, lower the risk to modify and easier to
understand. It can be represented using the below formula:
V-Model means Verification and Validation model. Just like the waterfall model, the V-
Shaped life cycle is a sequential path of execution of processes. Each phase must be
completed before the next phase begins. Testing of the product is planned in parallel with a
corresponding phase of development.
Diagram of V-model:
The various phases of the V-model are as follows:
Requirements like BRS and SRS begin the life cycle model just like the waterfall model.
But, in this model before development is started, a system test plan is created. The test plan
focuses on meeting the functionality specified in the requirements gathering.
The high-level design (HLD) phase focuses on system architecture and design. It provides
overview of solution, platform, system, product and service/process. An integration test plan
is created in this phase as well in order to test the pieces of the software systems ability to
work together.
The low-level design(LLD) phase is where the actual software components are designed. It
defines the actual logic for each and every component of the system. Class diagram with all
the methods and relation between classes comes under LLD. Component tests are created in
this phase as well.
The implementation phase is, again, where all coding takes place. Once coding is complete,
the path of execution continues up the right side of the V where the test plans developed
earlier are now put to use.
Coding: This is at the bottom of the V-Shape model. Module design is converted into code
by developers..
3) Code inspection:
Code inspection also called Fagan inspection is a method,normally with a high degree of formalism.
To detect all faults, violations, and other side effects.
This method increases the number of defects detected by:
e. Demanding through preparation before and inspections/review;
f. Enlisting multiple diverse views;
g. Assigning specific roles to the multiple participants.
h. Going sequentially through the code in structured manner.
Branch Coverage - This technique is running a series of tests to ensure that all branches are
tested at least once.
Path Coverage - This technique corresponds to testing all possible paths which means that
each statement and branch are covered.
16.Explain Top down, bottom up and bi-directional integration and system integration?
Top-down integration testing is an integration testing technique used in order to simulate the
behaviour of the lower-level modules that are not yet integrated. Stubs are the modules that
act as temporary replacement for a called module and give the same output as that of the
actual product.
The replacement for the 'called' modules is known as 'Stubs' and is also used when the
software needs to interact with an external system.
Bottom-up testing is a specific type of integration testing that tests the lowest components of
a code base first. More generally, it refers to a middle phase in software testing that involves
taking integrated code units and testing them together, before testing an entire system or code
base.
IT professionals refer to design assemblies, or groups of code modules that are evaluated for
overall functioning, in integrated testing environments.
a) In Software Development Life Cycle the System Testing is perform as the first level of
testing where the System is tested as a whole.
c) System Testing enables you to test, validate and verify both the Application Architecture
and Business requirements.
Generally, a separate and dedicated team is responsible for system testing. And, System
Testing is performed on staging server which is similar to production server. So this means
you are testing software application as good as production environment.
Integration Testing is a level of software testing where individual units are combined and
tested as a group.
The purpose of this level of testing is to expose faults in the interaction between integrated
units. Test drivers and test stubs are used to assist in Integration Testing.
integration testing: Testing performed to expose defects in the interfaces and in the
interactions between integrated components or systems. See also component integration
testing, system integration testing.
component integration testing: Testing performed to expose defects in the interfaces and
interaction between integrated components.
system integration testing: Testing the integration of systems and packages; testing
interfaces to external organizations (e.g. Electronic Data Interchange, Internet).
1) Requirements Coverage:
=> Has the software been tested against all requirements for the normal range of use?
=> Has the software been tested against all requirements for abnormal or unexpected usage?
Code Statements
Decisions
Conditions and Decisions
3) Architectural Coverage:
=>Have the actual control and data links been utilised during testing?
Data Paths
Control Links
21.Explain all the challenges in white box testing
1. Human tendency of a developer being unable to find the defects in his or her
code = since white box testing involves programmers who write the code, it is
quite possible that they may not be most effective in detecting defects in their own
work product
Fully tested code may not correspond to realistic scenarios = this mean that even after
extensive testing, some of the common user scenarios may get left out and defects may creep
in