Answer / divya

Waterfall model

A project using waterfall model moves down a series of steps
starting from an initial idea to a final
product. At the end of each step, the project team holds a
review to determine if they’re ready to
move to the next step. If the project isn’t ready to
progress, it stays at that level until it’s ready.
Each phase requires well-defined information, utilizes
well-defined process, and results in well defined
outputs. Resources are required to complete the process in
each phase and each phase is
accomplished through the application of explicit methods,
tools and techniques.
The Waterfall model is also called the Phased model because
of the sequential move from one
phase to another, the implication being that systems cascade
from one level to the next in smooth
progression. It has the following seven phases of development:
The figure represents the Waterfall Model.
Notice three important points about this model.
􀂃 There’s a large emphasis on specifying what the product
will be.
􀂃 The steps are discrete; there’s no overlap.
􀂃 There’s no way to back up. As soon as you’re on a step,
you need to complete the
tasks for that step and then move on.
Requirement phase
Analysis phase
Design phase
Development phase
Testing phase
Implementation phase
Maintenance phase
Notice three important points about this model.
􀂃 There’s a large emphasis on specifying what the product
will be.
􀂃 The steps are discrete; there’s no overlap.
􀂃 There’s no way to back up. As soon as you’re on a step,
you need to complete the
tasks for that step and then move on.

Prototype Model

The Prototyping model, also known as the Evolutionary model,
came into SDLC because of certain
failures in the first version of application software. A
failure in the first version of an application
inevitably leads to need for redoing it. To avoid failure of
SDLC, the concept of Prototyping is used.
The basic idea of Prototyping is that instead of fixing
requirements before the design and coding
can begin, a prototype is to understand the requirements.
The prototype is built using known
requirements. By viewing or using the prototype, the user
can actually feel how the system will
work.
The prototyping model has been defined as:
“A model whose stages consist of expanding increments of an
operational software with the
direction of evolution being determined by operational
experience.”
Prototyping Process
The following activities are carried out in the prototyping
process:
• The developer and die user work together to define the
specifications of the critical parts
of the system.
• The developer constructs a working model of the system.
• The resulting prototype is a partial representation of the
system.
• The prototype is demonstrated to the user.
• The user identifies problems and redefines the requirements.
• The designer uses the validated requirements as a basis
for designing the actual or
production software
Prototyping is used in the following situations:
• When an earlier version of the system does not exist.
• When the user's needs are not clearly definable/identifiable.
• When the user is unable to state his/her requirements.
• When user interfaces are an important part of the system
being developed.

Spiral model

The traditional software process models don't deal with the
risks that may be faced during project
development. One of the major causes of project failure in
the past has been negligence of project
risks. Due to this, nobody was prepared when something
unforeseen happened. Barry Boehm
recognized this and tried to incorporate the factor, project
risk, into a life cycle model. The result is
the Spiral model, which was first presented in 1986. The new
model aims at incorporating the
strengths and avoiding the different of the other models by
shifting the management emphasis to
risk evaluation and resolution.
Each phase in the spiral model is split into four sectors of
major activities.
These activities are as follows:
Objective setting:
This activity involves specifying the project and process
objectives in terms of their functionality
and performance.
Risk analysis:
It involves identifying and analyzing alternative solutions.
It also involves identifying the risks that
may be faced during project development.
Engineering:
This activity involves the actual construction of the system.
Customer evaluation:
During this phase, the customer evaluates the product for
any errors and modifications.


SDLC

Let us look at the Traditional Software Development life
cycle vs Presently or Mostly commonly
used life cycle.
Fig A (Traditional) Fig B (Most commonly used)
In the above Fig A, the Testing Phase comes after the
Development or coding is complete and
before the product is launched and goes into Maintenance
phase. We have some disadvantages
using this model - cost of fixing errors will be high
because we are not able to find errors until
coding is completed. If there is error at Requirements phase
then all phases should be changed.
So, total cost becomes very high.
During the Requirements phase, the emphasis is upon
validation to determine that the defined
requirements meet the needs of the organization. During
Design and Development phases, the
emphasis is on verification to ensure that the design and
program accomplish the defined
requirements. During the Test and Installation phases, the
emphasis is on inspection to determine
that the implemented system meets the system specification.
During the maintenance phases, the
system will be re-tested to determine that the changes work
and that the unchanged portion
continues to work.
Requirements and Analysis Specification
The main objective of the requirement analysis is to prepare
a document, which includes all the
client requirements. That is, the Software Requirement
Specification (SRS) document is the
primary output of this phase. Proper requirements and
specifications are critical for having a
successful project. Removing errors at this phase can reduce
the cost as much as errors found in
the Design phase. And also you should verify the following
activities:
• Determine Verification Approach.
• Determine Adequacy of Requirements.
• Generate functional test data.
• Determine consistency of design with requirements.
Design phase
In this phase we are going to design entire project into two
• High –Level Design or System Design.
• Low –Level Design or Detailed Design.
High –Level Design or System Design (HLD)
High – level Design gives the overall System Design in terms
of Functional Architecture and
Database design. This is very useful for the developers to
understand the flow of the system. In
this phase design team, review team (testers) and customers
plays a major role. For this the entry
criteria are the requirement document that is SRS. And the
exit criteria will be HLD, projects
standards, the functional design documents, and the database
design document.
Low – Level Design (LLD)
During the detailed phase, the view of the application
developed during the high level design is
broken down into modules and programs. Logic design is done
for every program and then
documented as program specifications. For every program, a
unit test plan is created.
The entry criteria for this will be the HLD document. And
the exit criteria will the program
specification and unit test plan (LLD).
Development Phase
This is the phase where actually coding starts. After the
preparation of HLD and LLD, the
developers know what is their role and according to the
specifications they develop the project.
This stage produces the source code, executables, and
database. The output of this phase is the
subject to subsequent testing and validation.
And we should also verify these activities:
• Determine adequacy of implementation.
• Generate structural and functional test data for programs.
The inputs for this phase are the physical database design
document, project standards, program
specification, unit test plan, program skeletons, and
utilities tools. The output will be test data,
source data, executables, and code reviews.
Testing phase
This phase is intended to find defects that can be exposed
only by testing the entire system. Static
Testing or Dynamic Testing can do this. Static testing means
testing the product, which is not
executing, we do it by examining and conducting the reviews.
Dynamic testing is what you would
normally think of testing. We test the executing part of the
project.
A series of different tests are done to verify that all
system elements have been properly integrated
and the system performs all its functions.
Note that the system test planning can occur before coding
is completed. Indeed, it is often done in
parallel with coding. The input for this is requirements
specification document, and the output are
the system test plan and test result.
Implementation phase or the Acceptance phase
This phase includes two basic tasks:
• Getting the software accepted
• Installing the software at the customer site.
Acceptance consist of formal testing conducted by the
customer according to the
Acceptance test plan prepared earlier and analysis of the
test results to determine whether the
system satisfies its acceptance criteria. When the result of
the analysis satisfies the acceptance
criteria, the user accepts the software.
Maintenance phase
This phase is for all modifications, which is not meeting
the customer requirements or any thing to
append to the present system. All types of corrections for
the project or product take place in this
phase. The cost of risk will be very high in this phase.
This is the last phase of software
development life cycle. The input to this will be project to
be corrected and the output will be
modified version of the project.

White Box Testing

Structural testing or White box testing

Structural tests verify the structure of the software itself
and require complete access to the source
code. This is known as ‘white box’ testing because you see
into the internal workings of the code.
White-box tests make sure that the software structure itself
contributes to proper and efficient
program execution. Complicated loop structures, common data
areas, 100,000 lines of spaghetti
code and nests of ifs are evil. Well-designed control
structures, sub-routines and reusable
modular programs are good.
White-box testing strength is also its weakness. The code
needs to be examined by highly skilled
technicians. That means that tools and skills are highly
specialized to the particular language and
environment. Also, large or distributed system execution
goes beyond one program, so a correct
procedure might call another program that provides bad data.
In large systems, it is the execution
path as defined by the program calls, their input and output
and the structure of common files that
is important. This gets into a hybrid kind of testing that
is often employed in intermediate or
integration stages of testing.

Block Box Testing

Functional tests examine the behavior of software as
evidenced by its outputs without reference to
internal functions. Hence it is also called ‘black box’
testing. If the program consistently provides
the desired features with acceptable performance, then
specific source code features are
irrelevant. It's a pragmatic and down-to-earth assessment of
software.

Functional or Black box tests better address the modern
programming paradigm. As objectoriented
programming, automatic code generation and code re-use
becomes more prevalent,
analysis of source code itself becomes less important and
functional tests become more important.
Black box tests also better attack the quality target. Since
only the people paying for an application
can determine if it meets their needs, it is an advantage to
create the quality criteria from this point
of view from the beginning.
Black box tests have a basis in the scientific method. Like
the process of science, Black box tests
must have a hypothesis (specifications), a defined method or
procedure (test plan), reproducible
components (test data), and a standard notation to record
the results. One can re-run black box
tests after a change to make sure the change only produced
intended results with no inadvertent
effects.

The project quality management knowledge area is comprised
of the set of processes that ensure
the result of a project meets the needs for which the
project was executed. Processes such as
quality planning, assurance, and control are included in
this area. Each process has a set of input
and a set of output. Each process also has a set of tools
and techniques that are used to turn input
into output.
Definition of Quality:
• Quality is the totality of features and characteristics of
a product or service that bare on its
ability to satisfy stated or implied needs.
Or
• Quality is defined as meeting the customer’s requirement
for the first time and for every
time. This is much more that absence of defects which allows
us to meet the requirements.
Some goals of quality programs include:
• Fitness for use. (Is the product or service capable of
being used?)
• Fitness for purpose. (Does the product or service meet its
intended
purpose?)
• Customer satisfaction. (Does the product or service meet
the customer's
expectations?)

Quality Management Processes
Quality Planning:
The process of identifying which quality standards is
relevant to the project and determining
how to satisfy them.
• Input includes: Quality policy, scope statement, product
description, standards and
regulations, and other process Output.
• Methods used: benefit / cost analysis, benchmarking,
flowcharting, and design of
experiments.
• Output includes: Quality Management Plan, operational
definitions, checklists, and Input
to other processes.
Quality Assurance
The process of evaluating overall projects performance on a
regular basis to provide
confidence that the project will satisfy the relevant
quality standards.
• Input includes: Quality Management Plan, results of
quality control measurements, and
operational definitions.
• Methods used: quality planning tools and techniques and
quality audits.
• Output includes: quality improvement.
Quality Control
The process of monitoring specific project results to
determine if they comply with relevant
quality standards and identifying ways to eliminate causes
of unsatisfactory performance.
• Input includes: work results, Quality Management Plan,
operational definitions, and
checklists.
• Methods used include: inspection, control charts, Pareto
charts, statistical sampling,
flow charting, and trend analysis.
• Output includes: quality improvements, acceptance
decisions, rework, completed
checklists, and process adjustments.

How do we prepare weekly and monthly status-report as QA?

4 Answers  

---

what are the key components of test plan document?

16 Answers   Tech Mahindra,

---

what are the fields in traceablity matixes.

8 Answers   HCL,

---

what will you do when your reported defect rejected?

10 Answers   TCS,

---

differentiate test strategy and test plan?

5 Answers  

---

---

What is reporting hiearchy in testing? Who report to whop and complete hiearchy including developers

6 Answers   ABC,

---

if there are 10 step in test cases while executing if their is mismatch at step 5 what is status of test case ? pass or fail or anything else? if require tab is not available then what's the status of test case?

2 Answers  

---

Hi Friends, Can any one tell me how the Risks for the basic web page testing in the Test Plan, as i am writting my first test plan. It will be greatfull if any one answer me as soon as possible

3 Answers  

---

what type of testing process is going on your company?

8 Answers   Accenture, CTS, ISPG, Ordain Solutions,

---

What is test strategy..?

2 Answers  

---

what is your company testcase format?

18 Answers   Infosys, MasterMind, Sinsoft,

---

What Methodology is followed in your testing?

19 Answers   ADP,

---