Software Quality Assurance: Time: 2 HRS.)

T.Y. B.Sc. (IT) : Sem.
VI
Software Quality Assurance
Time : 2½ Hrs.] Prelim Question Paper Solution [Marks : 75
Q.1Attempt any THREE question of the following : [15]

Q.1(a) Explain Quality management using statistical control process approach. [5]
Ans.: (i) Dr. Joseph Juran is a pioneer of statistical quality control with a definition of improvement
cycle through (DMMCI) i.e. ‘Define’, ’Measure’, ’Monitor’, ’Control’, ’Improve’.
(ii) One must understand the interrelationships among the customers, suppliers and processes used
in development, testing etc. and establish quality management based on metrics program.
(iii) Following are three parts of the approach, namely :

(1) Quality planning at all levels : Quality planning happens at two levels :
 Organization Level : It must be in the form of policy definition and strategic quality
plans on the basis of vision, missions set by senior management.
 Unit Level : Quality planning at unit level must be done by the people responsible for
managing the unit. Project plan and quality plan at unit level must be consistent with the
strategic quality plans at organization level.
(2) Quality control :
 Quality control process examines the present product at various levels with the defined
standards so that an organization may appraise the outcome of the processes.
 It must measure the deviations with respect to the number of achievements planned in
quality planning to reduce those deviations to minimum.
(3) Quality improvement :
 Improvement processes attempts to continuously improve the quality of the process
used for producing products.
 There is no end to quality improvements and it needs or take newer challenges again and
again.
Q.1(b) State and explain the TQM principles [5]

Ans.: TQM principles
1. Develop constancy of purpose of definition and deployment of various initiatives
Management must create constancy of purpose for products and processes, allocating
resources adequately to provide for long term as well as short term needs. The processes
followed during entire lifecycle of product development from requirement gathering to final
delivery must be consistent with each other over a larger horizon.
2. Adapting to new philosophy of managing people / stakeholders by building confidence and
relationships
Management must adapt to the new philosophies of doing work and getting work done from its
people and suppliers.
3. Declare freedom from mass inspection of incoming/produced output
There must be an approach for elimination of mass inspection followed by cost of failure as the
way to achieve quality of products because mass inspection results into huge cost overrun and
product produced is of inferior quality.
4. Stop awarding of lowest price tag contracts to suppliers
Organizations must end the practice of comparing unit purchase price as criteria for awarding
contracts. Vendor selection must be done on the basis of total cost including price, rejections,
etc .Aim of vendor selection is to minimize total cost, not merely initial cost of purchasing.
5. Improve every process used for development and testing of product.
Improve every process of planning, production and service to the customer and other support
processes constantly.
-1-
Vidyalankar : T.Y. B.Sc. (IT)  CL
6. Institutionalize training across the organization for all the people

An organization must include modern methods of training which may include on-the-job-training,
classroom training, self-study etc. for all people to make better use of their capabilities. Skill
levels of people can be enhanced to make them suitable for better performance by planning
different training programs.
7. Institutionalize leadership throughout organization at each level
An organization must adopt and include leadership at all levels with the aim of helping people to
do their jobs in a better way. Their focus must shift from number of work items to be
produced to quality of output.
8. Drive out fear of failure from employees
An organization must encourage effective two-way communication and other means to drive out
fear of failure from minds of all employees. Employees can work effectively and more
productively to achieve better quality output when there is no fear of failure
9. Break down barriers between functions/departments
Physical as well as psychological barriers between departments and staff areas must be broken
down to create a force of cohesion. People start performing as a team and there in synergy of
group activities
10. Eliminate exhortations by numbers, goals, targets
Eliminate use of slogans , posters and exhortations of the work force, demanding ‘Zero
Defects’ and new levels of productivity ,without providing methods and guidance about how to
achieve it
11. Eliminate arbitrary numerical targets which are not supported by processes
Eliminate quotas for work force and numerical goals for managers to be achieved. Substitute
the quotas with mentoring and support to people, and helpful leadership in order to achieve
continual improvement in quality and productivity of processes.
12. Permit pride of workmanship for employees
People must feel proud of the work that they are doing, and know how they are contributing
to organizational level. This means replacing ‘management by objective’ to ‘management by
fact’
13. Encourage education of new skills and techniques
Arrange a rigorous program of education and training for people working in different areas and
encourage self-improvement programs for everyone. They need to accept new challenges
14. Top management commitment and action to improve continually
Clearly define top management’s commitment to ever-improving quality and productivity and
their obligation to implement quality principles throughout the organization.
Q.1(c) Explain the Continual/continuous improvement cycle (PDCA) [5]

Ans.: (i) Continual (Continuous) improvement cycle is based on systematic sequence of Plan-Do-Check-
Act activities representing a never ending cycle of improvements. It was initially implemented
in agriculture them later in electronic industry and now it is famous in all industries.
(ii) PDCA improvement cycle can be thought of as a wheel of improvement continually(continuously)
rolling up the problem-solving and achieving better and better results for organization at each
iteration.
(iii) Following are the stages of PDCA cycle explained with the help of a diagram
Fig.: Continual improvement cycle (PDCA cycle)
-2-
Prelim Question Paper Solution
(iv) Plan:
 Planning includes answering all questions like who, when, what, why, where, how etc. about
various activities and setting expectations.
 Expected results must be defined in quantitative terms an actions must be planned to
achieve answers to these questions.
 Baseline studies (i.e. where one is standing and vision defines where one wishes to be) are
important for planning.
(v) Do:
 An organization must work in the direction set by the plan devised in earlier phase for
improvement.
 Actual execution of a plan can determine whether the results as expected are achieved or
not.
 ‘Do’ process need inputs like resources, hardware, software, training etc. for execution of a
plan.
(vi) Check:
 An organization must compare the actual outcome of ‘Do’ stage with reference or expected
results which are planned outcomes.
 Expected and actual results must be in numerical terms, and compared at some periodicity
as defined in the plan.
(vii) Act:
 If any deviations are observed in actual outcome with respect to planned results, the
organization may need to decide actions to correct the situation.
 One may have to initiate corrective or preventive actions as per the outcome of ‘Check’
stage.
 When expected results and actual results match with given degree of variation, one can
consider that the plan is going in the right direction.
Q.1(d) Difference between Continual and Continuous improvement cycle. [5]

Ans.:
Sr. Continuous Improvement Continual Improvement
No.
(i) It is dynamic in nature. The changes are It is dynamic as well as static change
done at every stage and every time to management. The changes are done, absorbed,
improve further. baseliner and sustained before taking next
step of improvements
(ii) Continuously striving for excellence gives Periodic improvement followed by stabilization
a continuous improvement process sustenance represents continual
improvement.
(iii) It has a thrust on continuous refinement Stabilization of processes at each iteration of
of the processes to eliminate waste improvement where waste is removed in stages
continuously
(iv) It has high dependence on people having Less dependence on people and more on
innovative skills tending towards innovation process
inventions
(v) Environment is continuously changed Changes in environment are followed by
stabilization
(vi) Sometimes it creates a turbulence in an It may be better suited than continuous
organization ,if people are not able to improvement. It gives a chance to settle the
digest continuous change change before next change is introduced.
-3-
Q.1(e) Explain generic quality management system structure. [5]

Ans.: Every organization has a different quality management structure depending upon its need and
circumstances. General view of quality management is defined below in a diagram :
Fig.: Quality Management System of a typical organization.
Following are the three main tiers of quality management system structure :
1st TIER – Quality Policy
 Quality policy sets the wish, intent and direction by the management about how activities will
be conducted by the organization.
 Since management is the strongest driving force in an organization, its intents are most important
 It is a basic framework on which the quality temple rests.
2nd TIER – Quality Objectives

 Quality objectives are the measurements established by the management to define progress
and achievements in a numerical way.
 An improvement in quality must be demonstrated by improvement in achievements of quality
factors (test factors) in numerical terms as expected by the management.
 The achievements of these objectives must be compared with planned levels expected and
results and deviations must be acted upon.
3rd TIER – Quality Manual

 Quality manual also termed as policy manual is establishes and publishes by the management of
the organization.
 It sets a framework for other process definitions and is a foundation of quality planning at
organization level.
Q.1(f) Explain software quality management methods. [5]

Ans.: (i) Quality management involves management of all inputs and processing to the processes defined
so that the output from the process is a per defined quality criteria. There are three levels of
handling problems, namely.
(ii) Correction:
 Correction is the condition where defects found in the product or service are immediately
sorted and fixed.
 This is a natural phenomenon which occurs when a tester defines any problem found during
testing.
 This is mainly quality control approach.
(iii) Corrective Actions:
 A situation where the root cause analysis of the defects is done and actions are initiated to
remove the root causes so that the same defect does not recur in future is termed as
corrective action.
 It is a responsibility of operations management group. Generally, project leads are given the
responsibilities of initiating corrective actions.
 This is a quality assurance approach.
-4-
(iv) Preventive Actions:

 Preventive action means that there are potential weak areas where defect has not been
found till that point, but there exists a probability of finding the defect.
 Generally identification and initiation of preventive actions are a responsibility of senior
management. Project managers are given this responsibility.
 This is a quality management approach where an organization takes preventive action to
ensure there is no defect in the first place.
Q.2 Attempt any THREE question of the following : [15]

Q.2(a) Explain the concept of Mutation testing. [5]
Ans.:  Mutation testing is used to check the capability of test program and test cases to find defects.
Test cases are designed and executed to find defects.
 If test cases are not capable of finding defects, it is a loss for an organization. This is also
termed as test case efficiency.
 A program is written and set of test cases are designed and executed on the program. The test
team may find out few defects. The original program and some defects are added deliberately.
This is called ‘mutant of the first program’ and the process is termed ‘mutation’. It is subjected
to the same test case execution again. The test cases must be able to find the defects
introduced deliberately in the mutant.
Suppose, X = Defects deliberately introduced by development
Y = Defects found by test cases in original program
Z = Defects found by test cases in mutant.
The ratio of (Z-Y)/X will give the test case efficiency.
 Defects found by test cases in mutant. Defects found by test cases in original program/
Defects deliberately introduced by development.
Q.2(b) Explain basic principles of testing. [5]

Ans.: The basic principles on which testing is based are given below:
 Define the expected output or result for each test case executed, to understand if expected
and actual output matches or not. Mismatches may indicate possible defects. Defects may be in
product or test cases or test plan.
 Developers must not test their own programs. No defects would be found in such kind of
testing as approach-related defects will we difficult to find.
 Inspect the results of each test completely and carefully. It would help in root cause analysis
and can be used to find weak processes. This will help in building processes rightly and
improving their capability.
 Include test cases for invalid or unexpected conditions which are feasible during production.
Testers need to protect the users from any unreasonable failure.
 Test the program to see if it does what is no supposed to do as well as what it is supposed to do.
 Reusability of test case is important for regression. Test cases must be used repetitively so
that they remain applicable. Test data may be changed in different iterations.
 Do not plan tests assuming no errors will be found. There must be targeted number of defects
for testing.
 The probability of locating more errors in any module is directly proportional to the number of
errors already found in that module.
Q.2(c) An application consists of 55 defects introduced deliberately by the development [5]

team. The test team finds total 45 defects including 5 defects which were not
introduced by the development team. Find the test team efficiency
Ans.: Given: Let X = No. of defects deliberately introduced by development team=55
Y = Total defects found by testing team= 45
Z = Defects found by testing team but not belonging to the defects deliberately introduced by
development.= 5
-5-
Formula:
Test Team efficiency(%) = Total defects found by testing team - Defects found by testing team
but not belonging to the defects deliberately introduced by development / No. of defects
deliberately introduced by development team
Solution:
Test Team efficiency(%) = (Y-Z)/X = 45-5/55=40/55
= 0.7272
0.7272 x 100
Test case efficiency(%) =72.72%
Q.2(d) Difference between black box testing and white box testing [5]
Ans.:
Sr.No. Black box testing White box testing
(i) Black box Testing involves testing White box testing is done on the basis
system/components considering inputs, of internal structures of software as
outputs and general functionalities as defined by designs, coding standards and
defined in requirement specifications. guidelines.
(ii) It is independent of platform, database It is a verification technique where one
and system to make sure that the can ensure that software is built
system works as per requirements correctly.
defined as well as implied ones.
It represents user scenario and actual
user interactions.
(iii) This is the only method to prove that It can ensure that defined processes,
software does what it is supposed to do procedures methods of development
and it does not do something which can have really been followed during
cause a problem to user software testing.
(iv) Some types of testing can be done only It can help in giving early warnings.
using black box methodology like
performance and security testing.
(v) Some logical errors in coding can be It does not ensure that user
missed in black box testing as black box requirements are met correctly.
testing efforts are driven by
requirements and not by design.
Q.2(e) What is a test strategy? List and explain different steps involved in developing a test [5]
strategy.
Ans.: Test strategy defines the action part of test policy. It defines the ways and means to achieve the
test policy.
Generally, there is a single test policy at organization level for product organizations while test
strategy may differ from product to product, customer to customer and time to time.
Following are some examples of test strategy may be as follows :
 Definition of coverage like requirement coverage or functional coverage etc.
 Level of testing from requirements gathering to acceptance phase.
 How much manual testing and automated testing required?
 Ratio of developers to testers.
The process of developing test strategy goes through the following stages :
1. Select and rank Test factors for the given application.
The test team must identify critical success factors/quality factors/ test factors for the
product under testing. These factors must be analyzed and prioritized/ ranked.
-6-
2. Identify System Development phases and related test factors.

The importance of test factors as per system development life cycle phase must be considered
to change the test approach accordingly.
3. Identify Risk associated with test factor in case not achieved.

Trade-offs may lead to few risks of development and testing the software. Customer must be
involved in doing trade-offs of test factors and the possible risks of not selecting proper test
factor.
4. Identify Phase in which risks of not meeting a test factor need to be addressed.
The risks may be tackled in different ways during development life cycle phases. As the phase
is over, one needs to assess the actual impact of the risks and effectiveness of devised counter
measures for the same.
Q.2(f) Which skills are expected by a good tester ? [5]

Ans.: Following are some of the testing skills expected by a good tester :
 Concepts of testing : A tester must understand methods , processes and concepts of testing.
He/she must be capable of test planning, designing test scenario , writing test cases and
defining test data.
 Levels of testing : Testers are involved in each phase of software development right from
proposal and contract , followed by requirement till acceptance testing. Testers must ensure
that each phase is passed successfully.
 Techniques for Validation and Verification : Techniques of verification/validation must be

understood and facilitated by testers to the development team, customer and management.
 Knowledge of testing standards : Testing standards are defined by software quality team ,or
also there are international standards which needs to be understood by tester and apply them
effectively.
 Risk assessment and management : Test cases and test data must be defined by testers to
minimize risks to final users in production environment.
 Developing Test plan : Test plan development is generally done by test managers or test leads
while implementation of these plans are done by testers.
 Defining acceptance criteria: Testers need to define acceptance criteria for the phases and
iterations of testing.
 Execution of Test Plan: Testers are given the responsibility of executing a test plan. It
includes defining test cases, test scenarios, and their execution. They must be able to perform
regression testing when planned.
Q.3Attempt any THREE question of the following : [15]

Q.3(a) Consider a program classifying a triangle problem. Input : All three sides of a triangle [5]
x, y and z (positive integers) with range (0,200]. The possible outputs being not a
triangle, isosceles triangle and equilateral triangle. Design Normal Boundary value test
cases and calculate the number of test cases.
Ans.: Triangle Problem : Consider a program to classify a triangle, the lower bounds of the ranges are all
1. We arbitrarily take 200 as an upper bound. The inputs are the three sides of triangle positive
integers and output can be isosceles triangle, equilateral triangle or not a triangle. Design test
cases using normal boundary value testing and worst case boundary value testing.
(a) Normal Boundary Value Testing :
For each side of triangle, the test values are {1, 2, 100, 199, 200} since 1 is min, 2 is min+, 100 is
nominal, 199 is max- and 200 is max.
-7-
Table 1 : Normal Boundary Value Testing Test Cases.

Case a b c Expected Output
1 100 100 1 Isosceles
3 100 100 100 Equilateral
4 100 100 199 Isosceles
5 100 100 200 Not a triangle
9 100 199 100 Isosceles
14 199 100 100 Isosceles
Notice that test cases 3, 8, and 13 are identical; two should be deleted. Further, there is no
test case for scalene triangles.
(b) Worst Case Boundary Value Testing Test Cases :
The cross-product of test values will have 125 test cases (some of which will be repeated.
The following Table only lists the first 25 worst-case boundary value test cases for the
triangle problem.
Table : Worst Case -Boundary Value Testing Test Cases.
Case a b c Expected Output
1 1 1 1 Equilateral
7 1 2 2 Isosceles
-8-
Q.3(b) Explain the concept of decision table based testing with the help of an example. [5]
Ans.:  Decision table ideal for describing situations in which a number of combinations of actions are
taken under varying sets of conditions.
 A decision table has four portions the condition stub, the condition entries, the action stub,
and the action entries.
 A column in the entry portion is a rule. Rules indicate which actions, if any, are taken for the
circumstances indicated in the condition portion of the rule. In the decision table below, when
conditions c1, c2, and c3 are all true, actions a1 and a2 occur. When c1 and c2 are both true and
c3 is false, then actions a1 and a3 occur.
 The entry for c3 in the rule where c1 is true and c2 is false is called a “don’t care” entry. The
don’t care entry has two major interpretations: the condition is irrelevant, or the condition
does not apply.
 This structure guarantees that we consider every possible combination of condition values.
 This completeness property of a decision table guarantees a form of complete testing.
 Decision tables in which all the conditions are binary are called Limited Entry Decision Tables
(LETDs).
Table : Decision table diagram.

Stub Rule 1 Rule 2 Rules 3, 4 Rule 5 Rule 6 Rules 7, 8
c1 T T T F F F
c2 T T F T T F
c3 T F  T F 
a1 X X X
a2 X X
a3 X X
a4 X X
Q.3(c) Describe Basis path testing method in detail [5]

Ans.:  The basis path testing is testing that defines test cases based on the flows or logical path that
can be taken through the program. In software engineering, Basis path testing involves
execution of all possible blocks in a program and achieves maximum path coverage with the
least number of test cases. It is a hybrid of branch testing and path testing methods.
 The objective behind basis path in software testing is that it defines the number of
independent paths, thus the number of test cases needed can be defined explicitly (maximizes
the coverage of each test case).
 Here we will take a simple example, to get a better 1
idea what is basis path testing include :
2
 In the example, we can see there are few conditional 1. If A = 50
statements that is executed depending on what 2. THEN IF B>C
3 4
condition it suffice. Here there are 3 paths or 3. THEN A=B
condition that need to be tested to get the output, 5 4. ELSE A=C
Path 1: 1,2,3,5,6, 7 5. ENDIF
Path 2: 1,2,4,5,6, 7 6 6. ENDIF
Path 3: 1, 6, 7
7
Q.3(d) Explain any two types of improved equivalence class testing. [5]
Ans.: Following two types of equivalence class testing are presented here :
(i) Weak Normal Equivalence Class Testing.
(ii) Strong Normal Equivalence Class Testing.
-9-
(i) Weak Normal Equivalence Class Testing :

The word ‘weak’ means ‘single fault assumption’. This type of
testing is accomplished by using one variable from each
equivalence class in a test case. We would, thus, end up with the
weak equivalence class test cases as shown in the figure.
Each dot in above graph indicates a test data. From each class
we have one dot meaning that there is one representative
element of each test case. In fact, we will have, always, the
same number of weak equivalence class test cases as the classes
in the partition.
(ii) Strong Normal Equivalence Class Testing :

This type of testing is based on the multiple fault assumption
theory. So, now we need test cases from each element of the
Cartesian product of the equivalence classes, as shown in the
figure.
Just like we have truth tables in digital logic, we have

similarities between these truth tables and our pattern of test
cases. The Cartesian product guarantees that we have a notion
of “completeness” in following two ways :
 We cover all equivalence classes
 We have one of each possible combination of inputs.
Q.3(e) Explain cause effect graphing technique. [5]

Ans.:  Cause-Effect Graphing is a technique where causes are the input conditions and effects are the
results of those input conditions.
 The Cause-Effect graph technique restates the requirements specification in terms of the
logical relationship between the input and output conditions. Since it is logical, it is obvious to
use Boolean operators like AND, OR and NOT.
 Cause-and-effect graphs shows unit inputs on the left side of a drawing, and using AND, OR,
and NOT “gates” to express the flow of data across stages of unit.
 The following Figure shows the basic cause-and-effect graph structures :
Example: Triangle problem

The causes designated by letter C are as under
C1 : Side x is less than sum of y and z
C2 : Side y is less than sum of x and z
C3 : Side z is less then sum of x and y
C4 : Side x is equal to side y
C5 : Side x is equal to side z
C6 : Side y is equal to side z
Fig.: Cause-Effect diagram for

triangle
- 10 -
The effects designated by letter e are as under

e1 : Not a triangle
e2 : Scalene triangle
e3 : Isosceles triangle.
e4 : Equilateral triangle
e5 : Impossible
Q.3(f) Define du and dc path. Explain Define / Use testing in data flow testing. [5]
Ans.:  Definition-use (du) paths: A path in the set of all paths in P(G) is a du-path for some variable v
(in the set V of all variables in the program) if and only if there exist DEF(v, m) and USE(v, n)
nodes such that m is the first node of the path, and n is the last node.
A du-path in PATHS(P)
where the initial node of the path is the only defining node of v (in the
DEF
USF
Fig. : An example of a DU-path that is also definition-
 Definition-clear (dc) paths: A path in the set of all paths in P(G) is a dc-path for some variable
v (in the set V of all variables in the program) if and only if it is a du-path and the initial node
of the path is the only defining node of v in the path.
Define/Use testing uses paths of the program graph, linked to particular nodes of the graph that
relate to variables, to generate test cases. The term “Define/Use” refers to the two main aspects
of a variable: it is either defined (a value is assigned to it) or used (the value assigned to the
variable is used elsewhere – maybe when defining another variable). Define/use testing was first
formalised by Sandra Rapps and Elaine Weyuker in the early 1980s.
Define/use testing is meant for use with structured programs. The pro-gram is referred to as P,
and its graph as G(P). The program graph has single entry and exit nodes, and there are no edges
from a node to itself. The set of variables within the program is called V, and the set of all the
paths within the program graph P(G) is PATHS(P).
Within the context of define/use testing, with respect to variables there are two types of nodes:
defining nodes and usage nodes. The nodes are defined as follows:
 Defining nodes, referred to as DEF(v, n): Node n in the program graph of P is a defining node
of a variable v in the set V if and only if at n, v is defined. For example, with respect to a
variable x, nodes containing statements such as “input x” and “x = 2” would both be defining
nodes.
 Usage nodes, referred to as USE(v, n): Node n in the program graph of P is a usage node of a
variable v in the set V if and only if at n, v is used. For example, with respect to a variable x,
nodes containing statements such as “print x” and “a = 2 + x” would both be usage nodes.
Usage nodes can be split into a number of types, depending on how the variable is used. For
instance, a variable may be used when assigning a value to another variable, or it may be used when
making a decision that will affect the flow of control of the program.
The two major types of usage node are:

 P-use: predicate use – the variable is used when making a decision
(e.g. if b > 6)
 C-use: computation use – the variable is used in a computation (for example, b = 3 + d – with
respect to the variable d).
- 11 -
There are also three other types of usage node, which are all, in
effect, subclasses of the C-use type:
 O-use: output use – the value of the variable is output to
the external environment (for instance, the screen or a DEF DEF
printer).
 L-use: location use – the value of the variable is used, for USF
instance, to determine which position of an array is used Fig. : An example of a DU-path.
(e.g. a[b]).
 I-use: iteration use – the value of the variable is used to
control the number of iterations made by a loop (for
example: for (int i = 0; i <= 10; i++)).
Looking at the example above in figure 1, for the variable total Price table lists the defining and
usage nodes (the particular instance of the variable being referred to is highlighted in bold text).
Table 1 : The defining and usage nodes for the variable totalPrice.
Node Type Code
4 DEF totalPrice = 0
7 DEF totalPrice = totalPrice + price
7 USE totalPrice = totalPrice + price
10 USE print("Total price: " + totalPrice)
11 USE if(totalPrice > 15.00) then
12 USE discount = (staffDiscount * totalPrice) + 0.50
14 USE discount = staffDiscount * totalPrice
17 USE finalPrice = totalPrice - discount
With these nodes, some useful paths can be generated.

Q.4(a) Explain different levels of acceptance testing and its importance. [5]
Ans.: The acceptance testing is generally done by the users and/ or customers to understand whether
the software satisfies their requirements or not, and to ascertain whether it is fit for use. There
are two (sometimes three) levels of acceptance testing.
 Alpha Testing : Alfa testing represents the testing done by the customer in development
environment in front of the development team. The testing is done at development site with
dummy data, either created by developers or shared by customer. In reality, alpha testing may
be done by testers in front of the customer to show that software is working. It can be used
as a tool for training key users on the application. Any major problems in terms of requirement
understanding, functioning of software, etc. can be cleared during alpha testing before
software is formally delivered. This is also termed as ‘dry run’ by some people.
 Beta Testing : Beta testing represents a business pilot where testing is actually conducted by
customer in production / semi  production environment. Tester/ developers may be appointed
to help the customer in testing the application, and recording the problems, if any. Beta testing
is extensively used as parallel testing to give confidence to the users that the software really
works as per established existing system at customer’s place.
 Gamma Testing : Gamma testing is used for limited liability testing at selected places. Gamma
testing is generally done by the product development organization that wishes to have limited
market demonstration and piloting of an application in the market. The application is given to
few people for using it in production, environment, and feedback is obtained from them about
the features incorporated as well as something missing or wrongly interpreted.
- 12 -
Q.4(b) Difference between verification and validation methods. [5]

Ans.:
Sr.No. Verification Validation
(i) Verification is an actively where we check Validation is an activity to find whether
the work product with reference to the software achieves whatever is
standards, guidelines and procedure. defined by reqs.
(ii) It is prevention based technique. It is detection based technique.
(iii) It is also termed as static testing as the It is also termed as dynamic testing as
work product undergoes a review. work product is execution.
(iv) It does not involves execution of the It involves execution of the code
code/program. program.
(v) Verification may be based on opinion of Validation is based on facts and is
reviewer and may change from person to generally independent of person.
person.
(vi) It answers question “Are we building the It answers the question “Are use
system right? building the right system?
(vii) Verification techniques involves: Validation techniques involves:
Reviews System testing
Walkthroughs User interfaced testing
Inspection Stress testing
Audits
(viii) Following coverage given by verification Following coverage given by validation
 statement  requirement
 decision  feature
 path  functionality
Q.4(c) Explain walkthrough technique in detail. [5]

Ans.: A walkthrough is characterized by the author of the document under review guiding the
participants through the document and his or her thought processes, to achieve a common
understanding and together feedback. This is especially useful if people from outside the software
discipline are present, who are not used to, or cannot easily understand software development
documents.
Within a walkthrough the author does most of the preparation. The participants, who are selected
from different departments and backgrounds, are not required to do a detailed study of the
documents in advance. Because of the way the meeting is structured, a large number of people can
participate and this larger audience can bring a greater number of diverse viewpoints regarding the
contents of the document being reviewed. If the audience represents a broad crosssection of
skills and disciplines, it can give assurance that no major defects are ‘missed’ in the walk through. A
walkthrough is especially useful for higherlevel documents, such as requirement specifications and
architectural documents.
Key characteristics of walkthroughs are :
 The meeting led by the authors; often a separate scribe is present.
 Scenarios and dry runs may be used to validate the content.
 Separate premeeting preparation for reviewers is optional.
Q.4(d) Explain V model in detail [5]

Ans.: (i) The V Model stands for Validation Model.
(ii) Validation model describes the validation activities associated with different phases of
software development.
Following are activities done at various phases :
 At the requirement phase, there is system testing and acceptance testing, where system
testers and users confirm that requirements have been really met or not.
- 13 -
Requirement Acceptance testing,

analysis system testing
System Interfac
design e testing
Program Integration
design testing
Coding, code review,

unit testing
Fig.: V model for testing (validation model)

 The Design phase covers design specification testing as well as structural testing.
 Programlevel designs are associated with integration testing.
 At code level, unit testing is done to validate individual units, in the program.
Q.4(e) Explain the types of milestone reviews [5]

Ans.: Milestone Review: The Milestone reviews are conducted on periodic basis depending on the
completion of a particular phase or a time frame defined or a milestone achieved a software
development life cycle. Three types of milestone reviews are explained below :
(i) Phase-End Review: Phase-end review is conducted at the end of a development phase under
review such as requirements phase, design phase, coding and testing.
Phaseend reviews are also termed ‘gate reviews’ by some organizations as the gate at phase
end opens only when the output criteria of the phase are achieved by the work product.
Phaseend reviews are used extensively in agile development as one phase completion is marked
by review before the next phase is started.
Review 1 Review 2 Review 3 Review 4
Testing
Coding
Design
Requirement
Time
Fig.: Phase end review
(ii) Periodic Review : When one phase ends in reality another phase may be half way through. In such
cases, we may have review on some periodic basis such as weekly, monthly, quarterly etc. Project
plan must define various periods when review of project related activities will be conducted.
Stakeholders may be required to review the progress and take actions on any impediments.
Month 1 Month 1 Month Month Month Month Month Month
7
Testing
Coding
Design
Requirement
Time
Fig.: Periodic review
- 14 -
Process of InProcess Review :

Following are steps of inprocess reviews are given below :
Work product, and metrics undergoing review are created and submitted to the stakeholders well
in advance.
 Inputs are received from stack holders to initiate various actions.
Risks identified by the project are reviewed and actions may be initiated as required. Risks
which no longer exist may be closed and risks which cannot affect the project are retired.
 Any issue related to any stakeholder is noted and followup actions are initiated.
 Review reports are generated at the end of review which acts as a foundation for the next
review.
Postimplementation Review :
Postmortem reviews/ postimplementation reviews are conducted after the project is over and
delivered to the customer.
Process of PostImplementation Review :

Some of the steps commonly found in postimplementation review are as follows :
 At the end of the project when final deliverables are send to the customer and when final
payments are received, postimplementation reviews are planned.
 All the stakeholders of the project gather at a predefined time.
 All the activities of project are reviewed and different stakeholders are expected to
retrospect their part of work.
 Each and every activity is listed to identify if something went exceptionally good or
exceptionally bad when the project was executed. All projectrelated metrics are reviewed.
Q.4(f) Describe various verification methods based on the parties involved in the methods [5]
Ans.: Following different methods for verification of software work products :
Self-Review :
(i) Self review may not be referred as an official way of review in most of the software
verification descriptions, as it is assumed that everybody does a self-check before giving work
product for further verification.
(ii) It is basically a self-learning and retrospection process.
Peer Review : Peer review is the most informal type of review where an author and a peer are
involved. It is a review done by a peer and review records are maintained. A peer may be a
fellow developer or tester as the case may be. Following are types of peer review
 Online Peer Review (Peerto Peer Review) : In such kind of review, the author and reviewer
meet together and review the work product jointly. Any explanation required by the reviewer
may be provided by the author.
 Offline Peer Review (Peer Review) : In such kind of review, the author informs the reviewer
that the work product is ready for review. The reviewer may review the work product as per
his time availability. The review report is send to the author along with the defects, if any. The
author may decide to accept / reject the review comments or defects identified.
 Superior -Review :
A superior such as team leader or module leader may have to review the artifacts made by his
subordinates to find its suitability to find its suitability with reference to expected outcome.

Q.5 (a) Write a short note on [5]
(i) Big bang testing
(ii) Regression testing
Ans.: (i) Big bang testing : In the Big Bang Testing, all the modules or components are integrated
before and after this everything is tested as a whole. In this type of testing all units or
components are linked at once which result into a complete system. If gives us a complete
system after integration which on which we can start testing.
- 15 -
Advantage :
 Big-Bang Testing is very fast and cheap.
 No need of help of any middle components like stubs, driver on which testing is dependent.
 In Big Bang Testing everything is finished before integration testing starts.
 No need of intermediate builds and efforts is required for the system.
Disadvantage :
 In Big Bang Testing, it is difficult to trace the cause of failures.
 There is very high chances of missing any critical difficult which result in failures of
system in production.
 Covering all the components for integration testing without missing any scenario is very
difficult.
 If any defect is present at the interface of the component, then it is very difficult to find
it at the very initial stage.
(ii) Regression testing:
 Regression testing determines whether the changed components have introduced any error
in unchanged components of the system.
 The maintenance projects may consider it as special testing as regression testing of entire
application may be very costly.
 It can be done at,
 Unit level to identify that changes in the units have not affected its intended purpose,
and other parts of the unit are working properly even after the changes are made in
some parts.
 Module level to identify that the module behaves in a correct way after the individual
units are changed.
 System level to identify that the system is performing all the correct actions that it
was doing previously as well as actions intended by requirements after change is made in
some parts of the system.
 Regression testing is performed where there is high risk that changes in one part of
software may affect unchanged components or system adversely. It is done by rerunning
previously conducted successful tests to ensure that unchanged components function
correctly after the change.
 Following are the development methodologies where regression testing is important :
 Any maintenance activity conducted in a system.
 Iterative development methodology.
 Agile development.
Q.5(b) Difference between stubs and drivers. [5]

Ans.:
Sr. Stubs Drivers
No.
1. Stubs used in Top Down Integration Drivers used in Bottom Up Integration
Testing. Testing.
2. Stubs are used when sub programs Drivers are used when main programs are
are under development. under development.
3. Top most module is tested first. Lowest module is tested first.
4. It can simulate the behaviour of It can simulate the behaviour of upper level
lower level modules that are not modules that are not integrated.
integrated.
5. Stubs are called programs. Drivers are the calling programs.
- 16 -
Q.5(c) Explain different types of integration testing. [5]

Ans.: (i) Integration testing involves testing of many units by combining them together to form a module
or sub module as the case may be.
(ii) It ensures that the units working correctly when tested individually are also working correctly
when brought together.
(iii) Following are different types of integration testing
 Top-down integration testing
 Bottom-up integration testing
Top – down
(i) In top-down integration testing approach, testing is conducted from main module to sub
module. If the sub module is not developed a temporary program called STUBis used to
simulate a sub-module.
(ii) Here the top level of the application is tested first and then it goes down ward till it
reaches final component of the system.
Advantages :
(i) It is useful when many major flaws occur towards the top level of the program
(ii) The feasibility of an entire program can be determined easily at very early stage as the top
most layer.
(iii) It does not need drives as the top layers are available first which can work as driver for
the layer below
Disadvantages:
(i) Individual units and modules are rarely tested alone and if tested are tested very rate.
(ii) Stubs needs to be written and tested before they can be used in the integration testing.
(iii) Stubs modules are often more complicated than they first appear to be
(iv) It can create a false belief that software can be coded and tested before design is
finished.
Bottom  up integration testing
- 17 -
 In this approach testing is conducted from sub module to main module, if the main module is
not developed a temporary program called DRIVERS is used to simulate the main module.
 Here the bottom level of the application is tested first and then it goes upwards till it
reaches the main module of the program.
Advantages
(i) It is useful when major flaws occur towards bottom level of the program
(ii) Each component and unit is tested first for its correctness. It is found to be working
correctly, then only it goes for further integration.
(iii) It makes the system robust
Disadvantages
(i) Here, top-level components are the most important but tested last
(ii) Large no. of drivers may be required in this type of integration.
(iii) It is time consuming approach.
Q.5(d) Write short note on [5]

(i) Smoke testing
(ii) Sanity testing
(iii) Stress testing.
Ans.: (i) Smoke testing :
 It is done test basic functionality of software application, to ensure application is living.
 The depth of smoke testing is less than sanity testing.
 Steps involved in smoke testing can be installation, navigating through application etc.
 Smoke testing is not applied for testing the application but to ensure user will be able to
work with it.
(ii) Sanity testing :

 It is done to test the major functionality of the application.
 The depth of sanity testing is more than smoke testing.
 It demonstrates connectivity to database, application servers etc. basic GUI Testing.
 Sanity Testing is applied for testing the application.
(iii) Stress testing :

 Stress Testing is about the system resources required by the transactions that have been
planned to be undertaken. If the system has limited resources available, the response of
the system may deteriorate due to non-availability or loading of resources.
 Stress testing is used to define the resources level required by the system for its
efficient and optimum performance.
Q.5(e) Describe Testing approach of web application. [5]

Ans.: Web application involves component testing, integration testing, functionality testing, and GUI
testing followed by various specialized testing.
Following testing methods are used in web application testing
(i) Component Testing
One must define approach and test plan for testing web application individually at client side
and at server side
(ii) Integration Testing
Communication between client and server are tested integration testing.
(iii) Performance Testing
The System performance is tested as huge number of clients may be communicating with
server simultaneously. The system requirement specifications must define maximum and normal
load conditions so that they can be tested.
- 18 -
(iv) Concurrency Testing

It may be possible when multiple users may be accessing same records at a time. The
concurrency testing is required to understand the behavior of a system when multiple user
access same record.
(v) Disaster Recovery/ Business Continuity Testing
Testing for disaster recovery and business continuity involves testing the scenario of such
failures and actions taken by the system in each case. The requirement specifications must
describe the possible expectations of system behavior in case of any failure.
(vi) Testing for Extended Periods
Testing over an extended period must be done to understand if service level of server
deteriorates over a time due to some reasons like memory leakage.
(vii) Security Testing
System must be tested for possible weak areas called ‘vulnerabilities’ and possible intruders
trying to attack the system called ‘perpetrators’.
(viii)Compatibility Testing
Web application may be put in different environments when the users are using them in
production. Servers may be in different hardware, software, or operating system environment
than the recommended one.
Q.5(f) Explain the stages of testing with a suitable diagram. [5]

Ans.:
Unit Testing
Module
Testing
Subsystem
Testing
System
Testing
Acceptance
testing
 The initial or first phase of testing is Unit testing, where inputs from unit testing are used to
identify and eliminate defects at unit level.
 After Unit testing, once the units are ready for integration, then integration or module testing
is done. It can be done by either development team or test team depending upon the
requirements of stubs and drivers.
 Once module testing is done, subsystem testing phase starts where the subsystem interaction
is tested with other subsystem.
 Once the system completes all levels of integration, it goes for system testing, where complete
system is tested.
 Finally system is taken for acceptance testing where it is tested to see whether it fulfills the
acceptance criteria of users or not.

- 19 -

Software Quality Assurance: Time: 2 HRS.)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Quality Assurance: Time: 2 HRS.)

Uploaded by

Copyright:

Available Formats

T.Y. B.Sc. (IT) : Sem.

Q.1Attempt any THREE question of the following : [15]

(iii) Following are three parts of the approach, namely :

Q.1(b) State and explain the TQM principles [5]

6. Institutionalize training across the organization for all the people

Q.1(c) Explain the Continual/continuous improvement cycle (PDCA) [5]

Fig.: Continual improvement cycle (PDCA cycle)

Q.1(d) Difference between Continual and Continuous improvement cycle. [5]

Q.1(e) Explain generic quality management system structure. [5]

Fig.: Quality Management System of a typical organization.

2nd TIER – Quality Objectives

3rd TIER – Quality Manual

Q.1(f) Explain software quality management methods. [5]

(iv) Preventive Actions:

Q.2 Attempt any THREE question of the following : [15]

Q.2(b) Explain basic principles of testing. [5]

Q.2(c) An application consists of 55 defects introduced deliberately by the development [5]

2. Identify System Development phases and related test factors.

3. Identify Risk associated with test factor in case not achieved.

Q.2(f) Which skills are expected by a good tester ? [5]

 Techniques for Validation and Verification : Techniques of verification/validation must be

Q.3Attempt any THREE question of the following : [15]

Table 1 : Normal Boundary Value Testing Test Cases.

Table : Decision table diagram.

Q.3(c) Describe Basis path testing method in detail [5]

(i) Weak Normal Equivalence Class Testing :

(ii) Strong Normal Equivalence Class Testing :

Just like we have truth tables in digital logic, we have

Q.3(e) Explain cause effect graphing technique. [5]

Example: Triangle problem

Fig.: Cause-Effect diagram for

The effects designated by letter e are as under

The two major types of usage node are:

Q.4 Attempt any THREE question of the following : [15]

Q.4(b) Difference between verification and validation methods. [5]

Q.4(c) Explain walkthrough technique in detail. [5]

Q.4(d) Explain V model in detail [5]

Requirement Acceptance testing,

Coding, code review,

Fig.: V model for testing (validation model)

Q.4(e) Explain the types of milestone reviews [5]

Process of InProcess Review :

Process of PostImplementation Review :

Q.5 Attempt any THREE question of the following : [15]

Q.5(b) Difference between stubs and drivers. [5]

Q.5(c) Explain different types of integration testing. [5]

Bottom  up integration testing

Q.5(d) Write short note on [5]

(ii) Sanity testing :

(iii) Stress testing :

Q.5(e) Describe Testing approach of web application. [5]

(iv) Concurrency Testing

Q.5(f) Explain the stages of testing with a suitable diagram. [5]

You might also like