t.y. b.sc. (it) software testing - vidyalankarvidyalankar.org/upload/st_soln.pdf · t.y. b.sc. (it)...

1014/BSc/IT/TY/Pre_Pap/2014/ST_Soln 1

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]Q.1(a) What is an error, failure and fault? [5](A) A failure is non fulfillment of requirements, A discrepancy between

actual result or behavior (Identified in Requirement Specification) Failure in a software means the software doesn’t perform functional

requirements, the failure occur in S/W because of fault. Every fault, or Defect or Bug in S/w is present since it was developed or changed.

A failure has its roots in a fault in the software. These fault is also called a defect or internal error programmer generally use a term Bug for fault e.g. of fault e.g. of fault can be the programmer might be wrongly programmed or forgotten code in application.

It is possible that a fault is hidden by one or more other faults in different parts of application. In that case, A failure only occurs after the masking defects have been corrected

The cause of fault or defect is an error or mistakes by person. E.g. wrong programming by developer or A mescindersfanding of commands in programming language.

However faults may be even cause by environmental conditions like radiation, magnetism etc. that introduce Hardware problem.

Q.1 (b) Explain success factors of review process. [5](A) Implementing formal reviews is not easy as there is no one way to success

and there are no. of ways to fail. Critical success factor for formal reviews are

1. Find a champion 2. Pick things that really counts 3. Explicitly planned & track review activities 4. Trained participants 5. Manage peoples issues 6. Follow the rules but keep it simple 7. Continuously improve process & tools. 8. Report results 9. Just do it.

Vidyala

nkar

[10]10][5][5

epancy between tween pecification) cation)

’t perform functional orm functione of fault. Every fault, or ult. Every fault, or

developed or changed. eveloped or changed software. These fault is also ware. These fault is

rammer generally use a term Bugnerally use a tet can be the programmer might be the program

n code in application. in application. s hidden by one or more other by one or more

ion. In thn that case, A failure only oat case, A fe been corrected e been corrected

or defect is an error or mistake defect is an error or g by developer or A mescindersfaeloper or A mesc

nguage. . ults may be even causay be even cause by enve

magnetism etc. thatetism etc. that introduce Ha introd

success factors success factor of review procef reviewementing formal reviews is not ementing formal rev

nd there are no. of ways to fail. Cre are no. of ways are 1. Find a champion 1. Find a champion

2. Pick things that really 2. Pick things that really 3. Explicitly planned &3. Explicitly pla 4. Trained particip4. Trained 5. Manage peopl 5. Manag 6. Follow the 6. 7. Continu7. 8. Repo

9. J

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

2

Q.1(c) Explain V-model. [5](A) V model was developed to address some of problem experience using

traditional waterfall approach defects were being found to late in life cycle testing was not involved in until end of project testing also added load time due to its late involvement.

The V model provides guidance that testing needs to begin as early as possible in life cycle.

V model shows testing is not only execution base activity there are variety of activity that need to perform before end of coding phase.

These activities should be carried out in parallel with development activities and tester needs to work with developer, so they can perform these activity and produce a good activity result.

Therefore in V model s/w tester is involved in development team from day 1.

V model was uses 4 test levels, each with there own objectives. Q.1(d) Explain decision table Based testing with example. [5](A) Decision Table base Testing : It has been use to represent & analysize & complex logical relationship

decision table are Idle for describing situation in which no of combinations of actions are taken under verifying set of conditions.

A decision table has 4 portions. The leftmost column 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 o/p. Consider e.g. of triangle function. Condition stab

SYSTEM ANALYSIS

SystemDesign Software

CodeS/w

Testing

Acceptance Testing

Integration Testing

UnitTesting SystemTesting

TEST LEVELS

S/wDEVELOP

MENT LEVELS

Vidyala

nkar of problem experience using roblem experience

re being founng found to late in life cycld to late in li project testing also added load ct testing also ad

that testing needs to begin as testing needs to b

ot only execut ot only execution base activity thion base act perfororm before end of coding pham before end of cod

d be carried out ied o in parallel with din paralle to work with developer, so they cak with developer, so t

ood activity result. ivity result. n V model s/w tester is involveodel s/w tester is

el was uses 4 test levels, eael was uses 4 test levels, each wit

Explain decision table Based testn decision table BasDecision Table base Testing :ion Table base Testin

It has been use to repres It has been use to repredecision table are Idle fdecision table areof actions are taken u actions are t

A decision table haA decision The leftmost co Th The condition The

expected oexp Conside

Cond

aakakakarTEST ST

LEVELS LEVELS

Prelim Paper Solution

3

Condition

stab

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 C3 : c < a + b F T T T T T T T T 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

Action stab

a1 : Not a a2 : Eq. V a3 : Fso a4 : satan D a5 : Impossible

Q.2Attempt any TWO questions. [10]Q.2(a) What is testing? Explain fundamental principles of testing. [5](A) Testing is an umbrella activity conducted throughout life cycle of software

to identify bugs or defects or faults, present in software. Testing can be identify both syntactical as well as logical error present in

software. General principles of testing are : 1) Testing shows the presence of defects, not there absence. 2) Exhaustive testing is not possible. 3) Testing activity should start as early as possible 4) Defects tends to cluster together (Group of similar elements) 5) The pesticide paradox 6) The test is context depended. 7) False of assuming that no failure means useful system. 8) An efficient testing will conducted by independent third party i.e.

professional software testor groups. 9) Test cases require for testing a software must be planned long before

testing begins and it must be traces sable to costumer requirement which extend from requirement document.

Q.2(b) Define software. Explain the characteristic of software. [5](A) Instruction : Any programmable excitable statement is called Instructions. 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.

Vidyala

nkar

T T

rr F T T rrrrrr

araraaaar arkkakaaar

kar

kkkakaaar

kakkkkakaaa kannnnknknknknknkkakkakaaental principles of testing. ciples of testin

conducted throughout life cycle cted throughou or faults, present in software. or faults, present in softw

both syntacticath syntactical as well as logical as well a

f testing are : ing are : ws the presence of defects, not th presence of defect

e testing is not possible. ng is not possible. g activity should start as early as y should start as ea

ects tends to cluster togethects tends to cluster toget er (GThe pesticide paradox e pesticide parado

) The test is context depended. test is context de7) False of assuming that no faalse of assuming that 8) An efficient testing wi8) An efficient testing w

professional software professional software 9) Test cases require 9) Test cases r

testing begins aestingwhich extend ch

Q.22(b) Define soft(b) DefA) Instruct

A setis


4

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 8) Maintainability 9) Portability Q.2(c) Explain psychology of software testing. [5](A) Psychology of Testing : 1) The people made mistakes but they do not like to admit them. One goal

of testing software is uncover disturbancing between software and specification or costumer needs, therefore failure found must be reported to developer.

2) Can developer test his own program?, it is on important & frequently asked question

The universal valid answer does not exist, if tester also author of program, they must examine their own work critically.

3) If developer implements a fundamental design error e.g. if they misunderstand the conceptual formation then it is possible that he or she may not find these using their own test.

4) On the other hand it is an advantage to have a good knowledge of own test object it is not necessary to learn test object and therefore time is saved, Management has to decide when it is the advantage to save time even with the disadvantage of blindness for their own errors.

5) Independent testing team tends to increase quality & comprehensiveness of the test tester can took at the test object without Bias (partiality). It is not their product and possible assumption & unisunderstanding of the tester. The tester must acquire necessary knowledge of the test object in order to create a test cases with corresponding time and cost. The tester comes along with deeper testing knowledge, developer which doesn’t 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 co operation between developer and tester.

7) There is often problem that failures found during testing are not reproducible for developers in development environment.

Vidyala

nkar[5]

y do not like to admit them. One t like to admit thr disturbancing between softwarbancing between

needs, therefore failure found efore failure

s own progra own progr m?, it is on importam?, it is on i

lid answer does no does not exist, if tt exis must examine examine their own work criteir own w

per implements a fundlements a fundamental amrstand the conceptual formatio the conceptual for n

may not find these using their ownd these using thn the other hand it is an advan the other hand it is an a nta

test object it is not ne object it is not n cessary tsaved, Management has to deved, Management haseven with the disadvantageven with the disadvant

5) Independent testing te 5) Independent testing teof the test tester cof the test tIt is not their pIt is the tester. T tesobject in orThe testdoesn

6) It


5

8) Mutual knowledge of their respective task encourages co operation 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 :

Planning and

Analysis and design

Implementation and Execution

Evolution of the test exit criteria

Post testing activity

Begin

end

Control

Vidyala

nkar

[

kknknklanlanalaalayal

yal

and xecution

test exit criter

ost testing activit

yayaend

nnkContr


6

Q.3 Attempt the following (any TWO) [10]Q.3 (a) Explain waterfall model with its advantages and disadvantages. [5](A) The WATERFALL MODEL was one of the earliest model to designed. It is

one of the systematic & sequential approach towards software development waterfall model develop software using Analysis, Analysis Design, Coding, Testing, Deployment & maintenance.

The arrows in these model is unidirectional. It assumes that developer shall get all requirement in single attempt. these model is suitable only for static requirements.

Once all requirements are analysed and gather from customer, the requirements are converted into Low Level and High Level Design.

The design can be Logical Flow, Diagramatic Represents Flowchart, Data Flow Diagram 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 programmer select appropriate programming language and start soft ware coding.

Need wish, policy laws

User Requirement

System Requirement

Global Design

Detailed Design

Implementation & Coding

Testing

Development & Maintenance

Vidyala

nkar

WATERFALL MODEL was one of tWATERFALL MODEL was on of the systematic & sequential a the systematic &

waterfall model develop softwarefall model develop sTesting, Deployment & maintenng, Deployment & mainThe arrows in these model The arrows in these model get all requirement in singget all requiremenstatic requirements. tic requirem

Once all requiremOnce all requirements arre

The design c TheFlow DiagFloprogramsyst

aniled Desigggn

alanImplementation & CodingImplementation & CodinglaalalTesting TestlDevelop

a


7

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 towards software development.

2) All the phases of software development are clearly defined i.e., Each team member should know when his/her responsibility in development process.

3) It is one of the time consuming model because ones requirements are gathered from costumer, the work model is available only after the deployment. Costumer needs to specify all their requirements software development but it is often difficult for any costumer to give all their requirements explicitly.

Q.3 (b) Explain different levels of testing. [5](A) According to V model of Software Development there four different levels

of testing 1) Unit/Component/Module Testing : A component testing is also known as Unit, module & program testing,

it searches for defects and verifies functionality of software that are separately testable.

In unit testing, the entire software is divided into smallest workable module called as unit and each a every unit is tested separately to ensure that it is working properly.

Advantages of Unit Testing are a) Error identification become simple b) Error propagation gets minimize c) Overall testing time will reduce The following test are performed on an individual module during unit

testing. 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.

Unit Testing Consideration

Module or Unit or Component

Boundary Condition Testing Local Data Structure Independent Path Testing Event Handler

BBT

WBTVidyala

nkar

towar

ined i.e., Each , Eacy in development evelopment

ones requirements are uirements are available only after the available only after the

their requirements software heir requirements softwar any costumer to give all their ostumer to give all

g.re Development velopment there four diffethere fou

e Testing : e Testing :sting is also known is also known as Unit, moduleas Unit,

or defects and verifiess and verifies functiona fately testable. estable.

testing, the entire software the entire softwa is diule called as unit and each a eved as unit and each e

nsure that it is working properly. t it is working pr Advantages of Unit Testing are Advantages of Unit Testi

a) Error identifia) Error identification beco b) Error propagation getsb) Error propagat c) Overall testing time c) Overall testing t The following test a The following test a

testing. testing.

Un

Modu


8

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 the system

e) Finally all error handling paths are tested to ensure that the module is working properly as an individual.

Component testing may include testing of functionality & specific non functional characteristics such as resource behavior, performance testing, & structural testing test cases are derived from the driver class to test their stuffs.

Unit testing is also called as Grey Box Testing (GBT) 2) Integration Testing : Once all the modules are tested properly. Tester needs to integrate

them as per the design of software to ensure that it will work properly as whole

There are two types of Integration testing i.e. Top down Integration Bottom up Integration

In top down integration one by one module gets added in system where as in bottom up integration is conducted cluster by cluster integration.

Regression testing is perform along with integration testing to ensure that system will perform properly whenever there is any change in software.

Integration testing test interfaces between components, interaction, to different parts of system such as an o. s., file system & interfaces between software & hardware.

Integration testing is after carried out by integrator but preferably by specific integration tester or testor team depending on structural requirement of system. Integration testing can be categorized as follows

a) Top Down 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.

Vidyala

nkarule w

sure that the at th

tionality & specific ty & specific resource behavior, ce behavior,

g test cases are derived cases are derived s.

x Testing (GBT) ng (GBT)

sted properly. Tester needs to intoperly. Tester need of software to ensure that it ftware to ensure t

s of Integration testing i.e. s of Integration testing i.eation n

tegration wn integration one by egration one by one modulone

as in bottom up integratioottom up integrati n is cogration.

egression testing is perform al testing is perensure that system will perforensure that system will change in software. change in softwar

Integration testing test in Integration testingto different parts ofto different partsinterfaces between sinterfaces between

Integration testi Integratioby specific intby specrequirementreqfollows

a) Top D In


9

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 :

It is concerned with behavior of whole system or product as defined by the scope of development project or product

System testing may include test based on requirement specification, business process, use cases, system behavior, interactions with operation system & system resources.

System testing is most often the final test on behalf of development to verify that the system to be delivered meets specification and its purpose may be to find as many defects as possible.

Most oftenly system testing is curried out by specialist testor from independent third party

System testing should investigate both functional & Non functional requirements of the system. Typically nonfunctional requirement includes performance & reliability system testing of functional requirement starts by using most appropriate specification based technique (BBT) for aspect of the system to be tested.

The following are testing to be conducted during system testing 1. Performance testing 2. Load/Stress 3. Recovery 4. Security testing 4) Acceptance Testing : When development organisation has perform its system test & has

corrected or all most defects, the system will delivered to user or costumer for acceptance testing these test should answer following question such as

a) Can system be released? b) What if any are the outstanding risk? c) Has development meet their expectations? 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 non functional characteristics.

e.g. Useability of system

Vidyala

nkar

uct as defined efine

ement specification, specification, vior, interactions with eractions with

est on behalf of development st on behalf of developmeered meets speceets specification and its ification a

fects as possible. as possible. curried out by specialist testor fd out by specialist

vestigate both functional & Nonate both functional system. Typim. Typically nonfunctional cally nonf

nce & reliability system testinnce & reliability system arts by using most appropriate s by using most approp

BT) for aspect of the system to beect of the systeing are testing to be conducted de testing to be condu

formance testing e testing oad/Stress tress

. Recovery ry 4. Security testing 4. Security testing

4) Acceptance Testing :cceptance Testing : When development org When development

corrected or all mocorrected or all mocostumer for acccostumer question such questio

a) Can sys a) b) Wha c) H It


10

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 the testing of

function to be performed component or system, A non functional quality characteristic such as reliability useability; A

structure or architecture of system or component; or related to change i.e. confirming the defects have been fixed and looking for unintended changes. i.e. Regretion Testing. Depending on test objectives, a different testing will be organised.

1. Testing of function [functional testing] The function of system is “what is does.” This is typically describe in requirement specification, functional specification & in use cases.

There may be some functions That are assumed to be provided that are not documented as well as not the part of requirement for system functional tests are based on these functions, describe in documents or understood ny the testor. Functional testing considers the specified behaviour & is often also reffered as Black Box testing or Behavaioural or Performance testing.

Testing functionality can be done from two prospective Requirement based or Business Process Based.

A) Req. Based testing uses a specification of the functional Requirements for the system as the basis for designing test cases. A good way to start is to use the table of content of the requirement specification as an initial test inventory or list of items to test. As a testor we should also priorities a requirement based on risk criteria and use these to prioritize the test. These will ensure that the important & critical test are included in testing efforts.

(B) Business Process Base testing uses knowledge of business processes. Use cases are very useful basis for test cases for business prospectives.

The technique use for functional testing are often specification 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. Non Functional Testing [Testing of s/w product ] (PERFUM)

Vidyala

nkar

[5][uld the testing of testing of

eliability useability; A useability; A ; or related to change i.e. ated to change i.e.

king for unintended changes. ng for unintended changectives, a different testing will s, a different testin

ting] The function of system is “whe function of sydescribe in requirement specife in requirement

se cases. ons That are assumed to be provhat are assumed t

ll as not thll as not t e part of requireme part of re based on these fued on these functions, descritions,

he testor. Function Functional testing coal tes often also reffered as also reffered as Black Box Bla

ance testing. sting functionality can be doneonality can be don from

or Business Process Based. ess Process Base Req. Based testing uses a Req. Based testing us

Requirements for the system Requirements for good way to start is to usgood way to start specification as an initispecification as an itestor we should alstestor we should alsand use these toand use timportant & crimporta

(B) Business Pr (B) BusUse casprosp

Th


11

1. A second target for testing is testing of the quality characteristics or non functional 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. Non functional testing, as functional testing is performed at all test levels. No Functional testing includes performance testing, load, stress usability, maintaence, reliability & portability testing. It is the testing of “How well” the system, work.

To the characteristics & sub characteristics of the software to be tested under non functional testing are as follows:

1. Functionality Sub characteristics : Suitability, Acuracy, Security, Interoperability, complaints. These

deals with functional testing. 2. reliability Sub characteristics Maturity, facect Tolerance, Recoverability & complaints. 3. Usability Sub characteristics Understandability, Learnability, Operability, attractiveness. 4. Efficiency Which is divided into Behavior & resource Utilisation. 5. Maintainability : Sub characteristics : Analyzability, Changeability, Stability, Testability, 6. Portability : Sub characteristics : Adaptability, install ability, Co existence, Replaceability. Q.3(d) Explain maintenance testing. [5](A) Maintenance testing : 1) Once deployed, system is often in service for year or even decades during

this time the system & it’s operational environment is often corrected, change or extended. Testing i.e. executing during these life cycle period is called Maintainance Testing.

2) Maintainance testing is different from maintenability testing, which defines how easy it is to maintain the system.

3) The development and test process applicable to new developments doesn’t change fundamentally for maintainance purpose the same test process steps will be apply & depending on size & risk of the changes made, several levels of testing are carried out during maintainance testing. A component test,, system test, Acceptance Test.

4) A maintainance test process useally begins with the receipt of an application for a change. The test manager will use these as basis for producing test plan.

Vidyala

nkar

t all testing, load, oad

testing. It is It

he software to be ftware to be lows:

perability, complaints. These rability, complaints. The

coverability & complaints. ility & complaintscs

ability, Operability, attractiveness Operability, attract divided into Behavior & resource Ud into Behavior &

b characteristics : b characteristics : hangeabiliteability, Stability, Testabilityy, Stability, Test

ub characteristics : teristics : ty, install ability, Cotall ability, Co existence, Reexiste

ntenance testing.ce testing.ce testing : g :

ce deployed, system is often in ce deployed, system is ofte sethis time the system & it’s oper time the system change or extended. Testing i.nge or extended. Teis called Maintain called Mainta ance Testi Te

2) Maintainance testing is 2) Maintainance testing isdefines how easy it is defines how ea

3) The development a3) The developchange fundamenge steps will beseveral lescompon

4) A ma


12

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) Regression Test to show that rest of system has not been affected by

maintainance work. The maintainance testing will perform on software under following condition.

A) If costumer or end user requires support or they are not understanding some of the functionality of s/w.

B) When developer wants to enhance / upgrade a software. C) When any changes are informed by user. Q.4Attempt the following (any TWO) [10]Q.4(a) Explain phases of review process. [5](A) Review process vary from informal to formal i.e. (well structured &

Regulated) Although inspection is most documented and formal review technique the review process consist of six main steps.

1) PLANNING. i) The review process for particular review process begins with

“Request for Review” by the author to moderator. The moderator is often assign to take care of scheduling if review that means the time, date, venue, agenda & invitation of review is made by moderator.

ii) On a project level, the project planning needs to allow time for review & rework activities, providing engineers with time to thurrowly participate in review.

iii) For more formal reviews, the moderator always perform an entry check & defines formal exit criteria.

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

these meeting is to get everybody on same wavelength regarding document under review & to commit to time that will be spent on 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.

Vidyala

nkar

ffected by d bym on software ftwar

e not understanding understanding

oftware. e.

[10

mal to formal i.e. (well structu formal i.e. (well

documented and formal review tented and forma ix main steps. x main step

process for particul for particular review ar or Review” by the author to modeview” by the author t

ssign to take care of scheo take care of sc duling, date, venue, agenda & invi, venue, agenda & ta

oderator. On a project level, the projec On a project level, the

review & rework activitiesreview & reworthurrowly participate in rethurrowly participa

iii) For more formal revie iii) For more formal recheck & defines formcheck & defines for

2) KICKKICKidOFFOFF i) An optional i) An

these mdocumch

ii)


13

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 spelling mistakes are recorded on document under review but not mentioned during review meeting.

iii) A critical success factor for thurrow preparation is no. of pages checked per hour, these is called Checking Rate.

4) REVIEW MEETING: i) Logging Phase: Discussion Phase Decision Phase

During logging phase, the issues e.g. defects that have been identified during preparation phase are mention phase by phase, reviewer by reviewer & are logged either by author or recorder. A separate person like recorder or scriber is present in logging phase to log defects encouraged during review process. To ensure process & efficiency, no real discussion, the items are logged & then handled in discussion phase. A detailed discussion on whether or not an issue is defects is not meaningful, as it is much more efficient to simply log it & proceed to next defect. During logging phase the focus is on logging as many defects as possible within certain time frame. To ensure these, moderator tries to keep good logging rate i.e. no. of defects logged per minute.

As chairperson of discussion meeting the moderator takes care of peoples issues. All the defects logged in previous phase are discussed in detail during discussion phase. At the end of meeting a decision on document under review has to be made by participant 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 found per page.

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

rm spelling ling not mentioned tione

tion is no. of pages no. of pages te.

s e.g. defects that have been ideefects that have bre mention phase by phase, re phase by pha

her by author or recorder. author or recorde recorder or sc recorder or scriber is present in riber is pre

ged during review process. during review process. ss & efficiency, no ency, n real discussionreal dis

d in discussion phase. scussion phase. A detailed A de is defects is not meaningfects is not meaning ul, as

og it & proceed to next defect. proceed to next defg logging phase the focus is on phase the focus lo

thin certain time frame. thin certain time frame. To ensure these, moderator tri ensure these, modefects logged per minute. fects logged per min

As chairperson of discus As chairperson of dispeoples issues. All the deoples issues. All the ddetail during discussidetail during dAt the end of meAt the endmade by particde bexit criteriacritical d

5) REW


14

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

6) FOLLOW UP: The moderator is responsible for ensuring that satisfactory action have

been taken on all logged defects, process improvement suggestion & change request. Although the moderator checks to make sure that author has taken action an all defects, it is not necessary for moderator to check all corrections in detail for more formal review type moderator checks only for complains to exit criteria i.e. during follow up moderator keeps track on those errors which are encountered during logging phase & their elimination process.

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

process. [5]

(A) The participant in any type of formal review must have adequate knowledge of review process, the best & most efficient review situation occurs when participant gains. Some kind of adv. for their own work during reviewing. The following are the members & responsibilities in review process.

1) Moderator / Manager: It is a chairperson of the entire review process. He/she determines

incorporation with author, type of review, approach & composition of review team. The moderator is responsible of scheduling of review process.

Moderator prepares policy, plan objectives & review process. The training of reviewer can conducted by moderator the moderator

performs entry check & follow up on rework, in order to control, the quality of input & output of review process.

Moderator can also defines exit criteria. 2) Author: Author is writer of the document under review, the authors goal should

be learn to as much possible with regards to improving quality of document but also to improve his or her ability to write futures documents.

The author’s task is to eliminate under areas & to understand the defects found.

If authors document exceeds exit criteria then author must involved in the rework phase.

3) Scriber / Recorder: During logging phase recorder has to record each defect mentioned and

any suggestions for process improvements

Vidyala

nkarion ha

ggestion & n &ke sure that e tha

ry for moderator moderator view type moderator pe moderator

ng follow up moderator up moderator ered during logging phase uring logging phase

members present in reviewrs present in revi [5

al review must have adequate know must have adequ most efficient review situation ocnt review situa

f adv. fo for their own work during rr their own wor & respon & re sibilities in review processibilities in review

er:son of the entiree enti review process review

with author, type of review, app author, type of reviem. The moderator is resp moderator is re onsibl

rator prepares policy, plan pares policy, pla objecte training of reviewer can coe training of reviewer can nd

performs entry check & follow forms entry checquality of input & output of reality of input & outpu

Moderator can also defines Moderator can also def2)2) Author:uth

Author is writer of t Author is writbe learn to as mbe learn tdocument but cumedocuments.

The auth defect

If a

3


15

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 reviewer reviews includes source, standards, checklist etc. The sole responsibility is to review author’s document & try to find as many defects as present in document.

Manager:

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

Q.4 (c) Explain goals and key characteristics of walkthrough and

Inspection. [5]

(A) Walkthrough : 1. Walkthrough is characterized by author of document under reviewing

guiding participant through document and his or her thought process, to achieve common understanding & to gather a feedback.

2. Walkthrough is specially useful if people from outside s/w discipline are present, who are not used to or cannot easily understand s/w documents. The content of document is explain step by step by author, to rich the consequences on changes or together information. Within a walkthrough the author does most of the preparation the participants who are selected. From different departments & document in advance.

3. Walkthrough is specially useful for higher level document such as requirement specification & architectural documents.

4. In walkthrough the reviewer should go through all requirements & specification of product to be develop & if require any modifications or suggestion or new ideas will be given to another as feedback

The goals of walkthrough are 1. To present document to stack holder both within an outside the s/w

discipline 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.

rates al reviewer wer

esponsibility is ility cts as present in present in

he decides on execution of decides on execution & determines whether review ermines whether r

ger is also responsible for providin also responsible for puested by participants. by participants.

aracteristics of walkthrough ristics of walkth

racterized by erized by author of documeauthor of dnt through document and his or h document and h

on understanding & to gather a feeerstanding & to gathegh is specially useful if ecially useful if people fropeo

who are not used to or canno re not used to or ca t ea content of document is explain stf document is ex

nsequences on changes or togethnsequences on changes or tthe author does most of the author does moselected. From different depalected. From differe

3. Walkthrough is specially 3. Walkthrough is speciarequirement specificatioequirement specificati

4. In walkthrough the 4. In walkthrouspecification of pspecificatisuggestion or nggest

The goals of 1. To pr

dis


16

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 app.

product. Inspection : 1. Inspection is most formal review type, the document under inspection is

prepared & check thoroughly before meeting, comparing work product with its sources & other referenced documents, & using rules & checklist as inspection is validation criteria (Acceptance testing)

Checklist mechanism is must 2. In inspection meeting defects found are logged & any discussion is

postponed until discussion phased, these makes inspection meeting very efficient meeting

3. In inspection meeting all defects are discussed, solve, & make a decision on them whether to accept or reject inspection is performed by an inspector.

Using checklist mechanism The goals of Inspections are 1. To help author to improve the quality of documentation under

inspection 2. To remove defects efficiently, as early as possible. 3. To remove defects efficiently, as producing documents with higher

level of quality 4. To train new employer in organisations development process. Key Characteristics of Inspection are 1. It is usually led by trained moderator 2. It uses define goal using process 3. If involves peer to peer common to examines product 4. Rules & checklist are use during preparation phase 5. Defects found are documented in logging list or issued log 6. Follows up is carried out by applying exit criteria. Q.4 (d) Explain static analysis by tools. (A) Coding standards Code Metric Code Structure

Vidyala

nkarlar ap

t under inspection is r inspection is ting, comparing work mparing work

nced documents, & using ocuments, & using dation criteria (Acceptance ation criteria (Acceptan

und are logged & any discussioe logged & any phased, these makes inspection m these makes inspe

defects ars are discussed, solve, & mae discussed, s o accept or reject inspection is po accept or reject inspect

echanism nspections are ions are

p author to improve the qualitr to improve theection

o remove defects effici defects efficiently, as een To remove defects efficiently, To remove defects effic

level of quality level of quality 4. To train new employer in To train new emplo o Key Characteristics of Inspey Characteristics of I

1. It is usually led by t 1. It is usually led by t 2. It uses define goa 2. It uses de 3. If involves pee 3. If involv 4. Rules & che 4. Rul 5. Defects 6. Follow

.4(d) Explain C


17

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, design

& code such as test coverage 4. The basic goal of static analysis is to find defects whether or not they

may cause failures The are three diff. methods to perform static analysis 1. Coding standard : Checking of coding standards is the most welknown feature during static

analysis. The first action to be taken is to define a coding standard The coding standards are platform dependent, usually a coding standard

consist of set of programming rules, naming conventions & layout specification. It is recommended for s/w tester to adopt existing standards. The main advantage of coding standard is that it saves lot of time & efforts during testing. Main reason for adopting standard is that the readymade tools are available which supports that standard, so overall testing efforts will reduced.

2. Code metric : When performing static code analysis useally information is calendared

about structural attributes of code, frequency of comments in program, depth of nesting, cyclomatic complexity & LOC.

Cyclomatic complexity metric is based on no. of decision in program. It is very important for testor because it provides indication of amount of testing necessary to practically avoid defects using cyclomatic complexity we can also get no. of independent paths in program the e.g. of code metric [refer notes]

3. Code structure : There are many different kinds of structure used in static analysis but

frequently used code structure are 1. Control Flow Structure : It addressed sequence of instruction during execution it provides

how the program structure is executed when a tester run the 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

Vidyala

nkar

ents, design sign

ether or not they or not they

ysis y

t welknown feature during static own feature during s s to define a coding standard efine a coding standa

dependent, usually a coding standent, usually a cong rules, naming conventions & s, naming convent

mended for s/w tester to adopfor s/w tester tntage of coding of coding standard is that i standard

testing. Main re esting. Main reason for adopting ason for adls are available which supports re available which su

forts will reduced. reduced.

orming static code analys static code analysis usealructural attributes of code, al attributes of cod freq

h of nesting, cyclomatic complexityng, cyclomatic coclomatic complexity metric is basclomatic complexity metric

very important for testor becauy important for ttesting necessary to pracsting necessary tocomplexity we can also getomplexity we can also of code metric [refer nof code metric [refer n

3.3 Code structure : Code structur There are many d There are

frequently usedeque 1. Control It ad

ho


18

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. 3. Identification of defects not easily found in dynamic testing. 4. Improved maintainability of codes & design seens engineers work

according to documented standards & rules 5. Prevention of defects, provided that’s engineers are wiling to learn

from their errors & continuous improvement is practiced. Q.5Attempt the following (any TWO) [10]Q.5(a) Explain White Box Testing. [5](A) The basis for white box technique is the source code of the test object

these techniques are often caused code based testing technique or structural testing technique.

Generic idea of white box technique is to execute every part of the code of test object atleast once flow oriented test cases are identified, analyzing program logic & then executed.

However the expected result should determine using requirement or specifications, not the code. These is done in order to decide if the execution resulted in failure.

The focus of examination of white box technique is on the statements of the test objects.

The primary goal of white box testing is then to achieve a previously define coverage of the statements, e.g. executes are possible statements in the program.

The basic white box test design technique are as follows: 1) Statements Coverage 2) Branch Coverage 3) Path Coverage Consider a e.g. of triangle problem (refer notebook) 1) Statement Coverage:

These analysis focuses on each statement of test object the test cases shall execute a predefined minimum quota or even all statements of test

Vidyala

nkar

code, design or design or

namic testing. sting. gn seens engineers work ns engineers work

les s t’s engineers are wiling to learn neers are wiling to

provement is practiced. ent is practiced.

hnique is the source code of the is the source coften caused ften cause code based testincode based

ique. box technique is nique to execute eveto execu

st once flow oriented test cases e flow oriented test then executed. xecuted.

e expected result shouected result should dettions, not the code. These ist the code. Th d

ion resulted in failure. ion resulted in failure. focus of examination of white bocus of examination

test objects. bjects. The primary goal of white box The primary goal of white bcoverage of the statementcoverage of the statementprogram. program.

The basic white box teThe basic white 1) Statements Cov1) Statem 2) Branch Cove 2) 3) Path Cove 3) Consid

1) S


19

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 of unidirectional statement appear in program fragment then they are illustrated as one single node. Conditional statements like if….else & loops like while, do …..while have more than one edges going out from them. After execution of test cases it must be verified which of the statements have been executed. Statement coverage 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

State Coverage = No. of executable Stat. x100Totalno. of stat.

2) Branch Coverage:

A more advance criteria for white box testing is branch coverage of control flow graph. e.g. Edges in the graph are Centre of tension. Execution of each statement is not consider during branch coverage but rather the execution of decisions are more important. The result of decision determines which statement is executed next. Branch coverage testing should make sure every decision with both possible outcomes i.e. true & false.

Test complition criteria for branch coverage is defined a

Branch Coverage = No. of executable branches x100Totalno. ofBranches

3) Path Coverage:

Until now test case determination focused on statement or branches of control flow as well as complexity repeatitions, the previous deliberations are not sufficient or not adequate test, path coverage requires execution of all different paths through test objects. The test completion criteria for P.C. cannot define mathematically because it will depends on no. of repeation of loop. No. of path coverage of test object can be determine using cyclomatic caomplexity, which gives total no. of maximum paths available in control flow.

Vidyala

nkar

ences n they are are

do …..while have .while have

erified which of the which of the overage must ensure that overage must ensure that

be executed at least once. executed at least once. define as as

nat. x100100

at.

for white bohite box testing is branchx testing

graph are Centre of tension. h are Centre of teot consider during r during branch covebranc

ecisions ns are more important. are more importa of decision determines ision determines which s

coverage testing should makege testing should sble outcomes i.e. true & false. mes i.e. true & fa

est complition criteria for st complition criteria for branch b

Branch Coverage = nch Coverage = yNo.of executNoTotaln. of execu

3) Path Coverage:3) Path Coverage:

Until now test case Until now tescontrol flow ascontrodeliberations iberrequires exThe tesbecauNo


20

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 equivalence program is tested by using set of valid & invalid i/p condition.

The domain of possible I/P data for each I/P data element is divided into equivalence classes.

[Equivalence class Partitioning] An equi. Class is group of data values where tester assumes that test

objects processes them in same way. The test of one representative of equivalence class is such as sufficient because it is assume that for any other I/P value for same equi. Class the test object will not show different variables.

Besides equi. Classes for correct I/P, those for incorrect I/P values must be tested as well. To test equi. Classes we have four diff. types of equivalence classes.

1) If continuous numerical domain is specified then create 1 valid & 2 invalid equivalence classes.

I/P Range 20 x 50 Valid x = {20,21…….49,50} Invalid i) x < 20 ii) x > 50 2) If no. of values should entered then create / valid (all possible correct

values) & 2 invalid equi. Classes (less & more than correct no.) I/P ……. Specific value a = 5 Valid x 5 Invalid x 5 or x < 5 x > 5 3) If set of values is specifies where each value may possibly be treated

differently then create one valid equivalence class for each value of set (containing exactly these values) & one additional invalid equi. Class (containing all possible other value).

I/P Member of set x = {a, e, i, o, u} valid x (a, e, i, o, u) Invalid 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.

& evep condition. ion

ent is divided divide

ter assumes that test mes that test of one representative of e representative of

use it is assume that for any e it is assume that for a the test object will not show st object will not

I/P, those for incorrect I/P vahose for incorre equi. Classes we have four diff. tyasses we have four

domain is specified then create is specified thses. es.

50 {20,21…….49,50} 1…….49,50} i) x < 20 < 20

ii) x > 50 ii) x > 50 of values should entered s should entered then c

ues) & 2 invalid equi. Classes ues) & 2 invalid equi. Classe (less I/P ……. Specific value P ……. Specific valu

a = 5 a = 5 Valid Valid x 5 5 Invalid Inval x 5 or x < 5 5 or x < 5

x > 5 x > 5 3) If set of values i3) If set of v

differently theffere(containing (containin

I/


21

I/P Boolean Value Valid TRUE Invalid 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

100No. of testedECEqu.Class coverageTotalno. ofEC

2) Boundary Value Analysis: It delivers a very reseanable addition to the test cases that have been

identified by equi. Classes. Faults often appears at the boundaries of equi. Classes. In boundary

value analysis s/w tester emphasizes on boundary condition because maximum no. of errors are generally occurs at boundary rather that within operational bound. Testers assume that if software works properly on the boundary then it will definetly work within boundary condition.

The most of the errors in software lies on boundary because boundaries are often not defined clearly or programmers misunderstand them.

A test with boundary values useally discovers the failure the technique can only we applied if set of data which is in one equi. Class has identifiable boundaries.

Boundaries value Analysis checks borders of equi. Classes on every border, the exact boundary value & both nearest adjecent value (Inside / Outside Equi. Class) are tested.

If the I/P condition for the program is the range within close internal ([a , b]) then using B VA we have six test cases as follows.

1) [a,b] a 1, a a + 1 b 1 b b + 1 2) An I/P file has restricted number of data records between 1 & 100

the test values should be 1,100,2,99. 3) If permitted no. of O/P values is to be rested, proceed just as with

the no. of input values: If O/P of 1 4 data values are, test accoured, test cases are 1, 4, 0, 5 Test complition criteria for Boundary value is define as

No. of testedBVBV coverage 100TotalNo. ofBV

=

Vidyala

nkar test cases that have been test cases that have been

s of equi. Classes. In boundary ui. Classes. In boues on boundary condition becaus boundary condition

rally occurs at boundary rather curs at boundarysters assume that if softwaressume that if so

hen it will definetly work withinwill definetly work

s in software in softwar lies on boundary bec lies on bounded clearly or arly o programmers misundeprogrammers m

ndary values useas useally discovers they discov applied if set of datad if set of data which is

boundaries. rieies value Analysis checks bordeue Analysis checks

er, the exact boundary value & boact boundary va Outside Equi. Class) are tested. Outside Equi. Class) are tes

If the I/P condition for the pro the I/P condition ([a , b]) then using B VA we haa , b]) then using B VA

1) [a,b] 1) [a,b] a a 1, a a + 1 a + 1 2) An I/P file has r 2) An I/P fil

the test valuethe te 3) If permitt 3) If

the no. o If O/P o Test c

B


22

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 similar 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 2) Exploratory testing 1) Error Guessing: It is a technique that should always be use as complement to other more

formal technique the success of error Guessing is very much depend on skill of tester, as good tester knows where the defects are most likely to occur.

Some people seem to be naturally good at testing as they have experience in testing of variety of software. Error guessing approach is used after more formal techniques that have been applied to same extent can be very effective.

In these technique the tester is likely to gain better understanding of system what is does & how it does, & with these better understanding the tester is likely to be better at guessing ways in which the system may not work properly.

There are no rules for error guessing. The tester is encourage to think of situations in which s/w may not be

able to code. Typical conditions to try includes division by zero, blank I/P , empty files

and wrong data I/P if anyone even says a system or environment in which s/w is not operate then error guessing is first methodology to operate software.

By using error guessing tester can find no. of errors by his own experience or common sense approach. Error guess methods saves a lot of time during testing.

2) Exploratory Testing: It is hands on approach in which testers are involve in minimum planning

& maximum 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.

Vidyala

nkar simi

very useful efu

e as complement to other more omplement to other Guessing is very much depend osing is very much de

ws where the defects are most lire the defects ar

naturally good at testing as tlly good at testin ariety of of software. Error guessinsoftware. Err

mal techniques al techniques that have been athat have ffective. ctive.

ue the tester is lister is likely to gain bekely to s does & how it doess & how it does, & with the & w

is likely to be better aty to be better at guessing work properly. roperly

e are no rules for error guessing. ules for error gue tester is encourage to think ofe tester is encourage to t

able to code. e to code. Typical conditions to try includpical conditions to tr

and wrong data I/P if anyonnd wrong data I/P if as/w is not operate then/w is not operate thensoftware. software.

By using error g By using eexperience or cperieof time durin

2)2) Explorato It is h

& m


23

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](A) Used Case Based Technique: In order to detect requirements, use cases or business cases are describe

these are then compiled into use case diagram, it is used to describe behavioral model of the system diagram consist of actors and uses cases where actors are active elements present in system and use cases are simply task or responsibilities of actor in given system.

Use case diagram serve the purpose of definning requirement on a relatively abstract level & describe typical user system interaction. UCD mainly serve to show external view of system it shall explain external view of system from the viewpoint of user or relation to neighbouring system.

UCD serve as basis for determining test case testing as external view is model technique is useful for both system testing & acceptance testing.

The following is necessary for determining test cases for UCBT. 1) Start Situation and Preconditions 2) Other Possible Condition 3) Expected Results 4) Post Conditions F.g. for use case diagram for use case diagram notation. 1) Actor stickman name of order 2) Use cases (Name of use cases…) 3) Association 4) System Boundary Box 5) Rotation include << include >> Extend << extends >>

Vidyala

nkar

[5][5

cases are describe are describe t is used to describe d to describe

of actors and uses cases ors and uses cases stem and use cases are simply em and use cases are sim

em. efinning requirement on a relativeg requirement on a r

system interaction. UCD mainly s interaction. UCD t shall explain expla external view of xternal v

ation to neighbouring system. to neighbouring systeermining testg test case testing as ext case testi

or both system testing & acceptanor both system testing & ary for or determining test cases for determining test cas

nd Preconditions ditionse Condition ition

Results ditions

se case diagram foagram for use case diagr use c

Actor stickman name of order or stickman nam2) Use cases e cases (Name of use casName of 3) Association 3) Association

4) System Boundary Box 4) System Boundary Box 5) Rotation 5) Rotation include << inclu include Extend << e Ext

dydyddyddy


24

Q.6Attempt the following (any TWO) [10]Q.6 (a) Explain roles and responsibilities of test leader in an organization. [5](A) Roles of test leader in test organisation : Test leaders tends to be involved in planning, monitoring, & control of testing

activity & tasks. At the outset of project, test leaders, in collaboration with other stakeholders, device test objectives, organizational test policies, test strategies, & test plans.

They estimate testing to be done & negotiate with management to acquire necessary resources they recognize when test automation as appropriate & it is they plan the effort, select the tools & ensure training of the team.

They may consult with other groups e.g. programers, to help them with their testing. They lead guide & monition the analysis, design, implementation & exception of test cases, test procedures & test suites. They ensure proper configuration management of the test ware produced & traceability of tests to test basis.

As test execution comes near, they make sure the test environment is put into place before test execution & manager during text execution. They monitor, control & report on the test progress, the product quality states & the test result.

Issue Return Book

Pay Fine Read NewspaperInternet access

Study/assignment

Collect Maintain BooksMaintain Students

record

Stock Place order

Cost estimationVerified Supply book

Verify Library card

<<include>>

<<include>>

Prepare list of books

Place order

Make payment

Verify order

Order book

<<extend>> Supplier

Librarian Student

Vidyala

nkar

ny TWO) responsibilities ofnsibilities of test leader in test lea

ader in test organisation : test organisation : s tends to be involved in planning, m to be involved in pl

& tasks. At the outset of project the outset of t, stakeholders, device test objecti stakeholders, device test o

ategies, & test plans. gies, & test plans. They estimate testing to be done estimate testing to necessary resources they recossary resources they rit is they plan the effort, seit is they plan the effort, se

They may consult with ot They may consult testing. They lead guting. They lexception of test cexception configuration macoto test basis.to t

As test exAs into plamont

aaaan

pp y ook nnananknknkknknSupplie

rian


25

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 Co ordinator.

Q.6 (b) What are the skills required for test staff. [5](A) Doing testing properly requires more than defining the right position &

number of people for those position. Good test teams have the right mix of skill based on tasks & activities they need to carry out & people outside team who are in charge of test task need the right skills too

People involved in testing need basic professional & social qualification such as literary, the ability to prepare & communicated effectively & so on. Going beyond that when we think of the skill that test need three main areas to me to main.

Application or business domain : A tester must understand the intended behavior, the problem the system will solve, the process it will automate.

Technology : A tester must be aware of issues, limitation & capabilities of chose

implementation technology, in order to effectively and efficiently locate problem & recognize the “likely to fail” functions & features.

A tester must know testing in order to efficiently carry out the test tasks assigned.

Q.6 (c) Explain test strategies and approaches used in testing. [5](A) The choice of test approaches or strategies is one powerful factor in

success of test effort & accuracy of test plan & estimates. This factor is under control of testor & test leaders 1. Analytical 2. Model based 3. Methodical 4. Process or standard compliant 5. Dynamic 6. Consultative or directed 7. Risk 8. Skill 9. Objectives 10. Regulations 11. Product 12. Business.

Vidyala

nkar

[ position & n &

e right mix of mix oople outside team utside team

social qualification such lification such effectively & so on. Going effectively & so on. Going

est need three main areas to t need three main areas

er must understand the intendest understand the solve, the process it will automate.he process it will a

ssues, limitation & capabilities limitation & capab n order tor to effectively and effic effectively kely kely to fail” functions & features. ail” functions & fe

ting in order to efficientl in order to efficiently carry

trategies and approaches used ins and approaches of test approaches or stst approaches or rateg

of test effort & accuracyfort & accuracy of test p actor is under control of testor & actor is under control of te

Analytical alytical 2. Modeldel based base3. Methodical 3. Methodical

4. Process or standard com 4. Process or standard com 5. Dynamic 5. Dynamic 6. Consultative or dir6. Consultativ 7. Risk 7. Risk 8. Skill 8. 9. Objectiv 9. 10. Regula10 11. Pro

12.


26

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 of project & betray you at middle or end.

The test strategies or approaches you pick will have a major influent on testing effort.

Product factor start with presence of sufficient project documentation so that testers can figure out what system is, how is opposed work & what correct behaviour look like.

The importance of non functional quality characteristic such as usability, reliability, security, performance, & so forth influences the testing effort.

These test target can be expensive & time consuming. Complexity is another major product factor. The difficulty of

comprehending & correctly handling the problem they system is being built to solve use of innovative technologies.

The need for intricate & perhaps multiple test configuration especially when these rally on the timely arrival of scarce software, hardware & other supplies.

The privalence of stringent security rules. The privelence of stringent security rule, strictly regimented process or other regulation geographical distribution of team especially if team croseses time zones.

Q.7Attempt the following (any THREE) [15]Q.7(a) Explain potential benefits and risks of using tools. [5](A) Tool can be any device which reduces human efforts & makes the task easier

every machines are a tool but every tool need not be a machine e.g. of tools are calculator, hammer, etc. The potential benefits of tools are 1. Tool reduces the human efforts 2. Using tools user can save their time 3. Using tool, it reduces repetitive work 4. Greater consistency repetitive work 5. Objective assessment 6. Ease of access to information about test or testing Risk of Using tools : 1. Unrealistic expectations for the tool 2. Underestimating time, cost & effort initial introduction of tool

Vidyala

nkarnning

or influent on ent o

ct documentation so umentation so opposed work & what work & what

acteristic such as usability, cteristic such as usabili influences the testing effort. ces the testing effo

e consuming. umingoduct factor. The difficulty factor. The d

the problem they system is beinoblem they systemogies.

aps multipultiple test configuration esle test config arrival of arrival of scarce software, har scarce softwa

tringent security securi rules. The pr rules. ctly regimented proc egimented process or othess o

team especially pecially if team croseses tif team cr

following (any (any THREEHRE ) ) n potential benefits and risksn potential benefits and ri of

ol can be any device which reducesn be any device whevery machines are a tool but ever machines are a tool be.g. of tools are cae.g. of tools are calculator, hamor, The potential benefits of tThe potential benefits of

1. Tool reduces the hum 1. Tool reduces t 2. Using tools user 2. Using tools ca 3. Using tool, it re3. Using t 4. Greater cons 4. 5. Objective 5. 6. Ease o6

Risk 1


27

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](A) Requirement management tools are used to gather requirement form end

users. e.g. of requirement management tools is are we portals. Set of questionnaire Features of characteristics of requirements management tools including

support for : 1. Storing requirements statements. 2. Storing information about requirement attributes. 3. Checking consistency of requirement 4. Identify undefined, missing or to be defined later requirements. 5. Prioritizing requirements for testing purposes. 6. Traceability through levels of requirements 7. Interfacing to test management tools 8. Coverage of requirements by set of test. Test management tools are use to manage entire test process. It starts

from test data preparation, test data exaction towards the preparation of final result of how many test & outstanding.

The features or characteristics of test management tools are 1. Management of test 2. Scheduling of test to be executed (manually or by a test execution

tools). 3. Management of testing activites (time spent in test design, test

execution whether we are on schedule or. Q.7(c) Explain features and characteristic of incident configuration

management tools. [5]

(A) Configuration management tools are used whenever any changes encounter during software life cycle software configuration management is an art of identifying and implementing necessary changes in a software.

Software configuration management tools are use when any request for change is encountered by end users or developer

Vidyala

nkar

. [5][5rement form end form end

s.

management tools including management tools includ

ment attributes. ributes. ment

r to be defined later requiremente defined later requi for testing purposes. sting purposes.

vels of requirements vels of requirements management tools gement tools

irements by set of test. y set of test.

ent tools are use to manas are use to man ge ent ata preparation, test dataeparation, test data exact

ult of how many test & outstanding many test & outeatures or characteristiceatures or characteristics of test s o

Management of test nagement of test 2. Scheduling of test to be exheduling of test to

tools). ools 3. Management of testin 3. Management of testin

execution whether wexecution whe Q.7(c) Explain features (c) Explain f

management tooma(A)(A) Configuration Con

during sofduridentifSof


28

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 1. Staring information about version & builds of the software & testuare. 2. Traceability between software and test ware & different versions &

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

s. libraries) 4. Reporting of statistics/metrics about incidents 5. Access control Incident Management Tools : These are used when there is incident occur during software execution Features or characteristics of incident management tools

1. Storing information about attributes of incidents. 2. Storing attachments (e.g. screenshot) 3. Prioritizing incidents. 4. Assigning actions to people (Fix, confirmation test) 5. Status (e.g. open, rejected, duplicate, dereffered, closed) 6. Reporting of statistics/metric about incidents (e.g. average time open) 7. Number of incidents with each status, total number raised, open or

closed. Q.7(d) Explain reporting and characteristics of unit test tools and security

tools. [5]

(A) Unit test framuvark tool is use to perform unit testing on software component

Features / Characteristic includes Supplying inputs to the unit/ module of software Receiving o/p generated by unit of software Which are being tested Executing set of test cases on s/w unit Record the result of each test case performed on each unit using pass or fail

basis Storing the result of test cases Support for debugging Covering measurement at code level

Vidyala

nkar

ncludes s e & testuare. are.

ferent versions & t versions &

ch configurations (e.g. o. figurations (e.g. o.

dents

ent occur during software execut during software incident management tools nt management t

bout attributes of incidents. ut attributes of incidents (e.g. screenshot) screenshot)

ents. ions to peop people (Fix, confirmation tle (Fix, conf

g. open, rejected ejected, duplicate, deref, duplicateng of statistics/metric ab tatistics/metric about inci

ber of incidents with each idents with ea statosed. sed

Explain reporting and characterin reporting and chartools. tools.

A)A) Unit test framuvark too Unit test framuvark toocomponent omponent

Features / CharacterFeatures Supplying inputs tSupplying i Receiving o/p g Re Which are b Wh ExecutingE

Recorbas


29

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 application code or underlying database.

Features or characteristics of security testing tools includes support for : 1. Identifying software’s. 2. Detecting instructions such as deniel of service attacks 3. Simulating various types of service attack 4. Probing for open ports or other externally visible points of attacks 5. Identifying weakness in password files & passwords 6. Security cheeks during operation. E.g. for checking integrity of files &

intrusion detection e.g. checking result of test attacks. Q.7(e) Explain Agile methodology in details. [5](A) Agile Model 1. Extreme programming is currently one of the most well known agile

development life cycle model. 2. The methodology claims to be more human friendly than the traditional

development method. 3. Using Agile model, Developer can develop simple and Interesting GUI for

S/W. Some of the characteristics of XP are: It promotes the generation of business stories to define functionality. It demands an on side costumer for continues feedback and to define

and carry out functional test. It promotes pair programming and shared code ownership among

developers. It states that component test scripts shall be written before code is

written and those test should be automated. It states that integration and testing of code shall happen several times

a day. It always states that we should always implement simplest that should

meet solutions to the today’s problem.

Vidyala

nkar

e application cation

es support for : port for :

ttacks

visible points of attacks ble points of attacks & passwords ds

E.g. for checking integrity of filer checking integ result of test attacks. of test attacks

details..

ng is currently one of the most is currently one of th ycle model. el.

gy claims to be moreims to be more human frien humat method. d.

ile model, Developer can del, Developer can develop sd

of the characteristics of XP are of the characteristics of It promotes the generation of bu promotes the gene It demands an on side costum demands an on side

and carry out functional tend carry out functiona It promotes pair pro It promotes pair pro

developers. developers. It states that coIt sta

written and thtten It states th

a day. It alw

me


30

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 Generating Expected Result if an oracle is available to the tool Test Data Preparation Tool: 1. Extracted Selected data records from files or database.

2. ‘Massage Data Records’ to make them anonymous and or not able to identified with real people (For data protection);

3. Enable records to be shored or arranged in different order. 4. Generate new records populated with pseudorandom data, or data set up

according to some guidelines e.g. an operational profile. 5. Constrict a large number of similar records from template to give large

set of records for volume test. Test Execution Tools: 1. Capturing (record) test inputs while test are execute manually. 2. Storing an expected result in the form of screen or object to compare to

the next time test is run Executing test from scored script and optionally data files accessed by script.

3. Dynamic comparison (while test is running) of screen elements, links, controls, objects and values;

4. Ability to initiate post execution comparison logging result for example : Exciting the screed displayed current data and time which is not of interest to a particular test.

Synchronising input with the application under test e.g. wait unfill the application.

Vidyala

nkar the tool

es or database. database. m anonymous and or not able tnymous and or not

protection); tion); rranged in different order. in different order.

ed with pseudorandomh pseudora data, or d dats e.g. an operational profile. an operational pro

r of similar r of similar records from templaecords from ume test. e test

ols: ecord) test inputs est inputs while test are e while te

n expected result in the focted result in the f rm of sxt time test is run Executing te est is run Execut st

a files accessed by script. a files accessed by script. Dynamic comparison (while test amic comparison (controls, objects and values; trols, objects and va

4. Ability to initiate post execbility to initiate post eExciting the screed disciting the screed disinterest to a particulainterest to a pa

Synchronising input wnchronising application.application

t.y. b.sc. (it) software testing - vidyalankarvidyalankar.org/upload/st_soln.pdf · t.y. b.sc. (it)...

Documents