Unit 1.

1. Define Boundary value analysis with suitable example.

Most of the defects in software products hover around conditions and boundaries. By
conditions, we mean situations wherein, based on the values of various variables, certain
actions would have to be taken. By boundaries, we mean ―limits of values of the various
variables.
• This is one of the software testing technique in which the test cases are designed
to include values at the boundary.
• If the input data is used within the boundary value limits, then it is said to be
Positive Testing. If the input data is picked outside the boundary value limits, then it is said to
be Negative Testing.
• Boundary value analysis is another black box test design technique and it is used
to find the errors at boundaries of input domain rather than finding those errors in the center
of input.
• Each boundary has a valid boundary value and an invalid boundary value. Test
cases are designed based on the both valid and invalid boundary values. Typically, we choose
one test case from each boundary.
• Boundary value analysis is a black box testing and is also applies to white box
testing. Internal data structures like arrays, stacks and queues need to be checked for boundary
or limit conditions. When there are linked lists used as internal structures, the behavior of the
list at the beginning and end has to be tested thoroughly.
• Boundary value analysis help identify the test cases that are most likely to
uncover defects.
Example
A system can accept the numbers from 1 to 10 numeric values. All other
numbers are invalid values. Under this technique, boundary values 0, 1,2,9,10,11 can be tested.

2. State any two advantages and disadvantages of V model

The advantages of the V-Model method are as follows:
• This is a highly-disciplined model and Phases are completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Simple and easy to understand and use.
• Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a
review process.
The disadvantages of the V-Model method are as follows:
• High risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing. •
Once an application is in the testing stage, it is difficult to go back and change functionality. • No
working software is produced until late during the life cycle

3. What are the objectives of software testing?

Objectives of Testing:
1. Finding defects which may get created by the programmer while developing the software.
2. Gaining confidence in and providing information about the level of quality.
3. To prevent defects.
4. To make sure that the end result meets the business and user requirements.
5. To ensure that it satisfies the BRS that is Business Requirement Specification and SRS that is
System Requirement Specifications.
6. To gain the confidence of the customers by providing them a quality product.

4. What is software testing?

Software testing is a method of assessing the functionality of a software program.

5. What is the test case? Which parameter are to be considered while documenting test
case.
A test case is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly. For designing the test case, it needs
to provide set of inputs and its corresponding expected outputs. Parameters:
1. Test case ID: is the identification number given to each test case.
2. Purpose: defines why the case is being designed.
3. Precondition: The prerequisite for running in the system.
4. Input: Actual inputs must be provided, instead of general inputs.
5. Expected outputs: which should be produced when there is no failure?
6. Actual outputs: What is the actual output when the code is executed.
7. Status: If Expected and actual result is same status is Pass otherwise it is Fail.
5. What is static testing ? Advantage and disadvantage.
Static testing is a type testing which requires only source code of the product, not the binaries or
executable. Static testing does not involve executing the program on computers but involves
select people going through the code to find out whether
1. The code works according functional requirement.
2. The code has been written in accordance with the design developed earlier in the project
life cycle.
3. The code for any functionality has been missed out.
4. The code handles errors properly.
Advantages:
1. Static testing start early in the life cycle so early feedback on quality issues can be
established.
2. As the defects are getting detected at early stage so the rework cost most often relatively
low.
3. Development productivity is likely to increase because of the less rework effort.
4. It helps to produce a better product.
Disadvantages:
1. It is time-consuming.
2. The logistics and scheduling can become an issue since multiple peoples are involved.
3. It is not always possible to go through every line of code.
4. Required High- skills.

6. Describe Inspection under static testing.

Static testing is to review the code without executing it. Formal Inspection is the most formal
method in static testing. This method can detect all faults, violations and other side effects. In
this:
1. Thorough preparation is required before an inspection/review
2. Enlisting multiple diverse views.
3. Assigning specific roles to the multiple participants
4. Going sequentially through the code in a structured manner.
There are four roles in this.
1.Author of the code: the person who had written the code
2.Moderator: who is expected to formally run the inspection according to the process.
3.Inspectors: are the people who actually provide review comments for the code.
4.Scribe: who takes detail notes during the inspection meeting and circulates them to the
inspection team after the meeting.
The author or moderator selects review team. The inspection team assembles at the
agreed time for inspection meeting. The moderator takes the team sequentially through the
program code. If any defect is found they will classify it as minor or major. A scribe documents
the defects. For major defects the review team meets again to check whether the bugs are
resolved or not.

7. State purpose of code coverage. How it is used in analyzing coding of software?

Code coverage is used to find out the percentage of code that is covered by testing. It is used for
analyzing the coding software: As product is realized in terms of program code we can run test
cases to exercise the different parts of the code gets tested. Code coverage testing involves
designing and executing test cases and finding out the percentage of the code that is covered by
testing.
It is found by adopting a technique called instrumentation of the code. This instrumented code
can monitor and keep audit of what portions of code are covered. The tools also allow reporting
on the portions of the code that are covered frequently, so that the critical or most-often portions
of the code can be identified.
Code coverage testing is made up of the following types of coverage:
1. Statement coverage
2. Path coverage
3. Condition coverage
4. Function coverage
5. Branch coverage
8. Explain with sample example the use of Decision Tables in the black box testing.
A decision table is a good way to deal with combinations of things (e.g. inputs). This technique is
sometimes also referred to as a cause-effect‘ table. The first task is to identify a suitable function
or subsystem which reacts according to a combination of inputs or events. The system should
not contain too many inputs otherwise the number of combinations will become unmanageable.
It is better to deal with large numbers of conditions by dividing them into subsets and dealing
with the subsets one at a time. Once you have identified the aspects that need to be combined,
then you put them into a table listing all the combinations of True and False for each of the
aspects.
Following decision table shows the sample example of a credit card black box testing
Conditions Rule 1 Rule 2 Rule 3 Rule 4:
Pin Number T T T F
Payment Detail T F F T
Overdue details F T T F

9. Explain the term :

Bug: A bug can be defined as the initiation of error or a problem due to which fault, failure,
incident or an anomaly occurs.
Error: A human action that produces an incorrect result.
Fault: An incorrect step, process, or data definition in a computer program.
Failure: A failure is said to occur whenever the external behavior of a system does not conform
to that prescribed in the system specification. A software fault becomes a software failure only
when it is activated.

10. Explain dyanamic testing

Dynamic testing: The dynamic is testing done by executing program. Main objective of this
testing is to confirm that the software product works in conformance with the business
requirements. The techniques used are unit testing, integration testing, system testing.
11. With the suitable example, explain how ‘Basis Path Testing’ is used to derive the code
complexity for the testing.
Basic path testing is the structural testing technique:
Path testing is based on control structure of the program for which flow graph is prepared
Path testing requires complete knowledge of the programs structure.
Path testing is closer to the developer and used by him to test his module.
The effectiveness of path testing gets reduced with te increase in size of software under
test.
Choose enough paths in a program such that maximum logic coverage is achieved.
Branch Coverage, code coverage, line coverage is also called as basis path testing.
Attempting to cover all the paths in the software is called basis path testing. It‘s the actual
structural testing which is the part of static white box testing. So many times static white box
testing is called basis path testing. The simplest form of path testing is called branch coverage
testing. To check all the possibilities of the boundary and the sub boundary conditions and it‘s
branching on those values. Test coverage criteria requires enough test cases such that each
condition in a decision takes on all possible outcomes at least once, and each point of entry to a
program or subroutine is invoked at least once.
Every branch (decision) taken each way, true and false. It helps in validating all the
branches in the code making sure that no branch leads to abnormal behavior of the application.
For example in the following code all the branches in the program are checked thoroughly. The
decisions are evaluated and are tested whether are not these branches are taken.
1. #include
2. void main()
3. {
4. int i , fact= 1, n;
5. printf(―enter the number ―);
6. scanf(―%d‖, &n);
7. for(i =1 ;i <=n; i++)
8. fact = fact * i;
9. printf (―the factorial of a number is ‖%d‖, fact);
10. }
Data Flow (Code Functional Testing)
Data flow coverage involves tracking a piece of data completely through the software. At the unit
test level this would just be through an individual module or function. The same tracking could
be done through several integrated modules or even through the entire software product—
although it would be more time consuming. During data flow, the check is made for the proper
declaration of variables declared and the loops used are declared and used properly.
Line coverage or code coverage testing:
The most straightforward form of code coverage is called statement coverage or line coverage. If
you‘re monitoring statement coverage while you test your software, your goal is to make sure
that you execute every statement in the program at least once. With line coverage the tester tests
the code line by line giving the relevant output. For example
1. #include
2. void main()
3. {
4. int i , fact= 1, n;
5. printf(―enter the number ―);
6. scanf(―%d‖, &n);
7. for(i =1 ;i <=n; i++)
8. fact = fact * i;
9. printf (―the factorial of a number is ‖%d‖, fact);
10. }

12. State the different errors being found by the static and dynamic black box testing.
Errors found by static black box testing :
Testing the specification is static black-box testing. The specification is a document, not an
executing program, so it's considered static. It's also something that was created using data from
many sources usability studies, focus groups, marketing input, and so on. The tester doesn't
necessarily need to know how or why that information was obtained or the details of the process
used to obtain it, just that it's been boiled down into a product specification. Tester can then take
that document, perform static black-box testing, and carefully examine it for bugs.
The development team may emphasize diagrams over words or it may use a self
documenting computer language. It performs this with the help of :
1. Performing a High-Level Review of the Specification
2. Low-Level Specification Test Techniques
 Overall all the errors in the specifications are found by this testing technic. Word to word
the specifications are scanned and are understood to get the clear meaining of them.
Errors found by dynamic black box testing:
Dynamic Black-Box Testing is as good as Testing the Software While Blindfolded.
Testing software without having an insight into the details of underlying code is dynamic
blackbox testing. It's dynamic because the program is running you're using it as a customer
would. And, it's black-box because you're testing it without knowing exactly how it works with
blinders on.
The testers keep on entering inputs, receiving outputs, and checking the results. Another
name commonly used for dynamic black-box testing is behavioral testing because its testing how
the software actually behaves when it's used.
To do this effectively requires some definition of what the software does namely, a
requirements document or product specification. Tester doesn't need to be told what happens
inside the software "box" , tester just need to know that inputting A outputs B or that performing
operation C results in D. A good product spec will provide tester with these details.
Once tester know the ins and outs of the software tester is about to test, testers next step
is to start defining the test cases. Test cases are the specific inputs that he will try and the
procedures that he will follow when he tests the software.
Partitioning of the data effectively is done for the software and checked.
Data testing is done with respect to boundary conditions , boundary value analysis, sub
boundary conditions.
State testing is done by giving the inputs and gaining the outputs.
It tests the software‘s logic flow.
Generates the state transtition maps.
Software is tested for load and stress conditions.

13. Illustrate process of graph-based testing with suitable example.

i. Black-box methods based on the nature of the relationships (links) among the program objects
(nodes), test cases are designed to traverse the entire graph
ii. Transaction flow testing – nodes represent steps in some transaction and links represent
logical connections between steps that need to be validated
iii. Finite state modeling – nodes represent user observable states of the software and links
represent transitions between states
 iv. Data flow modeling – nodes are data objects and links are transformations from one data
object to another v. Timing modeling – nodes are program objects and links are sequential
connections between these objects, link weights are required execution times.
Steps in graph testing:
i. Build a graph model.
ii. Identify the test requirements.
iii. Select test paths to cover those requirements.
Derive test data so that those test paths can be executed. (Refer dig from S17)

14. Describe structural walk through under static testing.

One of the static testing methods is structural walkthrough. In walkthroughs, a set of people look
at the program code and raise questions for the author. The author explains the logic of the code
and answers the questions. If the author is unable to answer some questions, he or she then takes
those questions and finds their answers.
(i) Walkthroughs are the next step up in formality from peer reviews.
(ii) In a walkthrough, the programmer who wrote the code formally presents (walks
through) it to a small group of five or so other programmers and testers.
(iii) The reviewers should receive copies of the software in advance of the review so they
can examine it and write comments and questions that they want to ask at the
review.
(iv) Having at least one senior programmer as a reviewer is very important.

15. Explain inspection and walk through.

Inspection:
i. Inspections are the most formal type of reviews.
ii. They are highly structured and require training for each participant.
iii. Inspections are different from peer reviews and walkthroughs in the original
programmer.
iv. These forces someone else to learn and understand the material being presented,
potentially giving a different slant and interpretation at the inspection meeting.
iv. The other participants are called inspectors.
v. Each is tasked with reviewing the code from a different perspective, such as a User,
a tester, or a product support person.
vi. This helps bring different views of the product under review and very often
Identifies different bugs.
vii. One inspector is even tasked with reviewing the code backward that is, from the
end to the beginning to make sure that the material is covered evenly and
completely.
viii. Walkthrough:
i. Walkthroughs are the next step up in formality from peer reviews.
ii. In a walkthrough, the programmer who wrote the code formally presents (Walks
through) it to a small group of five or so other programmers and testers.
iii. The reviewers should receive copies of the software in advance of the review so
they can examine it and write comments and questions that they want to ask at the
review.
iv. Having at least one senior programmer as a reviewer is very important.