T.Y. B.Sc.

(IT)
Software Testing
Time : 2 Hrs. 30 min] Prelim Question Paper Solution [Marks : 75

Q.1 Attempt any TWO questions. [10]

10]
Q.1(a) What is an error, failure and fault? [5
[5]
(A) x A failure is nonfulfillment of requirements, A discrepancy epancy between
tween
actual result or behavior (Identified in Requirement Specification)
pecification)
cation)

r
x Failure in a software means the software doesnt t perform
orm functional
function
requirements, the failure occur in S/W because e of fault.
ult. Every fault, or

ka
Defect or Bug in S/w is present since it was developed changed.
eveloped or changed
x A failure has its roots in a fault in the software. ware. These fault is also
called a defect or internal error programmer
rammer generally
nerally use a term
te Bug
for fault e.g. of fault e.g. of faultt can be the programmer
program might be
wrongly programmed or forgotten n code in application.
x It is possible that a fault iss hidden by one or more other faults in
an different parts of application.
the masking defects have
ion. In
n th
that
at case, A f
e been corrected
The cause of fault or defect is an error or mistake
failure only ooccurs after

mistakes by person. E.g.

wrong programming g by developer
eloper or A mescindersfanding
mescindersfa
mesc of commands in
programming language.
nguage..
However faults
ults may
ay be even cause environmental conditions like
cause by env
al
radiation, magnetism
etism etc. that introduce
introd Hardware
Ha problem.

Q.1(b) Explain success factor

factors of
f review proce
process. [5]
(A) Implementing
ementing
menting formal reviews
rev easy as there is no one way to success
is not e
dy

and re are no. of ways to fail. Critical

nd there C success factor for formal reviews
are
1. Find a champion
2. Pick things that really counts
planned & track review activities
3. Explicitly pla
participants
4. Trained particip
Vi

5. Manag peoples issues

Manage peopl
6. Follow the rules but keep it simple
7. Continuously
Continu improve process & tools.
Report results
8. Repo
9. JJust do it.

1014/BSc/IT/TY/Pre_Pap/2014/ST_Soln 1
 Vidyalankar : T.Y. B. Sc. (IT)  ST

Q.1(c) Explain V-model. [5]

(A)
SYSTEM Acceptance
ANALYSIS Testing
System Integration
Design Testing
Software Unit
Code Testing
S/w
S/w System TEST
ST
DEVELOP
LEVELS

r
MENT Testing Testing
LEVELS

ka
Vmodel was developed to address some of problem roblem experience using
traditional waterfall approach defects were re being
ng foun
foundd to late in li
life cycl
cycle
testing was not involved in until end of project ct testing also added
ad load time
an due to its late involvement.
The Vmodel provides guidance that testing needs to begin b as early as
possible in life cycle.
Vmodel shows testing is not ot only execution
execution base activity
act there
th are variety
of activity that need to perform
perfor
orm
m before end of cod phase.
coding pha
These activities should d be carried
ied oout in paralle development activities
parallel with d
and tester needs to work can perform these activity
k with developer, so tthey ca
and produce a good ivity result.
ood activity
al
Therefore in n Vmodel
odel s/w tester is involved
involve in development team from
day1.
Vmodelel was uses 4 test levels, each
ea with
wit there own objectives.
dy

Q.1(d) Explainn decision table Bas

Based testing
test with example. [5]
(A) Decision
ion Table base Testing
Testin :
It has been use to repre
represent & analysize & complex logical relationship
repres
decision table are Idle f for describing situation in which no of combinations
of actions are taken
t under
u verifying set of conditions.
A decision table has
ha 4 portions.
Vi

The
Th leftmost column
co is stub portion, and to the right of it is entry portion.
The condition portion is denoted by condition & action portion is denoted by
expected
exp o/p.
o
Consider
Conside e.g. of triangle function.
Condition stab
Cond

2
 Prelim Paper Solution

C1 : a < b + c F T T T T T T T T T T
C2 : b < a + c  F T T T T T T T T T
Condition C3 : c < a + b   F T T T T T T T T
stab C4 : a = b    F F F F T T T T
C5 : b = c    F F T T F F T T
C6 : a = c    F T F T F T F T

a1 : Not a ' 3 3 3

r
a2 : Eq. V ' 3
Action a3 : Fso ' 3 3 3

ka
stab a4 : satan D 3
a5 : 3 3 3
Impossible

Q.2Attempt any TWO questions. [10]

Q.2(a) What is testing? Explain fundamental
an ental principles
ciples of testing.
testin [5]
(A) Testing is an umbrella activity conducted throughout life cycle of software
cted throughou
to identify bugs or defects or faults, present in software.
softw
Testing can be identify both th syntactical
syntactical as well as
a logical
logica error present in
software.
General principles off testing
ing are :
1) Testing showsws the presence of defect there absence.
defects, not th
al
2) Exhaustive e testing
ng is not possible.
3) Testing g activity
y should start as early
ea as possible
4) Defects
ects tends to cluster together
together (Group
toget (G of similar elements)
5) The e pesticide paradox
parado
dy

6)) The test is context dedepended.

7) False
alse of assuming that no fa failure means useful system.
8) An efficient testing w will conducted by independent third party i.e.
wi
professional software testor groups.
9) Test cases rrequire for testing a software must be planned long before
testing
esting begins a and it must be traces sable to costumer requirement
Vi

ch extend from requirement document.

which

Q.2(b)
Q.22(b) Define
Def software. Explain the characteristic of software.
soft [5]
(A)
A) Instruction : Any programmable excitable statement is called Instructions.
Instruct
A set of instruction which are executable sequentially to get desired output
is called program.
A set of programes which when executed sequentially to get desired result
could software.

3
 Vidyalankar : T.Y. B. Sc. (IT)  ST

Characteristics of Software :
1) Software cannot be manifctured, it is always developed in classical
sense.
2) Software does not wareout i.e. software can be upgrade or modified
3) Availability : Software should be easily available to all user.
4) Reliability
5) Flexibility
6) Security
7) Useability

r
8) Maintainability

ka
9) Portability

Q.2(c) Explain psychology of software testing. [5]

(A) Psychology of Testing :
1) The people made mistakes but they y do nott like to admit them.
th One goal
an of testing software is uncoverr disturbancing rbancing between software
softwa and
specification or costumer needs, therefore efore failure found must be
reported to developer.
2) Can developer test hiss own prograprogram?,
progr important & frequently
m?, it is on iimporta
asked question
The universal valid lid answer does not exist, if ttester also author of
not exis
program, they must examine their eir own w critically.
work crit
al
3) If developer per implements
lements a fundamental
fundam design error e.g. if they
misunderstand
rstand the conceptual formation
formatio
for n then it is possible that he or
she may not find d these using their
th own test.
4) On n the other hand it is an a advantage
adva nta to have a good knowledge of own
test object it is not necessary
necessary to
n t learn test object and therefore time is
dy

saved,
ved, Management has to decidede when it is the advantage to save time
even
ven with the disadvantage
disadvant of blindness for their own errors.
5) Independent testing team te tends to increase quality & comprehensiveness
of the test ttester c can took at the test object without Bias (partiality).
It is not their product
p and possible assumption & unisunderstanding of
Vi

the tester.
tes The
T tester must acquire necessary knowledge of the test
object in order
or to create a test cases with corresponding time and cost.
The tester
test comes along with deeper testing knowledge, developer which
doesnt
doesn have or must first acquire.
6) It is job of the tester to report failure and disturbances observe to
management. The manner of the reporting can contribute the
cooperation between developer and tester.
7) There is often problem that failures found during testing are not
reproducible for developers in development environment.

4
 Prelim Paper Solution

8) Mutual knowledge of their respective task encourages cooperation

between tester and developer. Developer should know basics of testing
and tester should have basic knowledge of software development.

Q.2(d) Explain fundamental test process. [[5]

(A) Fundamental test process :

r
Begin

ka
Planning and

Analysis and design

an Implementation and
Execution
xecution
Control
Contr

Evolution of the test exit criteria

criter
al
Post activity
ost testing activit

end
dy
Vi

5
 Vidyalankar : T.Y. B. Sc. (IT)  ST

Q.3 Attempt the following (any TWO) [10]

Q.3 (a) Explain waterfall model with its advantages and disadvantages. [5]
(A)

Need wish,
policy laws

r
User Requirement

ka
System Requirement

Global Design
an Detailed
iled Desig
Design
gn

Implementation & Coding

Test
Testing
al
Development
D evelop & Maintenance

The WATERFALL MODEL was one on of the

t earliest model to designed. It is
one of the systematic & sequential a approach towards software development
dy

waterfall
fall model develop ssoftware using Analysis, Analysis Design, Coding,
Testing, maintenance.
ng, Deployment & mainten
main
The arrows in these model is unidirectional. It assumes that developer shall
get all requiremen single attempt. ? these model is suitable only for
requirement in sing
static
tic requirem
requirements.
requirements are analysed and gather from customer, the
Once all requirem
Vi

requirements ar
re are converted into Low Level and High Level Design.
The design canc be Logical Flow, Diagramatic Represents Flowchart, Data
Flow Diagram
Flo Diag of software. The actual conversion of software design, into
program code is done in software coding. Coding is directly depended on
system Design. As thy design is simple the coding is also easier. The
syst
programmer select appropriate programming language and start soft ware
coding.

6
 Prelim Paper Solution

Executable are tested as per the test plan in system testing. The software
are executed to find bugs defects present if any
Finally successful software is deployed to the costume and future activities
are handled through maintain advantages :
1) It is one of the oldest systematic & sequential approach towar towards
software development.
2) All the phases of software development are clearly defined ined i.e.,, Each
Eac
team member should know when his/her responsibility y in development
evelopment
process.

r
3) It is one of the time consuming model because ones requirements
uirements are

ka
gathered from costumer, the work model is available only after the
deployment. Costumer needs to specify all their
heir requirements softwa
software
development but it is often difficult forr any costumer
ostumer to give all their
requirements explicitly.

Q.3 (b) Explain different levels of testing.

an g. [5]
(A) According to Vmodel of Software re Development
velopment there four different levels
fou diffe
of testing
1) Unit/Component/Module e Testing :
x A component testing sting is also known as Unit, module & program testing,
it searches for functionality of software that
or defectss and verifies functiona
f
are separately
ately testable.
estable.
al
x In unit testing, the entire softwa divided into smallest workable
software is di
module
ule called
ed as unit and each a ev every
e unit is tested separately to
ensure
nsure thatt it is working prproperly.
x Advantages of Unit TestingTesti are
a) Error identification
identifi become simple
beco
dy

b) Error propagation
propagat gets minimize
c) Overall testing timet will reduce
x The following test are a performed on an individual module during unit
testing.
Unit Testing Consideration
Un
Vi

Modu or Unit or
Module  Boundary Condition Testing
BBT
Component  Local Data Structure
 Independent Path Testing
WBT
 Event Handler

a) In Boundary Condition Testing Individual module is tested on

their extremes boundaries, because maximum number of errors
do occurs on boundaries rather than its operation bound.

7
 Vidyalankar : T.Y. B. Sc. (IT)  ST

b) Local data structure testing ensures the validity of data

structure in software module
c) In independent path testing tester tests all the independent
path in module are working properly or not.
d) In interface testing, tester tests the interface of module with
ule w
the system
e) Finally all error handling paths are tested to ensure sure that
at th
the
module is working properly as an individual.
x Component testing may include testing of functionality
tionality
ty & specific

r
nonfunctional characteristics such as resource ce behavior,

ka
performance testing, & structural testing g test cases are derived
from the driver class to test their stuffs.
s.
Unit testing is also called as Grey Box
x Testing
ng (GBT)

2) Integration Testing :
an x Once all the modules are tested sted properly.
operly. Tester needs integrate
need to int
them as per the design of software ftware to ensure tthat it will work
properly as whole
x There are two typess of Integration testing i.e. i.e
Top down Integration
ation
n
Bottom up Integration
tegration
x In top downwn integration module gets added in system
egration one by one modul
where as in bottom integration
ottom up integratio
integrati conducted cluster by cluster
n is co
al
integration.
gration.
x Regression
egression testing is perperform al along with integration testing to
perform properly whenever there is any
ensure that system will perfor
change in software.
softwar
dy

x Integration testing test in interfaces between components, interaction,

to different parts of system such as an o. s., file system &
interfaces between ssoftware & hardware.
x Integratio testing is after carried out by integrator but preferably
Integration testi
by specific
spec integration
int tester or testor team depending on structural
req
requirement of system. Integration testing can be categorized as
Vi

follows
a) Top Down
D Integration :
In these, testing takes place from top to better following the
control flow or architectural structure e.g. starting from GUI or
main menu.
Components or system are substituted by staff.
b) Bottom Up Integration
Bottom up testing takes place form bottom of control flow upwards.

8
 Prelim Paper Solution

Components or system are substituted by drivers. (Cluster by cluster

testing)
c) Functional Incremental : Integration & testing takes place on the
basis of functional specification.

3) System testing :
x It is concerned with behavior of whole system or product uct as defined
efine
by the scope of development project or product
x System testing may include test based on requirementement specification,

r
business process, use cases, system behavior, vior, interactions
eractions with

ka
operation system & system resources.
x System testing is most often the final testest
st on behalf of developme
development
to verify that the system to be delivered
ered meets
eets spec
specification
ification a
and its
purpose may be to find as many defects
fects as possible.
x Most oftenly system testing is curried d out by specialist testor f from
anindependent third party
x System testing should investigate
vestigate Nonfunctional
ate both functional & Non
requirements of the system. m. Typically
Typically nonfunctional
nonf requirement
includes performancence & reliability system testing
testin of functional
requirement starts
arts by using most appropriate
approp specification
s based
technique (BBT)
BT) for aspect system to be tested.
ect of the syste
x The following
ing are
e testing to be condu
conducted dduring system testing
al
1. Performance
formance e testing
2. Load/Stress
oad/Stress
tress
3.. Recoveryry
4. Security testing
dy

4) Acceptance
cceptance Testing :
x When development org organisation has perform its system test & has
corrected or all most
mo defects, the system will delivered to user or
costumer for acc
acceptance testing these test should answer following
question
questio such as
system be released?
a) Can sys
Vi

b) What
Wha if any are the outstanding risk?
c) Has
H development meet their expectations?
x It is most often the responsibility of user & costumer, although
other stoke holder may be involves as well. The goal of acceptance
testing is to be established a confidence in the system, part of the
system or specific nonfunctional characteristics.
e.g. Useability of system

9
 Vidyalankar : T.Y. B. Sc. (IT)  ST

Acceptance testing is most then focused on a validation type of

testing, where by we are trying to determine whether the system is
fit for the purpose. Finding defects should not be main focus of
acceptance testing if generally perform on s/w to decide whether
s/w is simply accepted or rejected.

Q.3 (c) Explain functional and non functional testing. [

[5]
(A) A test type is focused on a particular test object which could uld the testing of
function to be performed component or system,

r
A nonfunctional quality characteristic such as reliability eliability useability; A

ka
structure or architecture of system or component;; or related ated to change i.e.
confirming the defects have been fixed and looking ng for unintended changes.
king chang
i.e. Regretion Testing. Depending on test objectives,
ectives,
s, a different testing
testin will
be organised.
1. Testing of function [functional testing] ting] The
he function of system
sy is what
w
an is does. This is typically describe e in requirement specif specification,
functional specification & in usese cases.
There may be some functions ons That
hat are assumed to provided that are
t be prov
not documented as well the
ll as not tth e part of rerequirement for system
requirem
functional tests are based ed on these functions, describe in documents or
fu tions, descri
understood ny the he testor. Functional
Functional testing
tes considers the specified
co
behaviour & is often also reffered as Bla Black Box testing or Behavaioural
or Performance
ance testing.
sting
al
Testing functionality
onality can be done
don from two prospective Requirement
based or Business Based.
ess Process Base
A) Req. Based testing us uses a specification of the functional
Requirements for the system as the basis for designing test cases. A
dy

good way to start is to useus the table of content of the requirement

initial test inventory or list of items to test. As a
specification as an iiniti
also priorities a requirement based on risk criteria
testor we should als
and use tthese to prioritize the test. These will ensure that the
critical test are included in testing efforts.
important & cr
importa
Business Process
(B) Bus Pr Base testing uses knowledge of business processes.
Vi

Use cases
cas are very useful basis for test cases for business
prospectives.
prosp
The technique use for functional testing are often specification
Th
based but experience based technique can be used as a part of test
design in functional testing, a model may be developed such as state
transition model re use case model.
2. NonFunctional Testing [Testing of s/w product ] (PERFUM)

10
 Prelim Paper Solution

1. A second target for testing is testing of the quality characteristics

or nonfunctional attributes of the system here we are interested in
How well or fast something is done. We are testing something that
we need to measure on scale of measurement e.g. time to respond.
Nonfunctional testing, as functional testing is performed att all test te
levels. NoFunctional testing includes performance testing, sting, load,
oad
stress usability, maintaence, reliability & portability testing. It is
the testing of How well the system, work.
To the characteristics & sub characteristics of the he software
ftware to be

r
tested under nonfunctional testing are as follows: lows:

ka
1. Functionality Subcharacteristics :
Suitability, Acuracy, Security, Interoperability,rability, complaints. The
perability, These
deals with functional testing.
2. reliability  Sub characteristics 
Maturity, facect Tolerance, Recoverability
coverability
ility & complaints.
complaints
an 3. Usability  Sub characteristics cs 
Understandability, Learnability, attractiveness.
ability, Operability, attract
attractiveness
4. Efficiency  Which is divided d into Behavior & resource Utilisation.
U
5. Maintainability : Sub b characteristics :
Analyzability, Changeability,
hangeabilit
eability, Testability,
y, Stability, Test
Testability
6. Portability : Subub characteristics
teristics :
Adaptability,
ty, install Coexistence,
tall ability, Co
Co
existe
existence, ReReplaceability.
al
Q.3(d) Explain maintenance
ntenance
ce testing. [5]
(A) Maintenancece testing
g:
1) Oncece deployed, system is often
ofte in service
se for year or even decades during
operational environment is often corrected,
this time the system & its oper
dy

change
nge or extended. Testing
Te i.e. executing during these life cycle period
i.
is called Maintainance
Mainta Testing.
Maintainance Te
Testi
2) Maintainance testing is different from maintenability testing, which
defines how easy
ea it is to maintain the system.
3) The develop
development a and test process applicable to new developments doesnt
nge fundamentally
change fundame for maintainance purpose the same test process
Vi

steps will be apply & depending on size & risk of the changes made,
levels of testing are carried out during maintainance testing. A
sseveral le
component test,, system test, Acceptance Test.
compon
4) A m maintainance test process useally begins with the receipt of an
application for a change. The test manager will use these as basis for
a
producing test plan.

11
 Vidyalankar : T.Y. B. Sc. (IT)  ST

On the receipt of new or change the specification, corresponding test

cases are specified or adapted. Once the necessary changes have been
made, regression testing is performed.
Useally maintainance testing will consist of two parts
i) Testing Changes
ii) ffected
Regression Test to show that rest of system has not been affected d by
maintainance work. The maintainance testing will perform m on software
ftwar
under following condition.
A) If costumer or end user requires support or they are e not understanding

r
some of the functionality of s/w.

ka
B) When developer wants to enhance / upgrade a software.
oftware.
e.
C) When any changes are informed by user.

Q.4Attempt the following (any TWO) [10]

[10
Q.4(a) Explain phases of review process. [5]
(A) anReview process vary from informal mal to formal i.e. (well structured
structu &
Regulated)
Although inspection is most documented forma review ttechnique the
ented and formal
review process consist of six ix
x main steps.
step
1) PLANNING.
i) The review process for particular
particular review process begins with
Request for
or Review
view by the author to t moderator.
mode The moderator is
often assign
ssign too take care of scheduling
scheduling if review that means the
sc
al
time,, date,, venue, agenda & invi invitation
ta of review is made by
moderator.
oderator.
ii) On a project level, the projec
project planning needs to allow time for
rework activities,
review & rewor activities providing engineers with time to
dy

thurrowly participate
participa in rereview.
iii) For more formal reviews,
revie
re the moderator always perform an entry
formal exit criteria.
check & defines form
for

KICKOFF
2) KICK
KICK OFF
OFF
i) An optional step in review process in kick off meeting the goal of
Vi

these mmeeting is to get everybody on same wavelength regarding

document under review & to commit to time that will be spent on
docum
ch
checking.
ii) Also the result of entry check & exit criteria are discussed in case
of more formal review.
iii) Roll assignment, checking rate, the pages to be check process
changes & possible other questions regarding formal reviews are also
discuss during this meeting.

12
 Prelim Paper Solution

3)
i) The participants who are individualy on document under review using
the related documents, procedure rules & checklist proper. The
individual participant identify defects according to their
understanding of document & role.
ii) All issues are recorded preferably using logging form rm spelling
ling
mistakes are recorded on document under review but not mentioned
tione
during review meeting.
iii) A critical success factor for thurrow preparationtion is no. of pages
checked per hour, these is called Checking Rate.
te.

4) REVIEW MEETING:
i) Logging Phase:
Discussion Phase
Decision Phase
During logging phase, the issuess e.g. defects
efects that have been
b identified
ide
during preparation phase are re mention phase by phase,
pha reviewer
re by
reviewer & are logged either her by author or recorde
recorder.
A separate person like recorder or scriber present in logging phase to
scriber is pre
log defects encouraged ged during review process.
To ensure process ss & efficiency,
ency, no discussion, the items are logged
n real dis
discussion
& then handled d in discussion
scussion phase. A ddetailed discussion on whether or
not an issue e is defects meaningful,
ects is not meaning
meaningf ul, as it is much more efficient to
simply log
og it & proceed to next defect.
def
Duringg logging phase the focus is on logging
lo as many defects as possible
within
thin certain time frame.
To ensure these, moderator
mo tries to keep good logging rate i.e. no. of
tri
defects
fects logged per minute.
min
As chairperson of discussion
discus
dis meeting the moderator takes care of
peoples
eoples issues. All the d defects logged in previous phase are discussed in
detail during d discussion phase.
discussi
At the end of meeting
me a decision on document under review has to be
madede by
b participant
partic based on formal exit criteria. The most important
exit criteria is no. of critical or major effect is avg. no. of major or
critical defect
d found per page.

REWORK:
5) REW
Based on defects detected, author will improve document under review
stepbystep. Not every defect i.e. found leads to rework. It is the
authors responsibility to judge if defects has to be fixed. If no. of

13
 Vidyalankar : T.Y. B. Sc. (IT)  ST

defects per page exceeds the exit criteria then only the rework should
be conducted for author.

6) FOLLOWUP:
The moderator is responsible for ensuring that satisfactory action have
ion ha
been taken on all logged defects, process improvement suggestion ggestionn &
change request. Although the moderator checks to make ke sure e that
tha
author has taken action an all defects, it is not necessaryry for moderator
to check all corrections in detail for more formal review
view type
pe moderator

r
checks only for complains to exit criteria i.e. during followup
ng followup moderator

ka
keeps track on those errors which are encounteredered during
uring logging phase
& their elimination process.

Q.4(b) Explain roles and responsibilities of members rs present in revi

review [5][5
process.
(A) anThe participant in any type of formal al review adequate knowledge
w must have adequ kno
of review process, the best & most efficient nt review situation
situa occurs when
oc
participant gains. Some kind of f adv. fo work during rreviewing. The
forr their own wor
following are the members & responsibilities
responsibilities in review process.
re proces
1) Moderator / Manager: er:
It is a chairpersonson of the e entire
enti review process.
process He/she determines
incorporation with author, type of review,revie approach
app & composition of
review team. m. The moderator is responsible
responsibl of scheduling of review
re
al
process.
Moderator
rator prepares
pares policy, plan
pla objectives
object & review process.
Thee training of reviewer can conducted
cond by moderator the moderator
performs chec & follow up on rework, in order to control, the
forms entry check
dy

quality
ality of input & output
outpu of rereview process.
Moderator can also defdefines exit criteria.
2) Author:
uth
Author is writer
writ of the
t document under review, the authors goal should
be learn to t as m much possible with regards to improving quality of
document
cume but also to improve his or her ability to write futures
Vi

documents.
The authors
auth task is to eliminate under areas & to understand the
defects found.
defect
If aauthors document exceeds exit criteria then author must involved in
the rework phase.
3) Scriber / Recorder:
3
During logging phase recorder has to record each defect mentioned and
any suggestions for process improvements

14
 Prelim Paper Solution

Reviewer:
The task of reviewer is to check authors documents for defects the levels
of domain knowledge or technical expertise needed by reviewer will depend
on type of review & type of document which is under review.
The reviews should be chosen to represent different prospective & rates in
review process. In addition to document under review the material
al reviewer
wer
reviews includes source, standards, checklist etc. The sole responsibility
esponsibility
ility is
to review authors document & try to find as many defects cts as present in
document.

Manager:
The manager is involved in reviews as he/she he decides on execution of
reviews, allocates time in project schedules & determines
ermines whether rreview
process object have been met. The manager providing
ger is also responsible for providin
p
readymade tools, review training if requested
uested by participants.

Q.4(c) Explain goals and key characteristics

aracteristics
ristics of walkthrough
walkth and [5]
Inspection.
(A) Walkthrough :
1. Walkthrough is characterized erized by author of document
racterized docume
d under reviewing
guiding participantnt through document and h her thought process, to
his or h
achieve common on understanding
erstanding & to gathe feedback.
gather a fee
2. Walkthrough gh is specially
ecially useful if people
peo from
fro outside s/w discipline are
present, who are re not used to or cacannott ea
canno easily understand s/w documents.
The content of f document is ex step by step by author, to rich the
explain st
consequences together information. Within a walkthrough
nsequences on changes or ttogeth
the author does mo most of the preparation the participants who are
selected.
lected. From different
differe departments
depa & document in advance.
3. Walkthrough is specially
specia useful for higher level document such as
requirement specification & architectural documents.
equirement specificatio
specificati
4. In walkthrou
walkthrough the reviewer should go through all requirements &
specification
specificati of product
p to be develop & if require any modifications or
suggestion
ggest or new
n ideas will be given to another as feedback
x The goals of walkthrough are
1. To present
pr document to stack holder both within an outside the s/w
discipline
dis in order to gather information regarding topic under
documentation.
2. To explain [knowledge transfer] & evaluate content of document
3. Establish a common understanding of document.
4. To examine & discuss validity of proposed solution &
5. Viability of alternatives.

15
 Vidyalankar : T.Y. B. Sc. (IT)  ST

x Key characteristics of walkthrough

1. The meeting is led by author often separate scribe is present.
2. The seniria may use to validate content
3. Separate permeating preparation for reviews is optional
4. The current requirement of product compare with similar lar ap
app.
product.

Inspection :
1. Inspection is most formal review type, the documentt underr inspection is

r
prepared & check thoroughly before meeting, ting, comparing
mparing work

ka
product with its sources & other referenced nced documents,
ocuments, & using
rules & checklist as inspection is validation
dation
ation criteria (Acceptance
(Acceptan
testing)
? Checklist mechanism is must
2. In inspection meeting defects found und are e logged & any discussion
discussio is
an postponed until discussion phased, these makes inspe meeting
inspection m
very efficient meeting
3. In inspection meeting all defectss are
are discussed, solve,
s & ma
make a decision
on them whether to o accept or reject inspect
inspection is pperformed by an
inspector.
Using checklist mechanism
echanism
x The goals of Inspectionsions are
nspections
1. To help p authorr to improve the quality
qualit of documentation under
al
inspection
ection
2. To o remove defects efficiently,
efficien early as possible.
as e
3. To remove defects efficiently,
effic as producing documents with higher
level of quality
dy

4. To train new emplo

employer in oorganisations development process.
x Key y Characteristics of I Inspection
Inspe are
1. It is usually led by ttrained moderator
2. It uses define
de goal using process
goa
3. If involv peer to peer common to examines product
involves pee
4. Rul checklist are use during preparation phase
Rules & che
Vi

5. Defects found are documented in logging list or issued log

6. Follows
Follow up is carried out by applying exit criteria.

Q.4 (d) Explain static analysis by tools.

.4(d)
(A) x Coding
C standards
x Code Metric
x Code Structure

16
 Prelim Paper Solution

Static analysis is an examination of req. design & code which differs from
dynamic testing in no. of following ways
1. Static analysis is perform on requirement, design or code without
actually executing s/w being examine
2. It is ideally perform before types of formal reviews
3. Static analysis unrelated to dynamic properties of requirements,
ents, design
sign
& code such as test coverage
4. The basic goal of static analysis is to find defects whether
ether or not they
may cause failures

r
ka
The are three diff. methods to perform static analysis y
ysis
1. Coding standard :
Checking of coding standards is the mostt welknown own feature during static
s
analysis. The first action to be taken iss to define
efine a coding standard
standa
The coding standards are platform dependent, dent, usually a coding
co standard
stan
consist of set of programming
an ng rules,
s, naming conventions
convent & layout
specification. It is recommendedmended for s/w tester to t adopt
adop existing
standards. The main advantagentage of coding standard is that iit saves lot of
time & efforts during testing.
esting. Main reason
reason for adopting
ad standard is that
the readymade tools ls are
re available which supports
su that standard, so
overall testing efforts
forts will reduced.
2. Code metric :
al
When performing
orming static code analys useally information is calendared
analysis useal
about structural
ructural
al attributes of cod frequency of comments in program,
code, freq
depth h of nesting,
ng, cyclomatic complexity
co & LOC.
Cyclomatic
clomatic complexity metric is bas based on no. of decision in program. It is
veryy important for testor
t because it provides indication of amount of
becau
dy

testing
sting necessary to practically
prac avoid defects using cyclomatic
complexity
omplexity we can also get no. of independent paths in program the e.g.
of
f code metric [refer notes]
no
n
3.
3 Code structure
structur :
There are many different
d kinds of structure used in static analysis but
frequently
eque used code structure are
Vi

1. Control Flow Structure :

It addressed
ad sequence of instruction during execution it provides
how the program structure is executed when a tester run the
ho
program. It can also be used to identify unreachable (Dead) code.
2. Data flow structure
It shows how the data acts as they are transform by programs.
3. Data structure

17
 Vidyalankar : T.Y. B. Sc. (IT)  ST

It refers to organization of data itself, independent of program

when data is arrange as list, queue, stack or other well define data
structure, algorithm for creating modifying or information about the
data while it provides lot of information about the data while
designing a test case.
Static analysis by tools is useful because of following reasons.
1. Early detection of defects prior to test execution
2. Early warning about suspicious aspects of the code, design or
requirements.

r
3. Identification of defects not easily found in dynamic
namic testing.
sting.

ka
4. Improved maintainability of codes & design gn seens
ns engineers work
according to documented standards & rules less
5. Prevention of defects, provided thats ts engineers
neers are wiling to learn
from their errors & continuous improvement
provement
ent is practiced.

Q.5Attempt the following (any TWO)

an [10]
Q.5(a) Explain White Box Testing. [5]
(A) The basis for white box technique
hnique is the source code
co of the test object
?these techniques are often ften cause testing technique or
caused code based testin
structural testing technique.
ique.
Generic idea of white box technique
nique is to execute
execu every
eve part of the code of
test object atleast
st oncee flow oriented test cases are identified, analyzing
program logic & then executed.
xecuted.
al
However the e expected
ected result should
shou determine using requirement or
det
specifications,
tions, nott the code. These
Th is ddone in order to decide if the
execution
ion resulted in failure.
The focus
cus of examination of white bobox technique is on the statements of the
dy

test objects.
bjects.
The primary goal of white boxb testing is then to achieve a previously define
statements, e.g. executes are possible statements in the
coverage of the statement
program.
The basic white box tetest design technique are as follows:
1) Statem Coverage
Statements Cov
Vi

Coverage
2) Branch Cove
Coverage
3) Path Cove
Consider a e.g. of triangle problem (refer notebook)
Consid

Statement Coverage:
1) S
These analysis focuses on each statement of test object the test cases
shall execute a predefined minimum quota or even all statements of test

18
 Prelim Paper Solution

objects. The first step is to translate source code into control flow
graph.
The graph makes it easier to specify in detail the control elements that
must be covered in a graph the statements are represented as node a
control flow between statement are resented by edges if sequences ences of
unidirectional statement appear in program fragment then n they are
illustrated as one single node.
Conditional statements like if.else & loops like while, do ..while
.while have
more than one edges going out from them.

r
After execution of test cases it must be verified erified which of the

ka
statements have been executed. Statement coverage overage must ensure that
each & every statement of a program must be executed at least once.
The test completion criteria for s.c. can define as
No.ofexecutableStat.
at.
State Coverage = x100
Totalno.
 ofstat.
at.
an
2) Branch Coverage:
A more advance criteria for white
control flow graph.
box testing is branch coverage of
hite box

e.g. Edges in the graph h are Centre of tension.

te Execution of each
statement is not ot considerr during brancbranch coverage
cove but rather the
execution of decisionsns are more important.
ecisions importa
al
The result of decision
ision determines which statement
s is executed next.
Branch coveragege testing should make ssure every decision with both
ble outcomes
possible mes i.e. true & fafalse.
Test
st complition criteria for branch
est b coverage is defined a
No..ofexecu
No execut
executablebranches
dy

Branch
nch Coverage = x100
Totalno.
Totaln ofBranches

3) Path Coverage:
Until now test
tes case determination focused on statement or branches of
control flow as well as complexity repeatitions, the previous
contro
deliberations
iber are not sufficient or not adequate test, path coverage
Vi

execution of all different paths through test objects.

requires ex
The test
tes completion criteria for P.C. cannot define mathematically
because it will depends on no. of repeation of loop.
becau
No. of path coverage of test object can be determine using cyclomatic
No
caomplexity, which gives total no. of maximum paths available in control
flow.

19
Vidyalankar : T.Y. B. Sc. (IT)  ST

Q.5(b) Explain boundary value analysis and equivalence class partitioning. [5]
(A) 1) Equivalence class Partitioning:
It is very difficult to test entire software as whole because software is
collection of set program. In equivalence partitioning s/w tester divide
entire software into set of equivalence classes & each & every eve
equivalence program is tested by using set of valid & invalid i/p p condition.
ion
The domain of possible I/P data for each I/P data element ent is divided
divide
into equivalence classes.
[Equivalence class Partitioning]
An equi. Class is group of data values where tester ter assumes
mes that test
objects processes them in same way. The test of one e representative of
equivalence class is such as sufficient because use
e it is assume that for any
a
other I/P value for same equi. Class the test st object will not show
different variables.
Besides equi. Classes for correct I/P, those hose for incorre
incorrect I/P vavalues
must be tested as well. To test equi. Classesasses we have four diff. tytypes of
equivalence classes.
1) If continuous numerical domain is specified then th create 1 valid & 2
invalid equivalence classes.ses.
es.
I/P o Range
20 d x d 50
Valid  x = {20,21.49,50}
1.49,50}
Invalid  i) x < 20
ii) x > 50
2) If no. of valuess should entered then create
c / valid (all possible correct
values)
ues) & 2 invalid equi. Classes
Classe (less & more than correct no.)
I/PP . Specific valu
value
a=5
Valid o x 5
Inval  x 5 or x < 5
Invalid
x>5
3) If set of vvalues is i specifies where each value may possibly be treated
differently
ffere then
the create one valid equivalence class for each value of set
(containing exactly these values) & one additional invalid equi. Class
(containing
(containin all possible other value).
I/P
I/ o Member of set
x = {a, e, i, o, u}
valid o x (a, e, i, o, u)
Invalid o x {b, c, d, f, . z}
4) If there is condition that must be fulfill then create 1 valid and 1 invalid
equivalence class to test the condition fulfill or not fulfill.

20
 Prelim Paper Solution

I/P o Boolean Value

Valid o TRUE
Invalid o FALSE
in t a = 5, b = 3, c = 2
if (a > b & b & b > c)
Test Completion Criteria:
For equi. Partitioning can be define as
No.oftestedEC
Equ.Classcov erage  u100

r
Totalno.
 ofEC
2) Boundary Value Analysis:

ka
It delivers a very reseanable addition to the test cases that have been
identified by equi. Classes.
Faults often appears at the boundariess of equi. ui. Classes. In bou
boundary
value analysis s/w tester emphasizes es on boundary condition because
becaus
maximum no. of errors are generally curs at boundary rather that
rally occurs
within operational bound. Testers
an sters assume
ssume that if so software works
properly on the boundary then hen it will definetly work within boundary
condition.
The most of the errorss in software
softwar lies on boundary
bound because
bec boundaries
are often not defined ed clearly
arly or
o programmers misunderstand
misunde
m them.
A test with boundaryndary valuess useally
usea y discovers
discov the failure the technique
can only we applied d if set of data which is in one equi. Class has
al
identifiable boundaries.
rie
Boundaries ies value
ue Analysis checks borde borders of equi. Classes on every
border,
er, the exact
act boundary value
va & both
bo nearest adjecent value (Inside
/ Outside Equi. Class) are testested.
If the I/P condition for the pro program is the range within close internal
dy

([a
a , b]) then using B VA we ha have six test cases as follows.
1) [a,b]
a  1, a a + 1 b1 b b+1
2) An I/P fil file has rrestricted number of data records between 1 & 100
the test values should be 1,100,2,99.
te value
permitted no. of O/P values is to be rested, proceed just as with
3) If permitt
Vi

the no. of
o input values:
If O/P o of 14 data values are, test accoured, test cases are 1, 4, 0, 5
Test complition
c criteria for Boundary value is define as
No.oftestedBV
BVcov erage  u100 =
TotalNo.ofBV

21
 Vidyalankar : T.Y. B. Sc. (IT)  ST

Q.5(c) Explain experience based testing. [5]

(A) In experienced based technique, peoples knowledge, skills & backgrounds are
prime contributor to test cases & test condition, the experience of both
technical & business people is important, as they bring diff. prospective to
test analysis & design process due to previous experience with simi similar
efu
system they may have insights into what could go wrong, which is very useful
in testing.
There are two types of experience base technique.
1) Error guessing

r
2) Exploratory testing

ka
1) Error Guessing:
It is a technique that should always be use omplement to other more
e as complement
formal technique the success of error Guessing sing is very much depend
de on
o
skill of tester, as good tester knows ws where re the defects are
ar most likely
li
an to occur.
Some people seem to be naturally testing as tthey have
lly good at testin
experience in testing of variety
ariety of software. Error guessing approach is
Err guessin
used after more formal mal
al techniques that have been a applied to same
extent can be very effective.
ffective.
ctive.
In these technique ue the tester likely to gain better
ster is likely be understanding of
system what iss doess & how it does,
does & with
w these
the better understanding
the tester is likely y to be better at guessing ways in which the system
al
may not work properly.
roperly
There e are no rules
ules for error guessing.
gu
Thee tester is encourage to think
t of situations in which s/w may not be
able
e to code.
dy

pical conditions to try

Typical tr includes
includ division by zero, blank I/P , empty files
nd wrong data I/P if a
and anyone
anyon even says a system or environment in which
/w is not operate then error guessing is first methodology to operate
s/w
software.
By using error
e guessing tester can find no. of errors by his own
g
experience
perie common sense approach. Error guess methods saves a lot
or c
Vi

during testing.
of time durin
Exploratory Testing:
2) Explorato
It is hhands on approach in which testers are involve in minimum planning
& mmaximum test execution planning involves creation of test cases, a
short declaration of scope, objectives & possible approaches to be used,
where as test design & execution activities are performed in parallel
without formally documenting test condition or test cases.

22
 Prelim Paper Solution

It is most useful when there are no or poor. Specifications & when time
is severally limited it can be use as check on the formal test process by
helping by ensure that most serious defects have been found.
In exploratory testing the cases prepared by s/w tester based on their
past experience of testing similar application based software.

Q.5(d) Explain use case based and state transition testing. [5

[5]
(A) Used Case Based Technique:
In order to detect requirements, use cases or business cases are describe

r
these are then compiled into use case diagram, itt is used d to describe

ka
behavioral model of the system diagram consist of actors ors and uses cases
where actors are active elements present in systemstem
em and use cases are sim
simply
task or responsibilities of actor in given system.
em.
Use case diagram serve the purpose of definning
efinning relatively
g requirement on a relative
r
abstract level & describe typical user system interaction. UCD mainly sserve
anto show external view of system itt shall explain
expla external
xternal view
v of system
from the viewpoint of user or relation
ation to neighbouring system.
syste
UCD serve as basis for determining
erminingg test case testing
testi as external
ext view is
model technique is useful foror both system testing & a acceptance
acceptan testing.
The following is necessary
ry for cases for UCBT.
or determining test cas
1) Start Situation andnd Preconditions
ditions
2) Other Possible e Condition
ition
al
3) Expected Results
4) Post Conditions
ditions
F.g. for use
se case diagram
agram for
for use case
c diagram
diag notation.

1) Actor
or stickman namenam of order
dy

2) Use
e cases o (Name cases)
Name of use cas
3) Association o o
4) System Boundary Box o
5) Rotation
o include << include
inclu >>
Extend << extends
o Ext e >>
Vi

23
 Vidyalankar : T.Y. B. Sc. (IT)  ST

<<include>> Verify Library

Issue card
Return Book <<include>>
Pay Fine
Read Newspaper
Internet access
Student Librarian
rian
Study/assignment

r
Collect
Maintain Books

ka
Maintain Students
record
Prepare list of Stock
books
Place order
Order book Place order
Cost estimation
n
Make payment
an
<<extend>>
Verify order
Verified
pp y book
Supply ook
Supplier
Supplie

Q.6Attempt the following (any ny TWO) [10]

nsibilities of test leader
Q.6(a) Explain roles and responsibilities lea in an organization. [5]
(A) ader in test organisation :
Roles of test leader
al
Test leaderss tends to be involved in planning,
pl m
monitoring, & control of testing
activity & tasks. Att the outset of project,
project, test leaders, in collaboration with
other stakeholders, device test objectives,
objecti
o organizational test policies, test
strategies,
ategies,
gies, & test plans.
dy

They estimate testing to be done & negotiate with management to acquire

necessary
ssary resources they recognize
rreco when test automation as appropriate &
it is they plan the effort, select
se the tools & ensure training of the team.
They may consult with ot other groups e.g. programers, to help them with their
testing.
ting. They lead
l guide
gu & monition the analysis, design, implementation &
exception of test c cases, test procedures & test suites. They ensure proper
Vi

configuration
co management of the test ware produced & traceability of tests
ma
to test
t basis.
As test execution
ex comes near, they make sure the test environment is put
into pla
place before test execution & manager during text execution. They
monitor,
mon control & report on the test progress, the product quality states &
the
t test result.

24
 Prelim Paper Solution

Daring text execution & as project winds down they write summary reports
on test states. Sometime test leaders wear diff., titles, such as test
management or test Coordinator.

Q.6(b) What are the skills required for test staff. [[5]
(A) Doing testing properly requires more than defining the right position n &
number of people for those position. Good test teams have the e right mix o of
skill based on tasks & activities they need to carry out & people
ople outside
utside team
who are in charge of test task need the right skills too

r
People involved in testing need basic professional & social qualification
lification such

ka
as literary, the ability to prepare & communicated effectively & so on. Going
beyond that when we think of the skill that test estt need three main areas to
me to main.
Application or business domain : A tester er mustst understand the intended
intende
behavior, the problem the system will solve, the he process it will a
automate.
anTechnology :
A tester must be aware of issues, ssues, limitation & capabilities
capab of chose
implementation technology, in n orderr to effectively and efficiently
effic locate
problem & recognize the likely
kely to fail
ail functions & features.
fe
A tester must know testing efficiently carry out the test tasks
ting in order to efficientl
assigned.
al
Q.6(c) Explain test strategies
trategiess and approaches used in testing. [5]
(A) The choice of test st approaches or strategies
strateg is one powerful factor in
success of test effort
fort & accuracy of test p
plan & estimates.
This factor
actor is under control of testor
te & test leaders
1. Analytical
alytical
dy

Modelbased
2. Model
del
based
base
3. Methodical
4. Process or standard comcompliant
5. Dynamic
6. Consultativ directed
Consultative or dir
7. Risk
Vi

8. Skill
Objectives
9. Objectiv
10. Regulations
10 Regula
11. Product
Pro
12. Business.

25
 Vidyalankar : T.Y. B. Sc. (IT)  ST

Q.6(d) What are the factors affecting test effort. [5]

(A) Testing is complex procedure on many projects & variety of factors can
influence it.
When creating test plan & estimating test effort & schedule you must keep
these factors in mind or you plans & estimate will deceive you at beginning nning of
project & betray you at middle or end.
The test strategies or approaches you pick will have a major or influent
ent on
o
testing effort.
Product factor start with presence of sufficient project ct documentation
umentation so

r
that testers can figure out what system is, how is opposed work & what

ka
correct behaviour look like.
The importance of nonfunctional quality characteristic cteristic such as usability,
acteristic usabili
reliability, security, performance, & so forth influences ces the testing effort.
effo
These test target can be expensive & time e consuming.
uming
Complexity is another major product oduct factor. The difficulty
d of
ancomprehending & correctly handling the problem being built
oblem they system is bein
to solve use of innovative technologies.
ogies.
The need for intricate & perhaps multiple
aps multip
ultiple
le test configuration
config especially when
es
these rally on the timely arrival of scarce softwa software, harhardware & other
supplies.
The privalence of stringent
tringent security
securi rules. The prprivelence of stringent
security rule, strictly
ctly regimented
egimented process
proc ss oro other
othe regulation geographical
distribution of team especially
pecially if team crcroseses ttime zones.
al
Q.7Attempt the following (any THREE)
THREE
HRE ) [15]
Q.7(a) Explainn potential benefits and ri risks of using tools. [5]
(A) Tool
ol can
n be any device which
wh reduces human efforts & makes the task easier
dy

every machines are a tool but

b every
ever tool need not be a machine
or, hammer,
e.g. of tools are calculator,
ca ham etc.
The potential benefits of ttools are
1. Tool reduces thet human
hum efforts
2. Using tools user cacan save their time
3. Using tool,
t it reduces
re repetitive work
Vi

consistency repetitive work

4. Greater cons
5. Objective assessment
6. Ease of
6 o access to information about test or testing

Risk of Using tools :

11. Unrealistic expectations for the tool
2. Underestimating time, cost & effort initial introduction of tool

26
 Prelim Paper Solution

3. Underestimating time & effort needed to achieve significant &

continuing benefits from the tool
4. Underestimating effort require to maintain test assets generated by the
tool
5. Over reliance on the tool

Q.7(b) Explain test management and requirement management tools.. [5]

[5
(A) Requirement management tools are used to gather requirementrement form end
users.

r
e.g. of requirement management tools is are we portals.
s.

ka
Set of questionnaire
Features of characteristics of requirements management tools includ including
support for :
1. Storing requirements statements.
2. Storing information about requirement
ment attributes.
ributes.
an3. Checking consistency of requirement
ment
4. Identify undefined, missing orr to be
e defined later requi
requirements.
requirement
5. Prioritizing requirements for testing
sting purposes.
6. Traceability through levels
vels of requirements
7. Interfacing to test management
gement tools
8. Coverage of requirements
irements by
y set of test.
al
Test management ent toolss are use to manage
man entire test process. It starts
manage ent
from test dataata preparation,
eparation, test data exaction
exact towards the preparation of
final result
ult of how many test & outstanding.
outstanding
out
The features
eatures or characteristics of test management tools are
characteristics o
1. Management
nagement of test
dy

2. Scheduling
heduling of test to be executed
ex (manually or by a test execution
tools).
ools
3. Management of testingtestin activites (time spent in test design, test
execution whether
whe we are on schedule or.
w

Q.7(c)
(c) Explain features
f and characteristic of incident configuration [5]
Vi

management
ma tools.
too
(A) Con
Configuration management tools are used whenever any changes encounter
during software
dur sof life cycle software configuration management is an art of
identifying and implementing necessary changes in a software.
identif
Software configuration management tools are use when any request for
Sof
change is encountered by end users or developer

27
 Vidyalankar : T.Y. B. Sc. (IT)  ST

SCM is 4 step process :

1. Identify the change
2. Control the change
3. Ensure that the change has been properly implemented
4. Status reporting

Features or characteristics of configuration management tools includes

ncludess
1. Staring information about version & builds of the softwaree & testuare.
are.
2. Traceability between software and test ware & different
ferentt versions &

r
variants
3. Keeping track of which versions belong with which figurations (e.g. o.
ch configurations

ka
s. libraries)
4. Reporting of statistics/metrics about incidents
dents
5. Access control

Incident Management Tools :

These are used when there is incident execution
ent occur during software execut
an Features or characteristics of incident

1. Storing information about

bout
nt management tools
t

ut attributes of incidents.
inciden
2. Storing attachments ts (e.g. screenshot)
3. Prioritizing incidents.
ents.
4. Assigning actions
ions to people
people (Fix, confirmation
conf ttest)
al
5. Status (e.g. rejected,
g. open, rejected
ejected,, duplicate dereffered, closed)
duplicate, deref
6. Reporting
ng of statistics/metric
tatistics/metric about
ab incidents
inci (e.g. average time open)
7. Number
ber of incidents
idents with each
ea status, total number raised, open or
stat
closed.
osed.
sed
dy

Q.7(d) Explain
in reporting and characteristics
character
char of unit test tools and security [5]
tools.
(A)
A) Unit test framuvark too tool is use to perform unit testing on software
component
omponent
Features / Characteristic
Character includes
Vi

Supplying inputs
i to
t the unit/ module of software
Receiving o/p generated
Re g by unit of software
Which
Wh are being
b tested
Executing set of test cases on s/w unit
E
Record the result of each test case performed on each unit using pass or fail
Recor
basis
bas
Storing the result of test cases
Support for debugging
Covering measurement at code level

28
 Prelim Paper Solution

Security tools :
There are number of tools that protect system from external attack for
e.g. firewalls, which are important for any system security testing tools can
be used to test security by trying to break into systems whether or not it is
protected by a security tool.
The attack may focus on the network the software support, the e application
cation
code or underlying database.
Features or characteristics of security testing tools includes es support
port for :

r
1. Identifying softwares.
2. Detecting instructions such as deniel of service attacks
ttacks

ka
3. Simulating various types of service attack
4. Probing for open ports or other externally visibleble points of attacks
5. Identifying weakness in password files & passwords ds
6. Security cheeks during operation. E.g. forr checking integrity
integ files &
of file
intrusion detection e.g. checking result of test attacks
attacks.

(A)
an
Q.7(e) Explain Agile methodology in details..
Agile Model
1. Extreme programming ng is currently one of theth most well known agile
[5]

development life cycle

ycle model.
el.
2. The methodology gy claims
ims to be more huma friendly than the traditional
human frien
developmentt method. d.
al
3. Using Agile
ile model,
del, Developer can ddevelop simple
s and Interesting GUI for
S/W.
Some of the characteristics of XP are are:
x It promotes the generation
gene of business
bu stories to define functionality.
dy

x It demands an on side costumcostumer for continues feedback and to define

nd carry out functional
and functiona test.
te
x It promotes pair pro programming and shared code ownership among
developers.
x It states
sta that component
co test scripts shall be written before code is
written those test should be automated.
tten and th
Vi

x It states that
th integration and testing of code shall happen several times
a day.
always states that we should always implement simplest that should
x It alw
meet solutions to the todays problem.
me

29
 Vidyalankar : T.Y. B. Sc. (IT)  ST

Q.7(e) Explain Agile methodology in details. [5]

(A) Test Design Tool:
Features:
Generating test input values from
Requirements
Design Models, (state, data and Object);
Code;
Graphical User Interface
Test condition

r
Generating Expected Result if an oracle is available to the tool

ka
Test Data Preparation Tool:
1. Extracted Selected data records from files es or database.
2. Massage Data Records to make them nymous and or not able to
m anonymous t
identified with real people (For data protection);
tion);
an 3. Enable records to be shored or arranged
rranged in different order.
4. Generate new records populated ed with h pseudora
pseudorandom dat data set up
data, or d
according to some guideliness e.g. an operational profile.
pro
5. Constrict a large numberr of similar records template to give large
ecords from templa
set of records for volume
ume
e test.
test

Test Execution Tools: ols:

1. Capturing (record)
ecord) test
est inputs while test
te are execute
e manually.
al
2. Storing an n expected
cted result in the form
f rm of screen
fo s or object to compare to
the nextxt time test
est is run Executing
Execut test
test from scored script and optionally
dataa files accessed by script.
3. Dynamic
amic comparison (while
( test is running) of screen elements, links,
dy

controls,
trols, objects and vavalues;
bility to initiate post execution
4. Ability e
exec comparison logging result for example :
Exciting
citing the screed dis displayed current data and time which is not of
interest to a particular
particula
pa test.
Synchronising
nchronising input w with the application under test e.g. wait unfill the
application
application.
Vi

30