Stqa Assignment-2: Explain QA Activities in Waterfall Process With The Help of Neat Diagram
Stqa Assignment-2: Explain QA Activities in Waterfall Process With The Help of Neat Diagram
Stqa Assignment-2: Explain QA Activities in Waterfall Process With The Help of Neat Diagram
2. Compare validation and verification. Explain validation and verification activities associated with
the V-Model
Verification Validation
1.Verification is a static practice of verifying 1.Validation is a dynamic mechanism of
documents, design, code and program. validating and testing the actual product.
2.It does not involve executing the code. 2. It always involves executing the code.
3.It is human based checking of documents and
3.It is computer based execution of program.
files.
4.Validation uses methods like black box
4.Verification uses methods like inspections,
(functional) testing, gray box testing, and white
reviews, walkthroughs, and Desk-checking etc. box (structural) testing etc.
5.Verification is to check whether the software 5.Validationis to check whether software meets
conforms to specifications. the customer expectations and requirements.
6.It can catch errors that validation cannot catch. 6.It can catch errors that verification cannot
It is low level exercise. catch. It is High Level Exercise.
9. It generally comes first-done before 9.It generally follows after verification. validation.
System Design
Once you have the clear and detailed product requirements, it is time to design the complete system.
The system design will have the understanding and detailing the complete hardware and
communication setup for the product under development. The system test plan is developed based on
the system design. Doing this at an earlier stage leaves more time for the actual test execution later.
Architectural Design
Architectural specifications are understood and designed in this phase. Usually more than one
technical approach is proposed and based on the technical and financial feasibility the final decision
is taken. The system design is broken down further into modules taking up different functionality.
This is also referred to as High Level Design (HLD).
Module Design
In this phase, the detailed internal design for all the system modules is specified, referred to as Low
Level Design (LLD). It is important that the design is compatible with the other modules in the system
architecture and the other external systems. The unit tests are an essential part of any development
process and helps eliminate the maximum faults and errors at a very early stage. These unit tests can
be designed at this stage based on the internal module designs.
Coding Phase
The actual coding of the system modules designed in the design phase is taken up in the Coding
phase. The best suitable programming language is decided based on the system and architectural
requirements.
The coding is performed based on the coding guidelines and standards. The code goes through
numerous code reviews and is optimized for best performance before the final build is checked into
the repository.
Validation Phases
Unit Testing
Unit tests designed in the module design phase are executed on the code during this validation phase.
Unit testing is the testing at code level and helps eliminate bugs at an early stage, though all defects
cannot be uncovered by unit testing.
Integration Testing
Integration testing is associated with the architectural design phase. Integration tests are performed
to test the coexistence and communication of the internal modules within the system.
System Testing
System testing is directly associated with the system design phase. System tests check the entire
system functionality and the communication of the system under development with external systems.
Most of the software and hardware compatibility issues can be uncovered during this system test
execution. Acceptance Testing
Acceptance testing is associated with the business requirement analysis phase and involves testing
the product in user environment. Acceptance tests uncover the compatibility issues with the other
systems available in the user environment. It also discovers the non-functional issues such as load
and performance defects in the actual user environment.
1. Pre-QA activities: Quality planning. These are the activities that should be carried out before
carrying out the regular QA activities. There are two major types of pre-QA activities in quality
planning, including: (a) Set specific quality goals. (b) Form an overall QA strategy, which includes
two sub-activities: i. Select appropriate QA activities to perform. ii. Choose appropriate quality
measurements and models to provide feedback, quality assessment and improvement.
2. In-QA activities: Executing planned QA activities and handling discovered defects. In addition
to performing selected QA activities, an important part of this normal execution is to deal with the
discovered problems. These activities were described in the previous two chapters.
3. Post-QA activities: Quality measurement, assessment and improvement These are the activities
that are carried out after normal QA activities have started but not as part of these normal activities.
The primary purpose of these activities is to provide quality assessment and feedback so that
various management decisions can be made and possible quality improvement initiatives can be
carried out .
5. List and explain major activities involved in quality assessment and improvement.
-Measurement: Besides defect measurements collected during defect handling, which is typically
carried out as part of the normal QA activities, various other measurements are typically needed for
us to track the QA activities as well as for project management and various other purposes. These
measurements provide the data input to subsequent analysis and modeling activities that provide
feedback and useful information to manage software project and quality.
-Analysis and modeling: These activities analyze measurement data from software projects and fit
them to analytical models that provide quantitative assessment of selected quality characteristics or
1. Setting quality goals by matching customer’s quality expectations with what can be
economicallyachieved by the software development organizations in the following sub-steps: (a)
Identify quality views and attributes meaningful to target customers and users. (b) Select direct
quality measures that can be used to measure the selected quality (c) Quantify these quality
measures to set quality goals while considering the marattributes from customer’s perspective. ket
environment and the cost of achieving different quality goals.
2. In forming a QA strategy, we need to plan for its two basic elements: (a) Map the above quality
views, attributes, and quantitative goals to select a specific set of QA alternatives. (b) Map the
above external direct quality measures into internal indirect ones via selected quality models. This
step selects indirect quality measures as well as usable models for quality assessment and analysis.
-Testplanning andpreparation, which set the goals for testing, select an overall testing strategy, and
prepare specific test cases and the general test procedure.
-Test execution and related activities, which also include related observation and measurement of
product behavior.
-Analysis and follow-up, which include result checking and analysis to determine if a failure has
been observed, and if so, follow-up activities are initiated and monitored to ensure removal of the
underlying causes, or faults, that led to the observed failures in the first place.
Sr
.
Key Black Box Testing White Box Testing
N
o.
1 Definitio
On other
Black box testing is the testing hand White box testing is
model
n
in which the tester do not the
havetesting
the model in which tester is
knowledge about the internal of internal implementation of
aware
the application
implementation of the application and and does the testing
testing performed by testeronisthe basis of that.
at very
high level that focuses on the
behaviour of the application.
3 Type
On of
Black box testing is the type other hand White box testing is
testing
theexternal
in which testing is based on type of testing in which internal
expectations as internal behaviour ofis known to the tester
behaviour
the application is not madeand hence he
provided to can test accordingly.
the tester.
5 Expectati
Expectation from Black box testing
While userisdoes White box testing
on
that it makes a clear visionwith
about
thethe
expectation that this
functionality of the application with
testing will also check the quality
external input parameters and
withperformance
its of the application
report. by executing the code of the
application.
10. Explain steps involved in CBT model construction and test preparation.
-Defining the model: These models are often represented by some graphs, with individual nodes
representing the basic model elements and links representing the interconnections. Some additional
information may be attached to the graph as link or node properties (commonly referred to as
weights in graph theory).
-Checking individual model elements to make sure the individual elements, such as links, nodes,
and related properties, have been tested individually, typically in isolation, prior to testing using the
whole model. This step also represents the self-checking of the model, to make sure that the model
captures what is to be tested.
-Dejning coverage criteria: Besides covering the basic model elements above, some other coverage
criteria are typically used to cover the overall execution and interactions. For example, with the
partition-based testing, we might want to cover the boundaries in addition to individual partitions;
and for FSM-based testing, we might want to cover state transition sequences and execution paths. -
Derive test cases: Once the coverage criteria are defined, we can design our test cases to achieve
them. The test cases need to be sensitized, that is, with its input values selected to realize specific
tests, anticipated results defined, and ways to check the outcomes planned ahead of time