Software Testing 54

April 7, 2010
[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]
1. Why do we need to test the software?

Ans: - Testing is the process of executing a program with the intent of finding errors and
defects and verifying that the software satisfies the customer requirements.
Defects can exist in software. As a human being developers can do mistakes in a software
development process. They can miss some requirements to implement in a product. However it
is a primary duty of software vendor to check that the software developed is working correctly
or not, it is defect less or not. They should ensure that the software, final product meets the
whole requirements stated in SRS or not. The purpose of software testing is to analyze a
software product and determine the difference between its requirements and the actual
behavior. The purpose is also to evaluate if the features and functionality of the given product
meets the specified requirements of the customer or user.
Testing is done for the following reasons-
To detect errors in a software product.

To verify that a software product confirm to its requirements.
To evaluate an attribute and capability of a software product and determine
that it meets the required results.
There are some reasons of software bugs
Poor understanding and incomplete requirements.

Unrealistic schedule.
Fast changes in requirements.
Too many assumptions and complacency.
If developers do not test the software, there will be a big loss of budgets, time, and skills,
because after finding errors during the use of application by clients, they will come back to
Development Company and complain for that. The company will be responsible for any defect occurred
in software product and have to resolve the problems losing time, budgets, and skills.
2.
Explain the origin of the deject distribution in a typical software
life cycle.
development
Ans: - In a typical project life cycle, testing is the later activity. A software product is tested
lastly at the time before delivering. Whenever a product is tested, the defect may occur due to
many different-different reasons. The defects are distributed mainly in four categories or
phases, which is shown in below in figure.
Kuvempu University | sahil08red@gmail.com
April 7, 2010
Deffect Distribution
Design 56%
Code 7%
other 10%
Requirement: - In requirement phase of software development life cycle, there are more
chances to exist errors due to lack of understanding the requirements properly and
requirements are kept change during development of software even continuing to change the
requirements after coding.
Design: - Whenever a software is developed, design phase comes after requirement phase. The
product is designed on the basis of customer requirements stated in SRS. If in requirement
phase, any changes are made then the design of the product also should to be changed, else the
defect will occur in design phase.
Coding: - Coding phase of a software development life cycle, is very sensitive phase. But there
are fewer chances to defect a product. There may be some mistake of functional, conditional,
and syntactical errors. Coding is also done on the basis of requirements and design.
Defects are more in requirement phase because, requirement may not be understood properly
or keep changing requirements time to time.
Defects at the coding level are minimum because, coding process is well understood and well
defined.
3.
Explain any five types of software testing
Ans :- There are some commonly used software testing typesBlack Box Testin :- To ensure the validity of the software application without the need for
having its internal structure exposed. During the testing, the program code is not available but
the executable module is used. Detailed test plan and proper test environment is required.
Black box testing method is used in most of the applications to ensure the business functions
accurately.
White Box Testing :- It is a method to test the software utilizing its internal structure. The
complete code structure is available during the test. Normally, programmers use this method to
find the errors at the program level which helps in debugging. This also helps in understanding
the behavior of the program, code review, and data flow and code level test case design.
Alpha Testing :- A person other than the developer carries out testing, in-house, and at
various project milestones. Since a third person tests the software, a detailed test plan must be
provided.
April 7, 2010
Beta Testing :- This type of testing is conducted by end-users either after or in parallel with
system testing. Users who are the ultimate owner of the software will test the system before
deployment and the errors will be reported back to the developer. For instance, Microsoft
Windows 2000 was released to a set of users worldwide for a limited duration for beta testing.
All these users were using earlier versions of Microsoft operating system. The goal is to test
the product by the end user in all respect.
Unit Testin :- Unit testing uses both black box and white box methods to test a module
against its design specification immediately after its design. This is normally done by the
developer or another programmer. Unit testing is important and mandatory for all software
modules. To illustrate, if you develop a program which computes simple interest, it has to be
tested for all different type of inputs. This is known as unit testing.
Integration Testing :- Here an independent tester in association with developers tests the
system after the integration. In large scale business systems, it is necessary to integrate many
modules developed by different people. Once it is integrated, the same has to be tested and
known as integration testing.
System Testing :- This is a pre-deployment testing to verify whether the developed system
meets the requirement specifications or not by simulating the target operational environment.
This is to verify whether the system is production ready or not.
Acceptance Testing :- Here the customer carries out system testing before finally accepting
the system as meeting his stated requirements. This is normally done by the customer in
association with the developer. Accepting testing is must for all systems. They will test the
software with the real data and conforms the software system for its correctness.
4.
What are quality concepts and quality of conformation?
Ans :- Quality Concepts are
Quality
Quality Control
Quality Assurance
Cost of Quality
The American heritage dictionary defines quality as a characteristic or attribute of something.
As an attribute of an item quality refers to measurable characteristic-things which we are able
to compare to known standards such as length, color, electrical properties, and malleability, and
so on. However, software is largely an intellectual entity, more challenging to characterize than
physical object.
Nevertheless, measures of a programs characteristic do exist. These properties include
1. Cyclomatic complexity
2. Cohesion
3. Number of functions points
4. Lines of code.
Quality of conformance :- Quality of conformance is the degree to which the design
specifications are followed during manufacturing. Again, the greater the degree of
conformance, the higher the level of quality of conformance.
In software development, quality of design encompasses requirements, specifications and
design of the system. The requirements must be gathered formally and there should not be any
ambiguity and must be complete in all respects. Specifications must be elaborated and defined
formally. Design must follow standard methods and process.
April 7, 2010
Quality of conformance is an issue focused primarily on implementation. If the

implementation follows the design and the resulting system meets its requirements and
performance goals, conformance quality is high.
5.
Explain defect amplification model.
Ans: - A defect amplification model can be used to illustrate the generation and detection of
errors during preliminary design, detail design, and coding steps of the software engineering
process. The model is illustrated schematically in Figure.
Errors for various step Defects
Errors passed through
Detection
Percent efficiency for error
detection.
Amplified errors c:x

Newly
generated
Error
passed
to next
step.
Errors.
Figure 1
Figure 1 illustrates hypothetical example of defect amplification for a software development

process in which no reviews are conducted. As shown in the figure each test step is assumed to
uncover and
correct fifty percent of all incoming errors without introducing new errors (an optimistic
assumption). Ten preliminary design errors are amplified to 94 errors before testing
commences. Twelve latent defects are released to the field. Figure 2 (see figure 3.4 and 3.5 page
29-30) considers the same conditions except that design and code reviews are conducted as part
of each development step. In this case, ten initial preliminary design errors are amplified to 24
errors before testing commences.
Only three latent defects exist. By recalling the relative cost associated with the
discovery and correction of errors, overall costs (with and without review for our hypothetical
example) can be established.
To conduct reviews a developer must expend time and effort and the development
organization must spend money. However, the results of the presiding example leave little
doubt that we have encountered a Pay now or pay much more later syndrome.
Formal technical reviews (for design and other technical activities) provide a
demonstrable cost benefit and they should be conducted.
6.
What are the main objectives of Formal technical reviews (FRI)?
Ans: - FTR is a SQA activity that is performed by software engineers. The main objectives of
the FTR are:
o To uncover errors in function, logic, implemented in any representation of
the software
o To verify that software under review meets its requirements
April 7, 2010
o To ensure that software has been represented according to predefined

standards
o To achieve software that is developed in an uniform manner
o To make projects more manageable
o
In addition, the FTR serves as a training ground, enabling junior engineers to observe different
approaches to software analysis, design, and implementation. The FTR also serves to promote
backup and continuity because numbers of people become familiar with parts of the software
that they may not have otherwise seen.
The FTR is actually a class of reviews that include walkthrough inspection and round robin
reviews, and other small group technical assessments of software. Each FTR is conducted as
meeting and will be successful only if it is properly planned, controlled and attended. In the
paragraph that follows, guidelines similar to those for a walk through are presented as a
representative Formal technical review.
The Focus of the FTR is on a work product - a component of the software. At the end of
review all attendees of the FTR must decide:
1. Whether to accept the work product without further modification
2. Reject the work product due to serve errors (Once corrected another review
must be performed)
3. Accept the work product provisionally (minor errors have been encountered and
must be corrected but no additional review will be required)
4.
The decision made, All FTR attendees complete a sign-off indication their participation
in the review and their concurrence with the review team findings
7.
Prepare a checklist to be followed while inspection.
Ans :- Prepare/Solve by yourself.

8.
Explain equivalence partitioning and boundary value analysis with example. List
the prons and cons of each methods.
Ans :- Equivalence Partitioning :- The main objective of this method is to partitioning the
input so that an optimal input data is selected. Steps to be followed are:
1. Divide the input domain into classes of data for which test cases can be
generated.
2. Attempting to uncover classes of errors, if any.
3. Identify the both right and wrong input data while partitioning the data.
4. Test the program for all types of data based on equivalence classes for input
conditions.
An equivalence class represents a set of valid or invalid states. An input condition is a
specific numeric value, range of values, a set of related values, or a Boolean condition.
April 7, 2010
Equivalence classes can be defined by:
If an input condition specifies a range or a specific value, one valid and two invalid
equivalence classes defined.
If an input condition specifies a Boolean or a member of a set, one valid and one
invalid equivalence classes defined.
Test cases for each input domain data item developed and executed. This method uses
less number of input data compare to exhaustive testing. However, the data for boundary
values are not considered
This method though reduces significantly the number of input data to be tested; it does
not test the combinations of the input data..
Example: If an input condition specifies that the range of values of the input variable
items must be from 1 to 999, one valid equivalence class would be 1<=items<=999 and 2
invalid equivalence classes would be items<1 and items>999.
Boundary Value Analysis: - It is observed that boundary points for any inputs are not tested
properly. This leads to many errors.
Large numbers of errors tend to occur at boundaries of the input domain. Boundary
Value Analysis (BVA) leads to selection of test cases that exercise boundary values.
BVA complements equivalence partitioning i.e. select any element in an equivalence
class, select those at the edge of the class.
Examples:
1. For a range of values bounded by a and b, test (a-1), a, (a+1), (b-1), b, (b+1). Consider
If a = 1 and b = 999 then the boundary values would be 0,1,2,999,1000 etc.
2. If input conditions specify a number of values n, test with (n-1), n and (n+1) input
values.
3. Apply 1 and 2 to output conditions (e.g., generate table of minimum and maximum
size).
4. If internal program data structures have boundaries (e.g., buffer size, table limits), use
input data
to exercise structures on boundaries.
BVA and equivalence partitioning both helps in testing the programs and covers most
of the conditions.
This method does not test the combinations of input conditions.
9.
Explain graph matrices with an example.
April 7, 2010
Ans :- Graph matrices can automate derivation of flow graph and determination of a set of basis
paths. Software tools to do this can use a graph matrix. A sample graph matrix is shown in
Figure.
The graph matrix:
-
Is a square matrix with number of sides equal to number of nodes

Rows and columns of the matrix correspond to the number of nodes in the flow
graph
Entries correspond to the directing edges.
The matrix can associate a number with each entry of the edge.
Use a value of 1 to calculate the cyclomatic complexity. The cyclomatic complexity is

calculated as
follows:
- For each row, sum the values of each column and subtract 1 with the sum
- Sum these final column totals and add 1.
In the example given in Figure 5,4, final value for each row is (1, 1,0,1,0,0,0,0). After
adding these values with addition of 1 becomes 4.
Some other interesting link weight can be measured by the graph as:
1
8
1
2
Probability that a link (edge) will be executed

Processing time for traversal of a link
Memory required during traversal of a link
Resources required during traversal of a link
7a 7b
1
1
3
4
1
1
1
1
1
5
6
7a
7b
1
1
1
April 7, 2010
10.
Explain control structure testing.
Ans: - Solve by yourself.

11.
Write a note on test automation? List few automation tools used for testing.
Ans :- Automation of testing is the state of the art technique where in number of tools will help
in testing program automatically. Programmers can use any tool to test his/her program and
ensure the quality. There are number of tools are available in the market. Some of the tools
which help the programmer are:
1.
2.
3.
4.
5.
6.
7.
Static analyzer
Code Auditors
Assertion processors
Test file generators
Test Data Generators
Test Verifiers
Output comparators.
Programmer can select any tool depending on the complexity of the program. All tools
only assist in testing but the initial effort must be more to design and develop test cases.
12.
Explain in details validation method of testing software and software testing
steps.
Ans :- At the culmination of integration testing, software is completely assembled as a package.
Interfacing errors have been uncovered and corrected, and a final series of software tests validation testing- may begin.
Validation can be defined in many ways, but a simple definition is that validation
succeeds when software functions in a manner that can be reasonable expected by customer.
Reasonable expectations are defined in the software requirement specification - a
document that describes all user-visible attributes of the software. The specification contains a
section titled Validation Criteria.
Information contained in that section forms the basis for a validation testing approach.
Validation test criteria: - A test plans outlines the classes of tests to be conducted and a test
procedure defines specific test cases that will be used in an attempt to uncover errors in
conformity with requirements. Both the plan and procedure are designed to ensure that:
All functional requirements are satisfied
All performance requirements are achieved
Documentation is correct and human-engineered and
Other requirements like portability, error recovery, and maintainability are met.
Configuration review: - An important element of the validation process is a configuration
review. The intent of the review is to ensure that all elements of the software configuration
have been properly developed, are catalogued, and have the necessary detail to support the
maintenance phase of the software life cycle.
April 7, 2010
Alfa and Beta testing :- If software is developed as a product to be used by many customers, it
is impractical to perform formal acceptance tests with each one. Most software product
developers use a process called alpha beta testing to uncover errors that only the end user
seems able to find.
The alpha test is conducted at the developers site by a customer software is used in a
natural setting with the developer Looking over the shoulder of the user and recording errors
and usage problems. Alpha tests are conducted in a controlled environment.
The beta test is conducted at one or more customer sites by the end user(s) of the
software. Unlike alpha testing the developer is generally not present therefore the beta test is a
live.
The customer records all problems (real/imagined) that are encountered during beta
testing and reports these to the developer at regular intervals. Because of problems reported
during beta test, the software developer makes modification and then prepares for release of the
software product to the entire customer base.
13.
With figure explain the strategy for software testing and software testing steps.
Ans :- A strategy for software testing integrates software test case design methods into a wellplanned series of steps that result in the successful construction of software. As important, a
software testing strategy provides a road map for the software developer, the quality assurance
organization, and the customer- a road map that describes the steps to be conducted as part of
testing, when these steps are planned and then undertaken, and how much effort, time, and
resources will be required
Therefore any testing strategy must incorporate test planning, test case design, test
execution, and resultant data collection and evaluation.
A software testing strategy should be flexible enough to promote the creativity and
customization that are necessary to adequately test all large software-based systems. At the
same time, the strategy must be rigid enough to promote reasonable planning and management
tracking as the project progresses.
The software engineering process may be viewed as a spiral, illustrated in Figure 2.
Initially system engineering defines the roll of software and leads to software requirements and
analysis, where the information domain, function, behavior, performance, constraints, and
validation criteria for software are established. Moving inward along the spiral, we come to
design and finally to coding.
To develop computer software, we spiral in along streamlines that decrease the level of
abstraction on each turn.
April 7, 2010
Figure 2 - Testing Strategy.
are validated against the software that has been constructed. Finally, we arrive at system testing
where the software and other system elements are tested as a whole.
To test computer software, we spiral out along streamlines that broaden the scope of
testing with each turn. Considering the process from a procedural point of view testing within
the context of software engineering is a series of four steps that are implemented sequentially.
The steps are shown In Figure 3 initially tests focus on each module individually,
assuring that it functions as a unit hence the name unit testing. Unit testing makes heavy use
of white-box testing techniques, exercising specific paths in a modules control structure to
ensure complete coverage and maximum error detection. Next, modules must be assembled or
integrated to form the complete software package. Integration testing addresses the issues
associated with the dual problems of verification and program construction. Black-box test case
design techniques are most prevalent during integration, although a limited amount of white box testing may be used to ensure coverage of major control paths. After the software has been
integrated (constructed), sets of high-order test are conducted. Validation criteria (established
during requirements analysis) must be tested. Validation testing provides final assurance that
software needs all functional, behavioral and performance requirements. Black-box testing
techniques are used exclusively during validation.
The last high-order testing step falls outside the boundary of software engineering and
into the broader context of computer system engineering. Software once validated must be
combined with other system elements (e.g., hardware, people, and databases). System testing
verifies the tall elements mesh properly and that overall system function/performance is
achieved.
10
April 7, 2010
Figure 3
- Software Testing Steps
14.
Explain integration testing? Explain any one method to carry out integration
testing
Ans :- Integration testing is a systematic technique for constructing the program structure
while conducting tests to uncover errors associated with interfacing.
The objective is to take unit tested modules and build a program structure that has been
dictated by design.
Integration testing is a systematic technique for constructing the program structure
while conducting tests to uncover errors associated with interfacing. The objective is to take
unit tested modules and build a program structure that has been dictated by design.
There are two methods of integration testing.
1. Top down testing.
2. Bottom up testing.
Top-down integration is an incremental approach to construction of program structure.
Modules are integrated by moving downward through the control hierarchy, beginning with
the main control module.
The integration process is performed in a series of five steps:
1. The main control module is used as a test driver, and stubs are substituted for all
modules directly subordinate to the main control module.
2. Depending on the integration approach selected (i.e., depth-or breadth first),
subordinate stubs are replaced one at a time with actual modules.
3. Tests are conducted as each module is integrated.
4. On completion of each set of tests, another stub is replaced with real module.
11
April 7, 2010
5. Regression testing may be conducted to ensure that new errors have not been
introduced.
The process continues from step2 until the entire program structure is built.
Top-down strategy sounds relatively uncomplicated, but in practice, logistical problems
arise. The most common of these problems occurs when processing at low levels in the
hierarchy is required to adequately test upper levels. Stubs replace low-level modules at the
beginning of top-down testing; therefore, no significant data can flow upward in the program
structure.
The tester is left with three choices.
1. Delay many tests until stubs are replaced with actual modules.
2. Develop stubs that perform limited functions that simulate the actual
module
3. Integrate the software from the bottom of the hierarchy upward
The first approach causes us to lose some control over correspondence between specific
tests and incorporation of specific modules. This can lead to difficulty in determining the cause
of errors tends to violate the highly constrained nature of the top down approach. The second
approach is workable but can lead to significant overhead, as stubs become increasingly
complex. The third approach is discussed in next section.
15.
Write short notes on
a)Cyclomaticcomplecity
b)Smoke testing, localization testing
(c) software quality metrics.
Ans :- The cyclomatic complexity gives a quantitative measure of the logical complexity. This
value gives the number of independent paths in the basis set, and an upper bound for the
number of tests to
ensure that each statement is executed at least once.
An independent path is any path through a program that introduces at least one new set
of processing statements or a new condition (i.e., a new edge)
12
April 7, 2010
PDL for PROCEDURE SORT

1:
do while records
remain
read record;
2:
if record field 1= 0
3:
then process record;
store in buffer;
increment counter;
4:
elseif record field 2 = 0
5:
then reset record;
6:
else process record;
store in file;
7a:
endif
endif
7b: enddo
8: end
Figure 4 - Sample program and corresponding flow diagram.
In Figure 4, the statements are numbered and the corresponding nodes also numbered
with the same number. The sample program contains one DO and three nested IF statements.
From the example we can observe that:
Cyclomatic Complexity of 4 can be calculated as:
1. Number of regions of flow graph, which is 4.
2. #Edges - #Nodes + 2, which is 11-9+2=4.
3. #Predicate Nodes + 1, which is 3+1=4.
The above complexity provides the upper bound on the number of tests cases to be
generated or independent execution paths in the program. The independent paths (4 paths) for
the program shown in Figure 4 are given below:
-
Independent Paths:
1.
2.
3.
4.
1, 8
1, 2, 3, 7b, 1, 8
1, 2, 4, 5, 7a, 7b, 1, 8
1, 2, 4, 6, 7a, 7b, 1, 8
Cyclomatic complexity provides upper bound for number of tests required to guarantee
the coverage of all program statements.
16.
Explain the importance of testing. What are the Hurdles in testing?
Ans :Importance :- Testing activity cannot be eliminated in the life cycle as the end product must be
bug free and a reliable one. Imagine a situation where in a persons balance in the account
13
April 7, 2010
reduces without withdrawing. A wrong marks card reaches the student which may spoil the
students career. Testing must be an integral part of the system development and this process
cannot be eliminated.
Testing is a critical element of software Quality Assurance

Post-release removal of defects is the most expensive
Significant portion of life cycle effort expended on testing
In a typical service oriented project, about 20-40% of project effort is spent on testing. It is
much more in the case of human-rated software.
An example could be, at Microsoft, tester to developer ratio is 1:1 whereas at NASA
shuttle development center (SEI Level 5); the ratio is 7:1. This shows that how testing is an
integral part of Quality Assurance.
HURDLES IN TESTING
As in many other development projects, testing is not free from hurdles. Some of the
hurdles normally encounters are:
Usually late activity in the project life cycle

No concrete output and therefore difficult to measure the value addition
Lack of historical data
Recognition of importance is relatively less
Politically damaging as you are challenging the developer
Delivery commitments
Too much optimistic that the software always works correctly3
Based on the project and delivery schedule these hurdles have to be addressed.
17.
What are the testing fundamentals? Explain briefly
Ans :- Any software program that is to be quality conscious, must be rigorously tested with a
predefined set of objectives. These objectives could vary from project to project. Some projects
may set a few objectives whereas others could set complete objectives. It is necessary to know
the objectives before testing any software system.
Some of objective of testing are:o Testing is a process of executing a program with the intent of finding an
error.
o A good test is one that has a high probability of finding an as yet
undiscovered error.
o A successful test is one that uncovers an as yet undiscovered error.
The objective is to design tests that systematically uncover different classes of errors
and do so with a minimum amount of time and effort.
14
April 7, 2010
Secondary benefit include:o Testing demonstrates that software functions appear to be working
according to specification.
o Those performance requirements appear to have been met.
o Data collected during testing provides a good indication of software
reliability and some indication of software quality.
Finally, if testing process is followed we can guarantee that testing cannot show the
absence of defects, it can only show that software defects are present. Once the objectives are
set, testing process needs to be understood properly.
Testing is a complex process and requires efforts similar to software development. A
typical test information flow is shown in Figure 5.
Figure 5 Test Information flow in a typical software test life cycle.
Software Configuration includes a Software Requirements Specification, a

Design Specification, and source code.
A test configuration includes a Test Plan and Procedures, test cases, and testing
tools.
It is difficult to predict the time to debug the code, hence it is difficult to
schedule.
Test Case Design: - During testing, test data and condition under which these data must be
used is to be determined. Such process is known as test case design. We need to understand the
scope of the testing and design the test cases.
Some of the points to be noted during the test case design are:
15
April 7, 2010
o Can be as difficult as the initial design.

o Can test if a component conforms to specification It is known as Black Box
Testing.
o Can test if a component conforms to design It is known as White box
testing.
In the Testing case design we cannot prove the complete correctness of the system as
not all execution paths can be tested during the test execution. Consider the flow chart example
shown in Figure 1.3 which represents multiple control structures and multiple paths of
program execution.
Loop<=20 times
Figure 6 Flow chart of a typical program execution with multiple paths.
A program with a structure as illustrated above (with less than 100 lines of Pascal code)
has about 100,000,000,000,000 possible combinations of paths. If attempted to test these at the
rate of 1000 tests per second, would take 3170 years to test all paths. This shows that
exhaustive testing of a software is not possible.
Testing is a mandatory activity in software development cycle. This activity must begin
from the requirements specification and should be addressed at each level of development cycle.
Before the beginning of the test execution, one should know about the importance of testing,
objectives and process of testing.
18.
Quality and reliability are related concepts but are different in a number of ways.
Discuss them.
Ans :- Solve by yourself.
16
April 7, 2010
19.
Explain in brief, the review technique adopted in quality assurance.

OR
List and explain the review techniques adopted in software quality assurance.
Ans :- QA consists of the editing and reporting functions of management. The goal of quality
assurance is to provide management with the data necessary to be informed about product
quality, thereby gaining insight and confidence that product quality is meeting its goals. Of
course, if the data provided through QA identify problems, it is managements responsibility to
address the problems and apply the necessary resources to resolve quality issues.
Conformance to explicitly stated functional and performance requirements, explicitly
documented development standards, and implicit characteristics that are expected of all
professionally developed software.
The above definition emphasizes three important points:
Software requirements are the foundation from which quality is measured. Lack of
conformance to requirements is lack of quality.
Specified standards define a set of development criteria that guide the manner in
which software is engineered. If the criteria are not followed, lack of quality will
almost surely result.
There is a set of implicit requirements often goes unmentioned. (E.g. the desire of
good maintainability). If software conforms to its explicit requirements but fails to
meet implicit requirements, software quality is questionable.
Software reviews are a filter for the software engineering process. That is, reviews are
applied at various points during software development and serve to uncover errors that can
then be removed. Software reviews serve to purify the software work products that occur as a
result of analysis, design, and coding.
Any review is a way of using the diversity of a group of people to:
Point out needed improvements in the product of a single person or a team;
Confirm that parts of a product in which improvement is either not desired, or not
needed.
Achieve technical work of more uniform, or at least more predictable quality that
can be achieved without reviews, in order to make technical work more manageable.
There are many different types of reviews that can be conducted as part of softwareengineering like:
1. An informal meeting if technical problems are discussed.
2. A formal presentation of software design to an audience of
customers, management, and technical staff is a form of review.
3. A formal technical review is the most effective filter from a
quality assurance standpoint.
17
April 7, 2010
Conducted by software engineers for software engineers, the FTR is an effective means
for improving software quality.
Explain the different error checklist for inspections consider the

program or perform review and list the review findings.
20.
Ans :- An important part of the inspection process is the use of a checklist to examine the
program for common errors. The checklist is largely language independent as most of the
errors can occur with any programming language.
Checklist for Data Reference Error:1. Is a variable referenced whose value is unset or uninitialized? This is probably the most
frequent programming error; it occurs in a wide variety of circumstances.
2. For all array references, is each subscript value within the defined bounds of the
corresponding dimension?
3. For all array references, does each subscript have an integer value? This is not
necessarily an error in all languages, but it is a dangerous practice.
4. Check for dangling reference problem?
Note:The Dangling reference problem occurs in situations where the lifetime of a pointer is
greater than the lifetime of the referenced storage.
5. Are there any explicit or implicit addressing problems if on the machine being used, the
units of storage allocation are smaller than the units of storage addressability?
6. If a data structure is referenced in multiple procedures or subroutines, is the structure
defined identically in each procedure?
7. When indexing into a string, are the limits of the string exceeded?
Checklist for Data-Declaration Error:1. Have all variables been explicitly declared? A failure to do so is not necessarily
an error, but it is a common source of trouble.
2. If all attributes of a variable are not explicitly stated in the declaration, are the
defaults well understood?
3. Where a variable is initialized in a declarative statement, is it properly
initialized?
4. Is each variable assigned the correct length, type, and storage class?
5. Is the initialization of a variable consistent with its storage type?
Checklist for Computation Error:1. Are there any computations using variables having inconsistent (e.g. No arithmetic)
data types?
2. Are there any mixed mode computations?
18
April 7, 2010
3. Are there any computations using variables having the same data type but different
lengths? (Example: short int X + long int Y = short int Z)
4. Is the target variable of an assignment smaller than the right-hand expression?
(Example int Product = float variable 1 * double of variable 2)
5. Is an overflow or underflow exception possible during the computation of an
expression? That is, the end result may appear to have a valid value, but an intermediate
result might be too big or too small for the machines data representations.
6. Is it possible for the divisor in a division operation to be zero?
7. Where applicable, can the value of a variable go outside its meaningful range?
8. Are there any invalid uses of integer arithmetic, particularly division? For example, if I
is an integer variable, whether the expression 2*I/2 is equal to I depends on whether I
has an odd or an even value and whether the multiplication or division is performed
first.
Checklist for Comparison Error:1. Are there any comparisons between variables having inconsistent data types (e.g.
comparing a character string to an address)?
2. Are there any mixed-mode comparisons or comparisons between variables of different
lengths?
3. If so, ensure that the conversion rules are well understood.
4. Does each Boolean expression state what it is supposed to state? Programmers often
make mistakes when writing logical expressions involving and, or, and not.
5. Are the operands of a Boolean operator Boolean? Have comparison and Boolean
operators been erroneously mixed together?
Checklist for Control-Flow Error:1. If the program contains a multi way branch (e.g. a computed GO TO in FORTRAN),
can the
Index variable ever exceed the number of branch possibilities? For example, in the Fortran
Statement, Will I always have the value 1, 2, or 3?
Here, the index value must not go beyond 3 as there are only 3 branches.
2. Will every loop, function or program module eventually terminate? Devise an informal
proof or argument showing that each loop will terminate
3. Is it possible that, because of the conditions upon entry, a loop will never execute? If so,
does this represent an oversight? For instance, for loops headed by the following
statements: DO WHILE (NOTFOUND) DO I=X TO Z
4. What happens if NOTFOUND is initially false or if X is greater than Z?
5. Are there any non-exhaustive decisions? For instance, if an input parameters expected
values are 1, 2, or 3; does the logic assume that it must be 3 if it is not 1 or 2? If so, is
the assumption valid?
What are the different techniques available to conduct black box

testing?
21.
19
April 7, 2010
Ans :- Functional tests examine the observable behavior of software as evidenced by its
outputs, without any reference to internal functions. This kind of tests is from the user point of
view, which means as if the user is testing as in the normal business functions.
Various techniques are used for black box testing. Some of the techniques used for black
box testing are discussed below:
The main objective of this method is to partitioning the input so that an optimal input
data is selected. Steps to be followed are:
Equivalence Partitioning:1.
2.
3.
4.
Divide the input domain into classes of data for which test cases can be generated.
Attempting to uncover classes of errors, if any.
Identify the both right and wrong input data while partitioning the data.
Test the program for all types of data based on equivalence classes for input
conditions
.
An equivalence class represents a set of valid or invalid states. An input condition is a
specific numeric value, range of values, a set of related values, or a Boolean condition.
Equivalence classes can be defined by:
If an input condition specifies a range or a specific value, one valid and two invalid
equivalence classes defined.
If an input condition specifies a Boolean or a member of a set, one valid and one
invalid equivalence classes defined.
Test cases for each input domain data item developed and executed. This method uses
less number of input data compare to exhaustive testing. However, the data for boundary
values are not considered.
This method though reduces significantly the number of input data to be tested; it does
not test the combinations of the input data.
Example: If an input condition specifies that the range of values of the input variable
items must be from 1 to 999, one valid equivalence class would be 1<=items<=999 and 2
invalid equivalence classes would be items<1 and items>999.
Boundary Value Analysis:It is observed that boundary points for any inputs are not tested properly. This leads to
many errors. Large numbers of errors tend to occur at boundaries of the input domain.
Boundary Value Analysis (BVA) leads to selection of test cases that exercise boundary
values. BVA complements equivalence partitioning i.e. select any element in an equivalence
Examples:
20
April 7, 2010
1. For a range of values bounded by a and b, test (a-1), a, (a+1), (b-1), b, (b+1).
Consider If a = 1 and b = 999 then the boundary values would be 0,1,2,999,1000 etc.
values.
size).
4. If internal program data structures have boundaries (e.g., buffer size, table limits),
use input data to exercise structures on boundaries.
of the conditions.
Cause Effect Graphic Technique:Translation of natural language descriptions of procedures to software based algorithms
is error prone.
Example: From US Army Corps of Engineers:
Executive Order 10358 provides in the case of an employee whose work week varies
from the normal Monday through Friday work week that Labor Day and Thanksgiving Day
each were to be observed on the next succeeding workday when the holiday fell on a day
outside the employees regular basic work week. Now, when Labor Day, Thanksgiving Day or
any of the new Monday holidays are outside an employees basic workbook, the immediately
preceding workday will be his holiday when the non-workday on which the holiday falls is the
second non-workday or the non-workday designated as the employees day off in lieu of
Saturday. When the non-workday on which the holiday falls is the first non-workday or the
non-workday designated as the employees day off in lieu of Sunday, the holiday observance is
moved to the next succeeding workday.
22.
Explain in brief different methods available in white box testing.
Ans :- This testing technique takes into account the internal structure of the system or
component. The entire source code of the system must be available. This technique is known as
white box testing because the complete internal structure and working of the code is available.
Testers are transparent to the entire code and design documentation during the testing.
White box testing helps to derive test cases to ensure:
1.
2.
3.
4.
All independent paths are exercised at least once.

All logical decisions are exercised for both true and false paths.
All loops are executed at their boundaries and within operational bounds.
All internal data structures are exercised to ensure validity
White box testing helps to:
Traverse complicated loop structures

21
April 7, 2010
Cover common data areas

Cover control structures and sub-routines
Evaluate different execution paths
Test the module and integration of many modules
Discover logical errors, if any
Helps to understand the code
Uncover execution problems during testing
White box testing is used to test conformance to requirements:
Logic errors and incorrect assumptions most likely to be made when coding for
special cases.
Need to ensure these execution paths are tested. This is also called as test of
logical coverage.
May find assumptions about execution paths incorrect, and so make design
errors. White box testing can find these errors.
Typographical errors are random. Just as likely to be on an obscure logical path
as on a mainstream path.
23. What are the guidelines to be followed which helps for creating series
of generic tests for GUIs?
Ans :- Guidelines are categorized into different kind of operations. Some of them are discussed
below:
For Windows:
Will the window open properly based on related typed or menu-based

commands?
Can the window be resized, moved, scrolled?
Does the window properly regenerate when it is overwritten and then recalled?
Are all functions that relate to the window available when needed?
Are all functions that relate to the window available when needed?
Are all functions that relate to the window operational?
Are all relevant pull-down menus, tool bars, scroll bars, dialog boxes, and
buttons, icons and other controls available and properly represented?
Is the active window properly highlighted?
If multiple or incorrect mouse picks within the window cause unexpected side
effects?
Are audio and/or color prompts within the window or as a consequence of
window operations presented according to specification?
Does the window properly close?
For Pull-Down menus and mouse operations:Kuvempu University | sahil08red@gmail.com
22
April 7, 2010
Is the appropriate menu bar displayed in the appropriate context?

Does the application menu bar display system related features (e.g. a clock
display)
Do pull-down operations work properly?
Do breakaway; menus, palettes, and tool bars work properly?
Are all menu functions and pull-down sub functions properly listed?
Are all menu functions and pull-down sub functions properly listed?
Are all menu functions properly addressable by the mouse?
Are text typeface, size, and format correct?
Is it possible to invoke each menu function using its alternative text-based
command?
Are menu functions highlighted (or grayed-out) based on the context of current
operations within a window?
Does each menu function perform as advertised?
Are the names of menu functions self-explanatory?
Is help available for each menu item, and is it context sensitive?
Are mouse operations properly recognized throughout the interactive context?
If multiple clicks are required, are they properly recognized in context?
If the mouse has multiple buttons, are they properly recognized in context?
Do the cursor, processing indicator (e.g. an hour glass or clock), and pointer
properly change as different operations are invoked?
For Data Entry:
Is alphanumeric data entry properly echoed and input to the system?

Do graphical modes of data entry (e.g., a slide bar) work properly?
Is invalid data properly recognized?
Are data input messages intelligible?
Are basic standard validation on each data is considered during the data entry
itself?
Once the data is entered completely and if a correction is to be done for a specific
data, does the system requires entering the entire data again?
Does the mouse clicks are properly used?
Does the help buttons are available during data entry?
In addition to the above guidelines, finite state modeling graphs may be used to derive a
series of tests that address specific data and program objects that are relevant to the GUI.
24. With figure explain the debugging process and why debugging is
difficult. OR
Explain the debugging process that results in the removal of the
error.
23
April 7, 2010
Ans :- The debugging process begins with the execution of a test case. As shown in Figure 7.7,
the debugging process begins with the execution of a test case. Results are assessed and a lack
of correspondence between expected and actual is encountered. In many cases, the noncorresponding data is a symptom of an underlying cause as yet hidden. The debugging process
attempts to match symptom with cause, thereby leading to error correction.
The debugging process attempts to match symptom with cause, there by leading to
error correction. The debugging process will always have two outcomes:
1. The cause will be found, corrected, and removed
2. The cause will not be found.
See Figure in the book (Page No.89)
In the latter case, the person performing debugging may suspect a cause, design a test case
to help validate his/her suspicion, and work toward error correction in iterative fashion.
Some characteristics of bugs provide some clues:
The symptom and the cause may be geographically remote. That is, the symptom may
appear in one part of a program, while the cause may actually be located at a site that is far
removed.
1.
2.
3.
4.
5.
Highly coupled program structures exacerbate this situation.

The symptom may disappear (temporarily) when another error is corrected.
The symptom may actually be caused by no errors (e.g. round-off inaccuracies).
The symptom may be caused by human error that is not easily traced.
The symptom may be a result of timing problems, rather than processing
problems.
6. It may be difficult to accurately reproduce input conditions (e.g. a real-time
application in which input ordering is indeterminate).
7. The symptom may be due to causes that are distributed across a number of tasks
running on different processors.
25. Explain unit test method with the help of your own sample. OR
With an illustrative example, explain the unit test method.
Ans :- Unit testing focuses verification efforts on the smallest unit of software design the
module. Using the procedural design description as guide, important control paths are tested to
uncover errors within the boundary of the module. The relative complexity of tests and
uncovered errors are limited by the constraint scope established for unit testing. The unit test
is normally white-box oriented, and the step can be conducted in parallel for multiple modules.
For example, a small program that computes a simple matrix multiplication is a unit. In
a business applications of inventory control, placing a purchase order also a typical unit or
module.
24
April 7, 2010
Unit testing is normally considered as an adjunct to the coding step. After source-level code
has been
developed, reviewed, and verified for correct syntax, unit test case design begins. A review of
design
information provides guidance for establishing test cases that are likely to uncover errors in
each of the categories discussed above. Each test case should be coupled with a set of expected
results.
Because a module is not a standalone program, driver and or stub software must be
developed for each unit test. The unit test environment is illustrated in figure 7.6.In most
applications a driver is nothing more than a Main program that accepts test case data, passes
such data to the test module and prints relevant results. Stubs serve to replace modules that are
subordinate to the module that is to be tested. A stub or dummy sub program uses the
subordinate modules interface may do minimal data manipulation prints verification of entry,
and returns.
Drivers and stubs represent overhead. That is, both are software that must be developed
but that is not delivered with the final software product. If drivers and stubs are kept simple,
actual overhead is relatively low. Unfortunately, many modules cannot be adequately unit
tested with simple overhead software. In such cases, complete testing can be postponed until
the integration test step (Where drivers or stubs are also used).
Unit test is simplified when a module with high cohesion is designed. When a module
addresses only one function, the number of test cases is reduced and errors can be more easily
predicted and uncovered.
See figure in book (Page No.79)
26. Develop an integration testing strategy for any system that you have
implemented already. List the problems encountered during such process.
Ans :- Integration testing is a systematic technique for constructing the program structure
Strategy:Integration testing is a systematic technique for constructing the program structure
There is often a tendency to attempt non-incremental integration; that is, to construct
the program using a big bang approaches. All modules are combined in advance. The entire
program is tested as a whole. And chaos usually results! A set of errors is encountered.
Correction is difficult because isolation of causes is complicated by the vast expanse of the
25
April 7, 2010
entire program. Once these errors are corrected, new ones appear and the process continues in
a seemingly endless loop.
Incremental integration is the antithesis of the big bang approach. The program is
constructed and tested in small segments, where errors are easier to isolate and correct;
interfaces are more likely to be tested completely; and a systematic test approach may be
applied. We discuss some of incremental methods here:
Top-Down Integration:Top-down integration is an incremental approach to construction of program structure.
Modules are integrated by moving downward through the control hierarchy, beginning with
the main control module.
The integration process is performed in a series of five steps:
1. The main control module is used as a test driver, and stubs are substituted for all
modules directly subordinate to the main control module.
2. Depending on the integration approach selected (i.e., depth-or breadth first),
subordinate stubs are replaced one at a time with actual modules.
3. Tests are conducted as each module is integrated.
4. On completion of each set of tests, another stub is replaced with real module.
5. Regression testing may be conducted to ensure that new errors have not been
introduced.
The process continues from step2 until the entire program structure is built. Top-down
strategy sounds relatively uncomplicated, but in practice, logistical problems arise. The most
common of these problems occurs when processing at low levels in the hierarchy is required to
adequately test upper levels. Stubs replace low-level modules at the beginning of top-down
testing; therefore, no significant data can flow upward in the program structure.
The tester is left with three choices
1. Delay many tests until stubs are replaced with actual modules.
2. Develop stubs that perform limited functions that simulate the actual module
3. Integrate the software from the bottom of the hierarchy upward
The first approach causes us to lose some control over correspondence between specific
tests and incorporation of specific modules. This can lead to difficulty in determining the cause
of errors tends to violate the highly constrained nature of the top down approach. The second
approach is workable but can lead to significant overhead, as stubs become increasingly
complex. The third approach is discussed in next section.
Bottom-Up Integration:Modules are integrated from the bottom to top, in this approach processing required for
modules subordinate to a given level is always available and the needs for subs is eliminated.
26
April 7, 2010
A bottom-up integration strategy may be implemented with the following steps:

1. Low-level modules are combined into clusters that perform a specific software sub
function.
2. A driver is written to coordinate test case input and output.
3. The cluster is tested.
4. Drivers are removed and clusters are combined moving upward in the program
structure.
As integration moves upward, the need for separate test drivers lessens. In fact, if the top
two levels of program structure are integrated top-down, the number of drivers can be reduced
substantially and integration of clusters is greatly simplified.
26. What is automated testing tools and give examples for automated
testing tools which help the programmer.
Ans :- Automation of testing is the state of the art technique where in number of tools will help
in testing program automatically. Programmers can use any tool to test his/her program and
ensure the quality. There are number of tools are available in the market. Some of the tools
which help the programmer are:
1.
2.
3.
4.
5.
6.
7.
Static analyzer
Code Auditors
Assertion processors
Test Verifiers
Output comparators.
29. Explain the purpose of testing? What happens if a software program

is not tested before deployment?
Ans :- The purpose of testing is to show that a program performs its intended functions
correctly, and Testing is the process of establishing confidence that a program does what it is
supposed to do.
Purpose:1. To show that the software works: It is known as demonstration-oriented.
2. Test all functions that are used to run the software which produces results. These
functions are directly related to the business functions. Here, all paths of the software
system are not tested. For instance, there may be an error routine which traps the
errors during the execution. This may not be necessary to test as it is not relevant to
the daily running of the software.
27
April 7, 2010
3. To Show that the software doesnt work: It is known as destruction-oriented. In this

case, all functions including non-business functions are tested to discover the possible
errors. Even non-routine functions are also tested. Exceptions are also tested. However,
once a single error is detected, the testing process stops.
4. To minimize the risk of not working up to an acceptable level: It is known as
evaluation oriented.
Sometimes the entire software will not be tested due to many reasons like inadequate time.
However, all the functions which are critical from the business point of view to the customer
will be tested. The acceptable level is a mutually agreed terms between the customer and the
developer.
28. Describe the software quality assurance (SQA) plan and explain the
SQA activities.
Ans :- How do we define Quality?
Conformance to explicitly stated functional and performance requirements, explicitly
documented
development standards, and implicit characteristics that are expected of all professionally
developed
software. The above definition emphasizes three important points:
1. Software requirements are the foundation from which quality is measured. Lack of
conformance to requirements is lack of quality.
2. Specified standards define a set of development criteria that guide the manner in which
software is engineered. If the criteria are not followed, lack of quality will almost surely
result
3. There is a set of implicit requirements often goes unmentioned. (E.g. the desire of good
maintainability). If software conforms to its explicit requirements but fails to meet
implicit requirements, software quality is questionable.
QA Activities:SQA comprises of a variety of tasks associated with two different constituencies.
1. The software engineers who do technical work like
Performing Quality assurance by applying technical methods
Conduct Formal Technical Reviews
Perform well-planed software testing.
2. SQA group that has responsibility for
Quality assurance planning oversight
Record keeping
28
April 7, 2010
Analysis and reporting.

QA activities performed by SE team and SQA are governed by the following plan:
Evaluation to be performed.
Audits and reviews to be performed.
Standards that is applicable to the project.
Procedures for error reporting and tracking
Documents to be produced by the SQA group
Amount of feedback provided to software project team.
What are the activities performed by SQA and SE team?

Prepare SQA Plan for a project
Participate in the development of the projects software description
Review software-engineering activities to verify compliance with defined software
process.
Audits designated software work products to verify compliance with those defined as
part of the software process.
Ensures that deviations in software work and work products are documented and
handled according to a documented procedure.
Records any noncompliance and reports to senior management.
29. Explain software reliability and how the reliability and availability are
measured.
Ans :- Software reliability, unlike many other quality factors, can be measured directed and
estimated using historical and developmental data. Software reliability is defined in statistical
terms as Probability of failure free operation of a computer program in a specified environment
for a specified time to illustrate, program x is estimated to have reliability of 0.96 over 8
elapsed processing hours. In other words, if program x were to be executed 100 times and
required 8 hours of elapsed processing time, it is likely to operate correctly to operate 96/100
times.
Measurement of reliability and availability:In a computer-based system, a simple measure of reliability is mean time between failure
(MTBF),
Where
MTBF = MTTF+MTTR
The acronym MTTF and MTTR are Mean Time To Failure and Mean Time To
Repair, respectively. In addition to reliability measure, we must develop a measure of
availability. Software availability is the probability that a program is operating according to
requirements at a given point in time and is defined
as:
Availability = MTTF / (MTTF+MTTR) x100%
29
April 7, 2010
The MTBF reliability measure is equally sensitive to MTTF and MTTR. The
availability measure is somewhat more sensitive to MTTR an indirect measure of the
maintainability of the software.
30. During code inspection what are the two main activities occur and
what are its benefits.
Ans :- An inspection team usually consists of four people. One of the four people is an expert.
The expert is expected to be a competent programmer, but he/she is not the programmer of
the code under inspection and need not be acquainted with the details of the program. The
duties of the expert include:
Distributing materials for scheduling inspections

Leading the session,
Recording all errors found, and
Ensuring that the errors are subsequently corrected.
The general procedure is that the expert distributes the programs listing and design
specification to other participants well in advance of the inspection session. The participants are
expected to familiarize themselves with the material prior to the session. During inspection
session, two main activities occur:
1. The programmer is requested to narrate, statement by statement, the logic of the
program.
During the discourse, questions are raised and pursued to determine if errors exist.
Experience has shown that many of the errors discovered are actually found by the
programmer, rather than the other team members, during the narration. In other
words, the simple act of reading aloud ones program to an audience seems to be a
remarkably effective error-detection technique.
2. The program is analyzed with respect to a checklist of historically common
programming errors (such a checklist is discussed in the next section).
Benefits:
31.
Identifying early, errors in the program,

The programmers usually receive feedback concerning his or her programming style
and choice of algorithms and programming techniques.
Other participants are also gain in similar way by being exposed to another
programmers errors and programming style.
The inspection process is a way of identifying early the most error-prone sections of the
program, thus allowing one to focus more attention on these sections during the
computer based testing processes.
Explain with example the system testing and its complexities.

30
April 7, 2010
Ans :- System testing is actually a series of different tests whose primary purpose is to fully
exercise the computer-based system. Although each test has a different purpose, all Work to
verify that all system elements have been properly integrated and perform allocated functions.
System testing proceeds with the following steps: function testing, performance testing,
acceptance
testing, and installation testing. Function testing looks for errors in implementation of
functional requirements, while performance testing does the same for nonfunctional
requirements. In other words, functional testing looks at whether functions are performed,
while performance testing looks at the way the functions are performed, i.e., considerations of
speed, accuracy, security and reliability. Performance testing can be further categorized into
stress testing, which subjects the system to its peak design load, volume testing, which consists
of checking for adequacy of the data structures, configuration testing or testing all specified
configurations, security testing, compatibility testing, environmental testing, etc. Acceptance
testing is done by the customer to test against defined requirements. A final installation testing
step allows the user to exercise the system in its actual operating environment.
A classic system testing problem is finger pointing. This occurs when an error is uncovered,
and
each system element developer blames the other for the problem. Rather than indulging in such
nonsense, the software engineer should anticipate potential interfacing problems and 1) design
error-handling paths that test all information coming from other elements of the system; 2)
conduct a series of tests that simulate bad data or other potential errors at the software
interface;3) record the results of tests to use as evidence if finger pointing does occur; and 4)
participate in planning and design of system tests to ensure that software is adequately tested.
32.
a)
b)
c)
Explain these terms brieflyBenchmark testing.

GUI testing and
Availability testing.
Ans :a) Benchmark Testin:-Benchmark is a standard mechanism to compare with other similar
products. This type of testing is to compare the product with the standard benchmark available.
b)GUI Testin:- Most of the modern software uses GUI method to develop user interface.
These user interfaces are developed using GUI standards. This method of testing is to ensure
the software is developed as per GUI standards and works correctly.
c)Availability Testing:- To ensure the availability of the application to the user by verifying
the user connections, check whether application responds to an input, 24x7 availability time
and number of failed attempts to load a page. The above dictionary of testing types is designed
to be a quick reference to help develop an appreciation, obtain some understanding and
strengthen your testing vocabulary. Some of the testing types/definitions may overlap with
each other and suggest nearly the same meaning. In such cases, it may be appropriate to refer
to more elaborate compendia or specialist material (as provided below) to arrive at a better
understanding.
31
April 7, 2010
33.
Explain statistical quality assurance technique.
Ans :- Statistical quality assurance reflects a growing trend throughout industry to become
more quantitative about quality. For software, statistical quality assurance implies the
following steps
Information about software defects is collected and categorized
An attempt is made to trace each defect to its underlying cause
Using Pareto principle (80% of the defects can be traced to 20% of all possible causes),
isolate the 20% (the vital few)
Once the vital few causes have been identified, move to correct the problems that have
caused the defects.
This relatively simple concept represents an important step toward the creation of an
adaptive software engineering process in which changes are made to improve those elements of
the process that introduce errors. To illustrate the process, assume that a software development
organization collects information on defects for a period of one year. Some errors are uncovered
as software is being developed. Other defects are encountered after the software has been
released to its end user.
Although hundreds of errors are uncovered, all can be tracked to one of the following
causes.
Incomplete or erroneous specification (IES)

Misinterpretation of customer communication (MCC)
Intentional deviation from specification (IDS)
Violation of programming standards ( VPS )
Error in data representation (EDR)
Inconsistent module interface (IMI)
Error in design logic (EDL)
Incomplete or erroneous testing (IET)
Inaccurate or incomplete documentation (IID)
Error in programming language translation of design (PLT)
Ambiguous or inconsistent human-computer interface (HCI)
Miscellaneous (MIS)
To apply statistical SQA table 1 is built. Once the few vital causes are determined, the
software
development organization can begin corrective action. After analysis, design, coding, testing,
and release, the following data are gathered.
Ei = The total number of errors uncovered during the ith step in the software
Engineering
process
Si = The number of serious errors
Mi = The number of moderate errors
Kuvempu University | sahil08red@gmail.com 32
Ti = The number of minor errors
PS = Size of the product (LOC, design statements, pages of documentation at the ith
April 7, 2010
Ws, Wm, Wt = weighting factors for serious, moderate and trivial errors where
recommended values are Ws = 10, Wm = 3, Wt = 1.
The weighting factors for each phase should become larger as development progresses.
This rewards an organization that finds errors early.
At each step in the software engineering process, a phase index, PIi, is computed as; PIi
= Ws (Si/Ei)+Wm (Mi/Ei)+Wt (Ti/Ei)
The error index EI ids computed by calculating the cumulative effect or each PIi,
weighting errors encountered later in the software engineering process more heavily than
those encountered earlier.
EI = (i x PIi)/PS
= (PIi+2PI2 +3PI3 +iPIi)/PS
The error index can be used in conjunction with information collected in table to
develop an overall indication of improvement in software quality.
See chart in book (Page No.35)
34.
Explain the ISO approach to quality assurance system. Or

What is ISO 9001 standard? List the requirements delineated by ISO
9001 to use in the software process
Ans :- ISO 9000 describes the elements of a quality assurance in general terms. These elements
include the organizational structure, procedures, processes, and resources needed to implement
quality planning, quality control, quality assurance, and quality improvement. However, ISO
9000 does not describe how an organization should implement these quality system elements.
Consequently, the challenge lies in designing and implementing a quality assurance system that
meets the standard and fits the companys products, services, and culture.
The ISO 9001 Standard:- ISO 9001 is the quality assurance standard that applies to software
engineering. The standard contains 20 requirements that must be present for an effective
quality assurance system. Because the ISO 9001 standard is applicable in all engineering
disciplines, a special set of ISO guidelines have been developed to help interpret the standard
for use in the software process.
The 20 requirements delineated by ISO9001 address the following topic.
1. Management responsibility
2. Quality system
33
April 7, 2010
3. Contract review
4. Design control
5. Document and data control
6. Purchasing
7. Control of customer supplied product
8. Product identification and tractability
9. Process control
10. Inspection and testing
11. Control of inspection, measuring, and test equipment
12. Inspection and test status
13. Control of non confirming product
14. Corrective and preventive action
15. Handling, storage, packing, preservation, and delivery
16. Control of quality records
17. Internal quality audits
18. Training
19. Servicing
20. Statistical techniques
In order for a software organization to become registered to ISO 9001, it must establish
policies and procedure to address each of the requirement noted above and then be able to
demonstrate that these policies and procedures are being followed.
35.
Checklist for data-reference errors.
Ans :- Checklist for data-reference errors:1. Is a variable referenced whose value is unset or uninitialized? This is probably
the most frequent programming error; it occurs in a wide variety of
circumstances.
2. For all array references, is each subscript value within the defined bounds of the
corresponding dimension?
3. For all array references, does each subscript have an integer value? This is not
necessarily an error in all languages, but it is a dangerous practice.
4. Check for dangling reference problem?
Note:
1. The Dangling reference problem occurs in situations where the lifetime of a
pointer is greater than the lifetime of the referenced storage.
2. Are there any explicit or implicit addressing problems if on the machine being
used, the units of storage allocation are smaller than the units of storage
addressability?
3. If a data structure is referenced in multiple procedures or subroutines, is the
structure defined identically in each procedure?
4. When indexing into a string, are the limits of the string exceeded?
36.
What are the different approaches to software testing?

34
April 7, 2010
Ans :- Testing is a yardstick to ensure the appropriateness of the understanding of needs and
the correctness of the corresponding deliverable (which could be a system, a product or a
service). Understanding is an outcome of the learning process, whereas delivery of an output is
an outcome of the process of understanding. There are multiple ways of testing to ensure
appropriateness/correctness. In the following sections, different types of testing are explained
briefly to gain the knowledge in the area of software testing.
1. Black Box Testing
To ensure the validity of the software application without the need for having its internal
structure
exposed. During the testing, the program code is not available but the executable module is
used. Detailed test plan and proper test environment is required. Black box testing method is
used in most of the applications to ensure the business functions accurately.
2. White Box Testing
It is a method to test the software utilizing its internal structure. The complete code structure
is
available during the test. Normally, programmers use this method to find the errors at the
program level which helps in debugging. This also helps in understanding the behavior of the
program, code review, and data flow and code level test case design.
3. Grey Box Testing
It is a higher level of abstraction and less comprehensive as compared to, white box testing. It
involves business case testing with parts of the internal structure exposed. Used to test the
software through some understanding of its internals and is like looking under hood.
4. Alpha Testing
A person other than the developer carries out testing, in-house, and at various project
milestones.
Since a third person tests the software, a detailed test plan must be provided.
5. Beta Testing
This type of testing is conducted by end-users either after or in parallel with system testing.
Users who are the ultimate owner of the software will test the system before deployment and
the errors will be reported back to the developer. For instance, Microsoft Windows 2000 was
released to a set of users world wide for a limited duration for beta testing. All these users
were using earlier versions of Microsoft operating system. The goal is to test the product by
the end user in all respect.
6. Unit Testing
Unit testing uses both black box and white box methods to test a module against its design
specification immediately after its design. This is normally done by the developer or another
programmer. Unit testing is important and mandatory for all software modules. To illustrate, if
you develop a program which computes simple interest, it has to be tested for all different type
of inputs. This is known as unit testing.
7. Integration Testing
Here an independent tester in association with developers tests the system after the
integration. In large scale business systems, it is necessary to integrate many modules
developed by different people. Once it is integrated, the same has to be tested and known as
integration testing.
8. System Testing
This is a pre-deployment testing to verify whether the developed system meets the requirement
35
April 7, 2010
specifications or not by simulating the target operational environment. This is to verify

whether the system is production ready or not.
9. Acceptance Testing
Here the customer carries out system testing before finally accepting the system as meeting his
stated
requirements. This is normally done by the customer in association with the developer.
Accepting testing is must for all systems. They will test the software with the real data and
conforms the software system for its correctness.
37.
Explain the need for inspection and list the different types of code reviews
38.
Explain black box testing with the help of an example.
Ans :- Functional tests examine the observable behavior of software as evidenced by its
outputs, without any reference to internal functions. This kind of tests is from the user point of
view, which means as if the user is testing as in the normal business functions.
Black box tests normally determine the quality of the software. It is an advantage to
create the quality criteria from this point of view from the beginning.
In black box testing, software is subjected to a full range of inputs and the outputs are
verified for its correctness. Here, the structure of the program is immaterial.
Black box testing technique can be applied once unit and integration testing is
completed.
It focuses on functional requirements.
It is compliment to the white box testing.
The main objective of the black box testing is to find:

1.
2.
3.
4.
5.
incorrect or missing functions

interface errors
errors in data structures or external database access
performance errors
initialization and termination errors
39. Explain how static program analysis is performed so as to identify

errors without executing the program.
Ans :- This strategy helps in identifying errors without executing the program. Peer reviewers
and programmers will use this strategy to uncover probable static errors.
Program inspection:- This is part of the static testing where in the code is tested for its design
standards, possible logical errors, type errors through code walk through. The details have
covered in the previous Chapter.
36
April 7, 2010
Mathematical program verification:- If the programming language semantics are formally

defined, one can consider program to be a set of mathematical statements. We can attempt to
develop a mathematical proof that the program is correct with respect to the specification. If
the proof can be established, the program is verified and testing to check verification is not
required.
There are a number of approaches to proving program correctness. We will only
consider axiomatic approach.
Suppose that at points P(1), .. , P(n) assertions concerning the program variables and
their relationships can be made.
The assertions are a(1), ..., a(n).
The assertion a(1) is about inputs to the program, and a(n) about outputs.
We can now attempt, for k between 1 and (n-1), to prove that the statements between
P(k) and P(k+1) transform the assertion a(k) to a(k+1).
Given that a(1) and a(n) are true, this sequence of proofs shows partial program
correctness. If it can be shown that the program will terminate, the proof is complete.
Static program analyzers:- Static analysis tools scan the source code to try to detect errors.
The code does not need to be executed. It uses most useful for languages which do not have
strong typing.
It can check:
1. Syntax.
2. Unreachable code
3. Unconditional branches into loops
4. Undeclared variables
5. Uninitialised variables
6. Parameter type mismatches
7. Uncalled functions and procedures
8. Variables used before initialization
9. Non-usage of function results
10. Possible array bound errors
11. Misuse of pointers
40.
Write a short notes on

i) Integration testing.
ii) Boundary value analysis.
iii) Quality control.
Ans :- Integration Testing:- Integration testing is a systematic technique for constructing the
program structure while conducting tests to uncover errors associated with interfacing.
37
April 7, 2010
The objective is to take unit tested modules and build a program structure that has been
dictated by design.
Integration testing is a systematic technique for constructing the program structure
There are two methods of integration testing.
1. Top down testing.
2. Bottom up testing.
Boundary Value Analysis:- It is observed that boundary points for any inputs are not tested
properly. This leads to many errors.
Large numbers of errors tend to occur at boundaries of the input domain. Boundary
Value Analysis (BVA) leads to selection of test cases that exercise boundary values.
BVA complements equivalence partitioning i.e. select any element in an equivalence
Examples:
1. For a range of values bounded by a and b, test (a-1), a, (a+1), (b-1), b, (b+1). Consider
If a = 1 and b = 999 then the boundary values would be 0,1,2,999,1000 etc.
values.
size).
4. If internal program data structures have boundaries (e.g., buffer size, table limits), use
input data to exercise structures on boundaries.
of the conditions.
Quality Control:- QC is the series of inspections, reviews, and tests used throughout the
development life cycle to ensure that each work product meets the requirements placed upon it.
QC includes a feedback loop to the process that created the work product. The combination of
measurement and feedback allows us to tune the process when the work products created fail to
meet their specification. These approach views QC as part of the manufacturing process QC
activities may be fully automated, manual or a combination of automated tools and human
interaction. An essential concept of QC is that all work products have defined and measurable
specification to which we may compare the outputs of each process the feedback loop is
essential to minimize the defect produced. Normally, a QC team reviews the development and
38
April 7, 2010
gives guidelines periodically to improve the software quality. They review the code, standards,
process followed at every stages.
41. Discuss the importance of testing. What happens if a software

program is not testing before deployment? Explain
Ans:- Importance:Testing activity cannot be eliminated in the life cycle as the end product must be bug
free and a reliable one. Imagine a situation where in a persons balance in the account reduces
without withdrawing. A wrong marks card reaches the student which may spoil the students
career. Testing must be an integral part of the system development and this process cannot be
eliminated.
Testing is a critical element of software Quality Assurance

Post-release removal of defects is the most expensive
Significant portion of life cycle effort expended on testing
In a typical service oriented project, about 20-40% of project effort is spent on testing. It
is much more in the case of human-rated software.
An example could be, at Microsoft, tester to developer ratio is 1:1 whereas at NASA
shuttle development center (SEI Level 5), the ratio is 7:1. This shows that how testing is an
integral part of Quality Assurance.
42.
Write a note on the following.

(i) Quality of design
(ii) Quality of conformance
(iii) Quality Control (QC)
Ans :- Quality of design:- Quality of design refers to the characteristics that designers specify
for an item. The grade of materials, tolerance, and performance specifications all contribute to
quality of design. As higher graded materials are used and tighter, tolerance and greater levels
of performance are specified the design quality of a product increases if the product is
manufactured according to specifications. Proper standards and documentations are used to
increase the quality standards. Adequate checks must be associated during the development life
cycle of the product.
Quality of conformance:- Quality of conformance is the degree to which the design
specifications are followed during manufacturing. Again, the greater the degree of
conformance, the higher the level of quality of conformance.
39
April 7, 2010
In software development, quality of design encompasses requirements, specifications

and design of the system. The requirements must be gathered formally and there should not be
any ambiguity and must be complete in all respects. Specifications must be elaborated and
defined formally. Design must follow standard methods and process.
Quality of conformance is an issue focused primarily on implementation. If the
implementation follows the design and the resulting system meets its requirements and
performance goals, conformance quality is high.
Quality Control:- QC is the series of inspections, reviews, and tests used throughout the
development life cycle to ensure that each work product meets the requirements placed upon it.
QC includes a feedback loop to the process that created the work product. The combination of
measurement and feedback allows us to tune the process when the work products created fail to
meet their specification. These approach views QC as part of the manufacturing process QC
activities may be fully automated, manual or a combination of automated tools and human
interaction. An essential concept of QC is that all work products have defined and measurable
specification to which we may compare the outputs of each process the feedback loop is
essential to minimize the defect produced. Normally, a QC team reviews the development and
gives guidelines periodically to improve the software quality. They review the code, standards,
process followed at every stages.
43.
Can a program be correct and still not exhibit good quality? Explain.
44. Is code reviews are relevant to the software testing? Explain the
process involved in a typical code review.
45.
Explain the need for GUI testing and its complexity.
Ans :- The growth of Graphical User Interfaces (GUIs) in various applications has become a
challenge for test engineers. Because of reusable components provided as part of GUI
development environments, the creation of the user interface has become less time consuming
and more precise. GUI is becoming mandatory for any application as users are used to it.
Sometime, the user interface may be treated as a different layer and easily separated from the
traditional functional or business layer. The design and development of user interface layer
requires separate design and development methodology. Here the main problem is to
understand the user psychology during the development time. Due to complexity of GUIs,
testing and generating test cases has become more complex and tedious.
46. Describe the important guidelines to be followed in documentation

testing.
40
April 7, 2010
Ans :- Errors in documentation can be as devastating to the acceptance of the program as

errors in data or source e code. You must have seen the difference between following the user
guide and getting results or behaviors that do not coincide with those predicted by the
document. For this reason, documentation testing should be a meaningful part of every
software test plan.
Documentation testing can be approached in two phases. The first phase, formal
technical review, examines the document for editorial clarity. The second phase examines live
test and users the documentation in conjunction with the use of the actual program.
Some of the guidelines to be followed are:
47.
Does the documentation accurately describe how to accomplish each mode of

use?
Is the description of each interaction sequence accurate?
Are examples accurate and context based?
Are terminology, menu descriptions, and system responses consistent with the
actual program?
Is it relatively easy to locate guidance within the documentation?
Can troubleshooting be accomplished easily with the documentation?
Are the document tables of contents and index accurate and complete?
Is the design of the document (layout, typefaces, indentation, graphics)
conducive to understanding and quick assimilation of information?
Are all error messages displayed for the user described in more detail in the
document?
If hypertext links are used, are they accurate and complete?
Write short notes on the following

(a)Inspections and work through
(b)Automated testing tools
(c) Alpha and beta testing.
Ans :- Inspections and work through:- Code inspections and walkthroughs are the two
primary human testing methods. It involve the reading or visual inspection of a program by a
team of people. Both methods involve some preparatory work by the participants. Normally it
is done through meeting and it is typically known as meeting of the minds, a conference held
by the participants. The objective of the meeting is to find errors, but not to find solutions to
the errors (i.e. to test but not to debug).
Automated Testing Tools:- Automation of testing is the state of the art technique where in
number of tools will help in testing program automatically. Programmers can use any tool to
test his/her program and ensure the quality. There are number of tools are available in the
market. Some of the tools which help the programmer are:
1. Static analyzer
2. Code Auditors
3. Assertion processors
41
April 7, 2010
4.
5.
6.
7.

Test Verifiers
Output comparators.
Alfa and Beta testing: - If software is developed as a product to be used by many customers, it
is impractical to perform formal acceptance tests with each one. Most software product
developers use a process called alpha beta testing to uncover errors that only the end user
seems able to find.
The alpha test is conducted at the developers site by a customer software is used in a
natural setting with the developer Looking over the shoulder of the user and recording errors
and usage problems. Alpha tests are conducted in a controlled environment.
The beta test is conducted at one or more customer sites by the end user(s) of the
software. Unlike alpha testing the developer is generally not present therefore the beta test is a
live.
The customer records all problems (real/imagined) that are encountered during beta
testing and reports these to the developer at regular intervals. Because of problems reported
during beta test, the software developer makes modification and then prepares for release of the
software product to the entire customer base.
48.
Explain the difference between codes Inspection and walk through
Ans :- An inspection team usually consists of four people. One of the four people is an expert.
The expert is expected to be a competent programmer, but he/she is not the programmer of
the code under inspection and need not be acquainted with the details of the program. The
duties of the expert include:
Distributing materials for scheduling inspections

Leading the session,
Recording all errors found, and
Ensuring that the errors are subsequently corrected.
The general procedure is that the expert distributes the programs listing and design
specification to other participants well in advance of the inspection session. The participants are
expected to familiarize themselves with the material prior to the session. During inspection
session, two main activities occur:
3. The programme is requested to narrate, statement by statement, the logic of the
program.
During the discourse, questions are raised and pursued to determine if errors exist.
Experience has shown that many of the errors discovered are actually found by the
42
April 7, 2010
programmer, rather than the other team members, during the narration. In other
words, the simple act of reading aloud ones program to an audience seems to be a
remarkably effective error-detection technique.
4. The program is analyzed with respect to a checklist of historically common
programming errors (such a checklist is discussed in the next section).
Walkthroughs:- The code walkthrough, like the inspection, is a set of procedures and errordetection techniques for group code reading. It shares much in common with the inspection
process, but the procedures are slightly different, and a different error-detection technique is
employed.
The walkthrough is an uninterrupted meeting of one to two hours in duration. The
walkthrough team
consists of three to five people to play the role of moderator, secretary (a person who records all
errors found), tester and programmer. It is suggested to have other participants like:
A highly experienced programmer,

A programming-language expert,
A new programmer (to give a fresh, unbiased outlook)
The person who will eventually maintain the program,
Someone from different project and
Someone from the same programming team as the programmer.
The initial procedure is identical to that of the inspection process: the participants are given
the materials several days in advance to allow them to study the program. However, the
procedure in the meeting is different. Rather than simply reading the program or using error
checklists, the participants play computer.
The person designated as the tester comes to the meeting armed with a small set of paper
test casesrepresentative sets of inputs (and expected outputs) for the program or module.
During the meeting, each test case is mentally executed. That is, the test data are walked
through the logic of the program. The state of the program (i.e. the values of the variables) is
monitored on paper or a blackboard.
The test case must be simple and few in number, because people execute programs at a rate
that is very slow compared to machines. In most walkthroughs, more errors are found during
the process of questioning the programmer than are found directly by the test cases themselves.
49.
Explain the background issues and activities of SQA.
Ans :- QA is an essential activity for any business that produces products to be used by others.
The SQA group serves as the customer in-house representative. That is the people who
perform SQA
must look at the software from customers point of view.
The SQA group attempts to answer the questions asked below and hence ensure the
quality of software.
43
April 7, 2010
The questions are:

1. Has software development been conducted according to pre-established
standards?
2. Have technical disciplines properly performed their role as part of the SQA
activity?
QA Activities:SQA comprises of a variety of tasks associated with two different constituencies.
1. The software engineers who do technical work like
Performing Quality assurance by applying technical methods
Conduct Formal Technical Reviews
Perform well-planed software testing.
2. SQA group that has responsibility for
Quality assurance planning oversight
Record keeping
Analysis and reporting.
QA activities performed by SE team and SQA are governed by the following plan:
Evaluation to be performed.
Audits and reviews to be performed.
Standards that is applicable to the project.
Procedures for error reporting and tracking
Documents to be produced by the SQA group
Amount of feedback provided to software project team.
50.
What are the activities performed by SQA and SE team?

Prepare SQA Plan for a project
Participate in the development of the projects software description
Review software-engineering activities to verify compliance with defined software
process.
Audits designated software work products to verify compliance with those defined as
part of the software process.
Ensures that deviations in software work and work products are documented and
handled according to a documented procedure.
Records any noncompliance and reports to senior management.
Explain the notations used for control structures.
44

Software Testing 54

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Software Testing 54

Загружено:

Авторское право:

Доступные форматы

April 7, 2010

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

1. Why do we need to test the software?

To detect errors in a software product.

There are some reasons of software bugs

Poor understanding and incomplete requirements.

Kuvempu University | sahil08red@gmail.com

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

Explain any five types of software testing

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

Quality of conformance is an issue focused primarily on implementation. If the

Amplified errors c:x

Figure 1 illustrates hypothetical example of defect amplification for a software development

What are the main objectives of Formal technical reviews (FRI)?

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

o To ensure that software has been represented according to predefined

Prepare a checklist to be followed while inspection.

Ans :- Prepare/Solve by yourself.

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

Equivalence classes can be defined by:

Explain graph matrices with an example.

Kuvempu University | sahil08red@gmail.com

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

Is a square matrix with number of sides equal to number of nodes

Use a value of 1 to calculate the cyclomatic complexity. The cyclomatic complexity is

Probability that a link (edge) will be executed

Kuvempu University | sahil08red@gmail.com

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

Explain control structure testing.

Ans: - Solve by yourself.

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

Kuvempu University | sahil08red@gmail.com

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

Figure 2 - Testing Strategy.

Kuvempu University | sahil08red@gmail.com

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

- Software Testing Steps

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

Write short notes on

Kuvempu University | sahil08red@gmail.com

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

PDL for PROCEDURE SORT

Explain the importance of testing. What are the Hurdles in testing?

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

Testing is a critical element of software Quality Assurance

Usually late activity in the project life cycle

What are the testing fundamentals? Explain briefly

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

Figure 5 Test Information flow in a typical software test life cycle.

Software Configuration includes a Software Requirements Specification, a

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

o Can be as difficult as the initial design.

Kuvempu University | sahil08red@gmail.com

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

Explain in brief, the review technique adopted in quality assurance.

Kuvempu University | sahil08red@gmail.com

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

Explain the different error checklist for inspections consider the

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

What are the different techniques available to conduct black box

Kuvempu University | sahil08red@gmail.com

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]

[STQA SOLUTION FOR 5TH SEM-MAY/JUN-2010]