Tutorial Sheet No.

Q1. Explain software testing limitations.

Ans. 1: It is very important to understand the limitations of testing. Testing does not assure success or
even prove that a product will be usable. Even the most strictly conducted formal test cannot ensure
that a product will be usable when released. Testing has following limitations:
a) Predefined Testing time not allocated when testing phase begins: One of the limitations of traditional
approach is that in most of the cases deployment date is announced prior to initiation of the project and
in this process developers consume most of the time from the schedule which leaves lesser time for
testing and later due to insufficient testing project fails after deployment or software release is delayed
which incurs cost to business.
b) 100% Testing not possible in case of complex systems: When there is a complex project which
involves lot of interactions with downstream and upstream applications then there are chances of not
performing thorough testing and pass criteria defined are not met due to lots of dependencies on
outside systems.
c) Lack of formal testing and reviews at requirement and design stage of software development life
cycle.
d) Lack of formal unit testing methodology and assembly testing prior to handling the product to
testing team.
e) Lack of efficient and effective automation testing as selection and evaluation of tool is difficult due
to availability of lots of tools and high cost of tools which supports different programming languages
that becomes difficult for testers to understand and learn the programming language. Also most of
the automation tools require writing lots of code rather than just configuring the tool and feeding stable
application to tool to test the critical components and performance parameters.
f) Testing implicit requirements and obvious functionality needs more experienced testers and this is
generally not defined anywhere in project plan and test plan. For Ex- Clicking cancel or remove link
should show some warning edit with okay and cancel button saying that the unsaved information will
be lost. Such requirements are sometimes skipped; however testers ensure that implicit requirements be
tested and fixed.
g) In todays scenario where all applications are required to be developed for mobiles, tablets, and
traditional systems, their interoperability, compatibility with various hardware, and for all available
browsers i.e. all versions of IE, Firefox, Chrome, Mac etc, makes it difficult to ensure the products
stability in all environments and end to end testing.
h) The developer to tester ration has increased to 1:3 for medium sized products, which makes it more
expensive to test the product end to end.
i) Testing does not assure success or even prove that a product will be usable. Even the most strictly
conducted formal testing cannot ensure that a product will be usable when released . Testing cannot
establish that a product functions properly under all conditions but can only establish that it does not
function properly under specific conditions .
j) Testing can be used to show the presence of errors, but never to show their absence!. Testing is only
able to identify the known issues or errors. It gives no idea about defects still uncovered. Testing cannot
guarantee that the system under test is error free.
k) In software testing you cannot test every valid input, invalid input and path.

l) It is not a secret that in some cases it is more effectual both in terms of time, cost, and precision to
conduct an expert or heuristic estimation of a product rather than test it. This is particularly true in the
early steps of a product when gross violations of usability principles abound. It is simply unnecessary
to bring in many partakers to reveal the evident .
m) Exhaustive testing is not possible in current scenario.
n) Complete testing is infeasible. Complexity is the root of the problem. At some point, software testing
has to be stopped and product has to be shipped .
Q2. Explain various software testing limitations.
Ans. 2:
1) You cannot test a program completely
2) We can only test against system requirements
- May not detect errors in the requirements.
- Incomplete or ambiguous requirements may lead to inadequate or incorrect testing.
3) Exhaustive (total) testing is impossible in present scenario.
4) Time and budget constraints normally require very careful planning of the testing effort.
5) Compromise between thoroughness and budget.
6) Test results are used to make business decisions for release dates.
7) Even if you do find the last bug, youll never know it
8) You will run out of time before you run out of test cases
9) You cannot test every path
10) You cannot test every valid input
11) You cannot test every invalid input
Q3. Differentiate between software Verification and Validation.
Ans. 3:

Verification
Are we building the system right?
Verification is the process of evaluating
products of a development phase to find out
whether they meet the specified requirements.

Validation
Are we building the right system?
Validation is the process of evaluating software
at the end of the development process to
determine whether software meets the customer
expectations and requirements.
The objective of Verification is to make sure
The objective of Validation is to make sure that
that the product being develop is as per the
the product actually meet up the users
requirements and design specifications.
requirements, and check whether the
specifications were correct in the first place.
Following activities are involved in
Following activities are involved in Validation:
Verification: Reviews, Meetings and
Testing like black box testing, white box testing,
Inspections.
gray box testing etc.
Verification is carried out by QA team to check Validation is carried out by testing team.

whether implementation software is as per

specification document or not.
Execution of code is not comes under
Execution of code is comes under Validation.
Verification.
Verification process explains whether the
Validation process describes whether the
outputs are according to inputs or not.
software is accepted by the user or not.
Verification is carried out before the
Validation activity is carried out just after the
Validation.
Verification.
Following items are evaluated during
Following item is evaluated during Validation:
Verification: Plans, Requirement
Actual product or Software under test.
Specifications, Design Specifications, Code,
Test Cases etc,
Cost of errors caught in Verification is less
Cost of errors caught in Validation is more than
than errors found in Validation.
errors found in Verification.
It is basically manually checking the of
It is basically checking of developed program
documents and files like requirement
based on the requirement specifications
specifications etc.
documents & files.
Conclusion on difference of Verification and Validation in software testing:
1. Both Verification and Validation are essential and balancing to each other.
2. Different error filters are provided by each of them.
3. Both are used to finds a defect in different way, Verification is used to identify the errors in
requirement specifications & validation is used to find the defects in the implemented Software
application.

Tutorial Sheet No.2

Q1. Explain different levels of testing with their merits and demerits.
Ans. 1. Unit Testing
Unit testing is a procedure used to validate that a particular module of source code is working properly.
The procedure is to write test cases for all functions and methods so that whenever a change causes a
regression, it can be quickly identified and fixed
Benefits
The goal of unit testing is to isolate each part of the program and show that the individual parts are
correct. Unit testing provides a strict, written contract that the piece of code must satisfy. As a result, it
affords several benefits
a. Facilitates Change
b. Simplifies Integration
c. Documentation
d. Separation of Interface from Implementation
2. Integrated Systems Testing
Integrated System Testing (IST) is a systematic technique for validating the construction of the overall
Software structure while at the same time conducting tests to uncover errors associated with
interfacing. The objective is to take unit tested modules and test the overall Software structure that has
been dictated by design. IST can be done either as Top down integration or Bottom up Integration.
3. System Testing
System testing is testing conducted on a complete, integrated system to evaluate the systems
compliance with its specified requirements. System testing falls within the scope of Black box testing,
and as such, should require no knowledge of the inner design of the code System testing is actually
done to the entire system against the Functional Requirement Specifications (FRS) and/or the System
Requirement Specification (SRS). Moreover, the System testing is an investigatory testing phase,
where the focus is to have almost a destructive attitude and test not only the design, but also the
behavior and even the believed expectations of the customer. It is also intended to test up to and beyond
the bounds defined in the software/hardware requirements specifications. Remaining All Testing
Models comes under System Testing
4. User Acceptance Testing
User Acceptance Testing (UAT) is performed by Users or on behalf of the users to ensure that the
Software functions in accordance with the Business Requirement Document. UAT focuses on the
following aspects
All functional requirements are satisfied
All performance requirements are achieved
Other requirements like transportability, compatibility, error recovery etc. are satisfied
Acceptance criteria specified by the user is met
Sample Entry and Exit Criteria for User Acceptance Testing
Entry Criteria
Integration testing sign off was obtained
Business requirements have been met or renegotiated with the Business Sponsor or
representative
UAT test scripts are ready for execution
The testing environment is established

 Security requirements have been documented and necessary user access obtained
Exit Criteria
UAT has been completed and approved by the user community in a transition meeting
Change control is managing requested modifications and enhancements
Business sponsor agrees that known defects do not impact a production releaseno remaining
defects are rated 3, 2, or 1
Q2. Draw the test cases by using equivalence partitioning method for the following situation.
Find out the type of a triangle on the basis of given three input integer values.
Ans.2: The problem statement we note that there are four possible outputs:
Not a Triangle
Isosceles
Equilateral
Scalene
We can use these to identify output (range) equivalence classes:
R1= {<a, b, c> | the triangle with sides a, b, c, is equilateral}
R2= {<a, b, c> | the triangle with sides a, b, c, is isosceles}
R3= {< a, b, c> | the triangle with sides a, b, c, is scalene}
R4= {a, b, c> | sides a, b, c do not form a triangle}
These classes yield the following simple set of test cases:
Sample Test Cases based on Output Domain:

Test Case

Expected
Output

OE1

Equilateral

OE2

Isosceles

OE3

Scalene

OE4

Not a
Triangle

Equivalence Test Cases for the Triangle Problem (Input Domain):

If we base the equivalence classes on the input domain, we will obtain a larger set of test cases. We can
define the sets:
D1= {<a,b,c> | a=b=c}
D2= {<a,b,c> | a=b, ac}
D3= {<a,b,c> | a=c, ab}
D4= {<a,b,c> | b=c, ab}

D5= {<a,b,c> | ab, ac, bc}

As a separate property we can apply the triangle property to see even if the input constitutes a triangle
D6= {<a, b, c> | a b+c}
D7= {<a, b, c> | b a+c}
D8= {<a, b, c> | c a+b}
If we wanted also we could split D6 into
D6={<a, b, c> | a = b+c} and
D6= {<a, b, c> | a > b+c}
Q3.. Draw the test cases by using Boundary Value Analysis method for the following situation.
Find out the type of a triangle on the basis of given three input integer values.
Ans3. Boundary value analysis is also augmented by the single fault assumption principle.
Failures occur rarely as the result of the
simultaneous occurrence of two (or more) faults
In this respect, boundary value analysis test cases can be obtained by holding the values of all but one
variable at their nominal values, and letting that variable assume its extreme values.

T = { <y1nom, y2min>,
<y1nom, y2min+>, <y1nom, y2nom>, <y1nom, y2max->,
<y1nom, y2max+>, <y1min, y2nom>, < 1nin+, y2nom>, <y1max-, y2nom>,
<y1max, y2nom> }
Test Cases Using Boundary Value Analysis: