FAQ_Testingdocument1

8/13/2019 FAQ_Testingdocument1

1/30

Software Testing FAQ

Explain the software development lifecycle.

There are seven stages of the software development lifecycle

1. Initiate the project The !sers identify their "!siness re#!irements.$. %efine the project The software development team translates the &!siness

re#!irements into system specifications and p!t together into System

Specification %oc!ment.

'. %esign the system The System Architect!re Team designs the system and

write F!nctional %esign %oc!ment. %!ring design phase general sol!tions re

hypothesi(ed and data and process str!ct!res are organi(ed.

). "!ild the system The System Specifications and design doc!ments are given

to the development team code the mod!les &y following the *e#!irements and

%esign doc!ment.

+. Test the system , The test team develops the test plan following the

re#!irements. The software is &!ild and installed on the test platform afterdevelopers have completed development and -nit Testing. The testers test the

software &y following the test plan.

. %eploy the system After the !ser,acceptance testing and certification of the

software/ it is installed on the prod!ction platform. %emos and training are

given to the !sers.

0. S!pport the system , After the software is in prod!ction/ the maintenance

phase of the life &egins. %!ring this phase the development team wors with

the development doc!ment staff to modify and enhance the application and

the test team wors with the test doc!mentation staff to verify and validate

the changes and enhancement to the application software.

2hat is software #!ality34

5*

%efine software #!ality for me/ as yo! !nderstand it4

Q!ality software is reasona&ly &!g,free/ delivered on time and within &!dget/ meets

re#!irements and6or expectations/ and is maintaina&le. 7owever/ #!ality is

o&vio!sly a s!&jective term. It will depend on who the 3c!stomer3 is and their overall

infl!ence in the scheme of things. Each type of 3c!stomer3 will have their own slant

on 3#!ality3 , the acco!nting department might define #!ality in terms of profits

while an end,!ser might define #!ality as !ser,friendly and &!g,free.

2hat3s the role of doc!mentation in QA4

8ritical. 9:ote that doc!mentation can &e electronic/ not necessarily paper.; QA

practices sho!ld &e doc!mented s!ch that they are repeata&le. Specifications/

designs/ &!siness r!les/ inspection reports/ config!rations/ code changes/ test plans/

test cases/ &!g reports/ !ser man!als/ etc. sho!ld all &e doc!mented. There sho!ld

ideally &e a system for easily finding and o&taining doc!ments and determining

what doc!mentation will have a partic!lar piece of information. 8hange

management for doc!mentation sho!ld &e !sed if possi&le.


2/30

At what stage of the S% Tester will !se the

re#!irement doc!ment to write the test cases.

$. Esta&lishing the hard free(e date> 7ard free(e date is a date after which

system test team will not accept any more software and doc!mentation

changes from development team/ !nless they are fixes of severity 1 ?*@s.

The date is sched!led so that prod!ct test team will have time for final

regression.

'. 2riting master test plan> It is written &y the lead tester or test coordinator.

?aster test plan incl!des entire testing plan/ testing reso!rces and testingstrategy.

). Setting !p ?* Tool> The ?* tool m!st &e set as soon as yo! now of the

different mod!les in the prod!ct/ the developers and testers on the prod!ct/

the hardware platform/ and operating system testing will &e done.

This information will &e availa&le !pon the completion of the first draft of

the architect!re doc!ment. "oth testers and developers are trained how to

!se the system.

+. Setting !p the test environment> The test environment is set on separate

machines/ data&ase and networ. This tas is performed &y the technical

s!pport team. First time it taes some time/ Afterwards the same

environment can &e !sed &y the later releases.

. 2riting the test plan and test cases> Template and the tool is decided to

write the test plan/ test cases and test proced!res. Expected res!lts are

organi(ed in the test plan according to the feat!re categories specified in the

re#!irement doc!ment. For each feat!re positive and negative test cases are

written. 2riting test plan re#!ires the complete !nderstanding of the

prod!ct and its interfaces with other systems. After test plan is completed/ a

walthro!gh is cond!cted with the developers and design team mem&ers to

&aseline the test plan doc!ment.

0. Setting !p the test a!tomation tool> =lanning of test strategy on how to

a!tomate the testing. 2hich test cases will &e exec!ted for regression testing.

:ot all the test cases will &e exec!ted d!ring regression testing.

. Identify acceptance test cases> Select s!&sets that are expected on the first

day of system test. These tests m!st pass to accept the prod!ct in the system

test.

Acceptance testing phase>

1. 2hen the prod!ct enters system test/ chec it has completed integration test

and m!st meet the integration test exit criteria.


3/30

$. 8hec integration exit criteria and prod!ct test entrance criteria in the

master test plan or test strategy doc!ments.

'. 8hec the integration testing sign off criteria sheet.

). 8oordinate release with prod!ct development.

+. 7ow the code will &e migrated from development environment to the test

environment.. Installation and acceptance testing.

=rod!ct testing phase>

1. *!nning the test> Exec!tion of test cases and verify if act!al f!nctionality of

application matches the expected res!lts.

$. Initial man!al testing is recommended to isolate !nexpected system &ehavior.

5nce application is sta&le a!tomated regression test co!ld &e generated.

'. Iss!e ?*@s !pon detection of the &!gs.

2hat is the val!e of a testing gro!p4 7ow do yo! j!stify yo!r wor and &!dget4

All software prod!cts contain defects6&!gs/ despite the &est efforts of theirdevelopment teams. It is important for an o!tside party 9one who is not developer;

to test the prod!ct from a viewpoint that is more o&jective and representative of the

prod!ct !ser.

Testing gro!p test the software from the re#!irements point of view or what is

re#!ired &y the !ser. Testers jo& is to examine a program and see if it does

not do what it is s!pposed to do and also see what it does what it is not

s!pposed to do.

2hat is master test plan4 2hat it contains4 2ho is responsi&le for writing it4

5*2hat is a test plan4 2ho is responsi&le for writing it4 2hat it contains.

5*

2hat3s a 3test plan34 2hat did yo! incl!de in a test plan4

A software project test plan is a doc!ment that descri&es the o&jectives/ scope/

approach/ and foc!s of a software testing effort. The process of preparing a test plan

is a !sef!l way to thin thro!gh the efforts needed to validate the accepta&ility of a

software prod!ct. The completed doc!ment will help people o!tside the test gro!p

!nderstand the 3why3 and 3how3 of prod!ct validation. It sho!ld &e thoro!gh eno!gh

to &e !sef!l &!t not so thoro!gh that no one o!tside the test gro!p will read it. The

following are some of the items that might &e incl!ded in a test plan/ depending on

the partic!lar project>

Title

Identification of software incl!ding version6release n!m&ers

*evision history of doc!ment incl!ding a!thors/ dates/ approvals

Ta&le of 8ontents

=!rpose of doc!ment/ intended a!dience

5&jective of testing effort


4/30

Software prod!ct overview

*elevant related doc!ment list/ s!ch as re#!irements/ design doc!ments/

other test plans/ etc.

*elevant standards or legal re#!irements

Trace a&ility re#!irements

*elevant naming conventions and identifier conventions

5verall software project organi(ation and personnel6contact,

info6responsi&ilties

Test organi(ation and personnel6contact,info6responsi&ilities

Ass!mptions and dependencies

=roject ris analysis

Testing priorities and foc!s

Scope and limitations of testing

Test o!tline , a decomposition of the test approach &y test type/ feat!re/

f!nctionality/ process/ system/ mod!le/ etc. as applica&le

5!tline of data inp!t e#!ivalence classes/ &o!ndary val!e analysis/ error

classes

Test environment , hardware/ operating systems/ other re#!ired software/

data config!rations/ interfaces to other systems

Test environment validity analysis , differences &etween the test and

prod!ction systems and their impact on test validity.

Test environment set!p and config!ration iss!es

Software migration processes

Software 8? processes

Test data set!p re#!irements

%ata&ase set!p re#!irements 5!tline of system,logging6error,logging6other capa&ilities/ and tools s!ch as

screen capt!re software/ that will &e !sed to help descri&e and report &!gs

%isc!ssion of any speciali(ed software or hardware tools that will &e !sed &y

testers to help trac the ca!se or so!rce of &!gs

Test a!tomation , j!stification and overview

Test tools to &e !sed/ incl!ding versions/ patches/ etc.

Test script6test code maintenance processes and version control

=ro&lem tracing and resol!tion , tools and processes

=roject test metrics to &e !sed

*eporting re#!irements and testing delivera&les Software entrance and exit criteria

Initial sanity testing period and criteria

Test s!spension and restart criteria

=ersonnel allocation

=ersonnel pre,training needs

Test site6location


5/30

5!tside test organi(ations to &e !tili(ed and their p!rpose/ responsi&ilties/

delivera&les/ contact persons/ and coordination iss!es

*elevant proprietary/ classified/ sec!rity/ and licensing iss!es.

5pen iss!es

Appendix , glossary/ acronyms/ etc.

The team,lead or a Sr. QA Analyst is responsi&le to write this doc!ment.

2hy is test plan a controlled doc!ment4

"eca!se it controls the entire testing process. Testers have to follow this test plan

d!ring the entire testing process.

2hat information yo! need to form!late test plan4

:eed the "!siness re#!irement doc!ment to prepare the test plan.

2hat is ?*4

?* is a ?odification *e#!est also nown as %efect *eport/ a re#!est to modify theprogram so that program does what it is s!pposed to do.

2hy yo! write ?*4

?* is written for reporting pro&lems6errors or s!ggestions in the software.

2hat information does ?* contain4

5*

%escri&e me to the &asic elements yo! p!t in a defect report4

5*

2hat is the proced!re for &!g reporting4

The &!g needs to &e comm!nicated and assigned to developers that can fix it. Afterthe pro&lem is resolved/ fixes sho!ld &e re,tested/ and determinations made

regarding re#!irements for regression testing to chec that fixes didn3t create

pro&lems elsewhere. If a pro&lem,tracing system is in place/ it sho!ld encaps!late

these processes. A variety of commercial pro&lem,tracing6management software

tools are availa&le.

The following are items to consider in the tracing process>

8omplete information s!ch that developers can !nderstand the &!g/ get an

idea of its severity/ and reprod!ce it if necessary.

"!g identifier 9n!m&er/ I%/ etc.;

8!rrent &!g stat!s 9e.g./ 3*eleased for *etest3/ 3:ew3/ etc.;

The application name or identifier and version

The f!nction/ mod!le/ feat!re/ o&ject/ screen/ etc. where the &!g occ!rred

Environment specifics/ system/ platform/ relevant hardware specifics

Test case name6n!m&er6identifier

5ne,line &!g description

F!ll &!g description


6/30

%escription of steps needed to reprod!ce the &!g if not covered &y a test case

or if the developer doesn3t have easy access to the test case6test script6test tool

:ames and6or descriptions of file6data6messages6etc. !sed in test

File excerpts6error messages6log file excerpts6screen shots6test tool logs that

wo!ld &e helpf!l in finding the ca!se of the pro&lem

Severity estimate 9a +,level range s!ch as 1,+ or 3critical3,to,3low3 is common; 2as the &!g reprod!ci&le4

Tester name

Test date

"!g reporting date

:ame of developer6gro!p6organi(ation the pro&lem is assigned to

%escription of pro&lem ca!se

%escription of fix

8ode section6file6mod!le6class6method that was fixed

%ate of fix

Application version that contains the fix

Tester responsi&le for retest

*etest date

*etest res!lts

*egression testing re#!irements

Tester responsi&le for regression tests

*egression testing res!lts

2hat is 2hite &ox testing6!nit testing4

-nit testing , The most 3micro3 scale of testingB to test partic!lar f!nctions or code

mod!les. Typically done &y the programmer and not &y testers/ as it re#!iresdetailed nowledge of the internal program design and code. :ot always easily done

!nless the application has a well,designed architect!re with tight codeB may re#!ire

developing test driver mod!les or test harnesses.

2hat is Integration testing4

Integration testing , Testing of com&ined parts of an application to determine if they

f!nction together correctly. The 3parts3 can &e code mod!les/ individ!al

applications/ client and server applications on a networ/ etc. This type of testing is

especially relevant to client6server and distri&!ted systems.

2hat is "lac &ox testing4"lac "ox testing is also called system testing which is performed &y the testers.

7ere the feat!res and re#!irements of the prod!ct as descri&ed in the re#!irement

doc!ment are tested.

2hat nowledge yo! re#!ire to do white &ox/ integration and &lac &ox testing4


7/30

For white &ox testing yo! need to !nderstand the internals of the mod!le lie data

str!ct!res and algorithms and have access to the so!rce code and for &lac &ox

testing only !nderstanding6f!nctionality of the application.

2hat is *egression testing4

*egression testing> *e,testing after fixes or modifications of the software or itsenvironment. It can &e diffic!lt to determine how m!ch re,testing is needed/

especially near the end of the development cycle. A!tomated testing tools can &e

especially !sef!l for this type of testing..

2hy do we do regression testing4

In any application new f!nctionalities can &e added so the application has to &e

tested to see whether the added f!nctionalities have affected the existing

f!nctionalities or not. 7ere instead of retesting all the existing f!nctionalities

&aseline scripts created for these can &e rer!n and tested.

7ow do we regression testing4Cario!s a!tomation testing tools can &e !sed to perform regression testing lie

2in*!nner/ *ational *o&ot and Sil Test.

2hat is Integration testing4

Testing of com&ined parts of an application to determine if they f!nction together

correctly. The 3parts3 can &e code mod!les/ individ!al applications/ client and server

applications on a networ/ etc. This type of testing is especially relevant to

client6server and distri&!ted systems.

2hat is the difference &etween exception and validation testing4

Calidation testing aims to demonstrate that the software f!nctions in a manner that

can &e reasona&ly expected &y the c!stomer. Testing the software in conformance to

the Software *e#!irements Specifications.

Exception testing deals with handling the exceptions 9!nexpected events; while the

A-T is r!n. "asically this testing involves how to change the control flow of the

A-T when an exception arises.

2hat is the difference &etween regression a!tomation tool and performance

a!tomation tool4

*egression testing tools capt!re test and play them &ac at a later time. The capt!re

and play&ac feat!re is f!ndamental to regression testing.

=erformance testing tool determine the load a server can handle. And m!st have

feat!re to stim!late many !sers from one machine/ sched!ling and synchroni(e

different !sers/ a&le to meas!re the networ load !nder different n!m&er of

sim!lated !sers.

2hat are the roles of glass,&ox and &lac,&ox testing tools4


8/30

Dlass,&ox testing also called as white,&ox testing refers to testing/ with detailed

nowledge of the mod!les internals. Th!s these tools concentrate more on the

algorithms/ data str!ct!res !sed in development of mod!les. These tools perform

testing on individ!al mod!les more liely than the whole application. "lac,"ox

testing tools refer to testing the interface/ f!nctionality and performance testing of

the system mod!le and the whole system.

2hat was the test team hierarchy4

=roject


9/30

7ow do yo! feel a&o!t cyclomatic complexity4

8yclomatic complexity is a meas!re of the n!m&er of linearly independent paths

thro!gh a program mod!le. 8yclomatic complexity is a meas!re for the complexity

of code related to the n!m&er of ways there are to traverse a piece of code. This

determines the minim!m n!m&er of inp!ts yo! need to test all ways to exec!te the

program.

2ho sho!ld test yo!r code4

QA Tester

7ow do yo! s!rvive chaos4

I s!rvive &y maintaining my calm and foc!sing on the wor.

2hat =rocess6?ethodologies are yo! familiar with4

2aterfall methodology

Spiral methodology

5r tal a&o!t 8!stomi(ed methodology of the specific client

2hat yo! will do d!ring the first day of jo&4

Det ac#!ainted with my team and application

Tell me a&o!t the worst &oss yo!@ve ever had.

Fort!nately I always had the &est &osses/ taling in professional terms I had no

complains on my &osses.

2hat is a s!ccessf!l prod!ct4

A &!g free prod!ct/ meeting the expectations of the !ser wo!ld mae the prod!cts!ccessf!l.

2hat do yo! lie a&o!t 2indows4

Interface and -ser friendliness

2indows is one the &est software I ever !sed. It is !ser friendly and very easy to

learn.

2hat is good code4

These are some important #!alities of good code

8leanliness> 8lean code is easy to readB this lets people read it with minim!m effort

so that they can !nderstand it easily.8onsistency> 8onsistent code maes it easy for people to !nderstand how a program

worsB when reading consistent codeB one s!&conscio!sly forms a

n!m&er of ass!mptions and expectations a&o!t how the code wors/

so it is easier and safer to mae modifications to it.

Extensi&ility> Deneral,p!rpose code is easier to re!se and modify than very specific

code with lots of hard coded ass!mptions. 2hen someone wants to add a new


10/30

feat!re to a program/ it will o&vio!sly &e easier to do so if the code was designed to

&e extensi&le from the &eginning.

8orrectness> Finally/ code that is designed to &e correct lets people spend less time

worrying a&o!t &!gs and more time enhancing the feat!res of a program.

2ho are Gent "ec/ %r Drace 7opper/ and %ennis *itchie4Gent "ec is the a!thor of Extreme =rogramming Explained and The Smalltal

"est =ractice =atterns.

%r. Drace ?!rray 7opper was a remara&le woman who grandly rose to the

challenges of programming the first comp!ters. %!ring her lifetime as a leader in

the field of software development concepts/ she contri&!ted to the transition from

primitive programming techni#!es to the !se of sophisticated compilers.

%ennis *itchie created the 8 programming lang!age.

7ow yo! will &egin improve the QA process4

"y following QA methodologies lie waterfall/ spiral instead of !sing ad,hoc

proced!res.

2hat is -?< and how it is !sed for testing4

The -nified ?odeling


11/30

2hat are 8?? and 8??I4 2hat is the difference4

The 8apa&ility ?at!rity ?odel for Software 98?? or S2,8??; is a model for

j!dging the mat!rity of the software processes of an organi(ation and for

identifying the ey practices that are re#!ired to increase the mat!rity of these

processes.

The 8apa&ility ?at!rity ?odel Integration 98??I; provides the g!idance for

improving yo!r organi(ation3s processes and yo!r a&ility to manage the

development/ ac#!isition/ and maintenance of prod!cts and services. 8??

Integration places proven practices into a str!ct!re that helps yo!r organi(ation

assess its organi(ational mat!rity and process area capa&ility/ esta&lish priorities

for improvement/ and g!ide the implementation of these improvements.

The new integrated model 98??I; !ses =rocess Areas 9nown as =As; which are

different to the previo!s model/ and covers as well systems as software processes/

rather than only software processes as in the S2,8??.

%o yo! have a favorite QA &oo4 2hy4

Effective ?ethods for Software Testing , =erry/ 2illiam E.

It covers the whole software lifecycle/ starting with testing the project plan and

estimates and ending with testing the effectiveness of the testing process. The &oo is

paced with checlists/ worsheets and :,step proced!res for each stage of testing.

2hen sho!ld testing &e stopped4

This can &e diffic!lt to determine. ?any modern software applications are so

complex/ and r!n in s!ch an interdependent environment/ that complete testing can

never &e done. 8ommon factors in deciding when to stop are>

- %eadlines 9release deadlines/ testing deadlines/ etc.;- Test cases completed with certain percentage passed- Test &!dget depleted- 8overage of code6f!nctionality6re#!irements reaches a specified point- "!g rate falls &elow a certain level- "eta or alpha testing period ends

2hen do yo! start developing yo!r a!tomation tests4

First/ the application has to &e man!ally tested. 5nce the man!al testing is over and

&aseline is esta&lished.

2hat are positive scenarios4

Testing to see whether the application is doing what it is s!pposed to do.

2hat are negative scenarios4

Testing to see whether the application is not doing what it is not s!ppose to do.


12/30

2hat is #!ality ass!rance4

The set of s!pport activities 9incl!ding facilitation/ training/ meas!rement and

analysis; needed to provide ade#!ate confidence that processes are esta&lished and

contin!o!sly improved in order to prod!ce prod!cts that meet specifications and fit

for !se.

2hat is the p!rpose of the testing4

Testing provides information whether or not a certain prod!ct meets the

re#!irements.

2hat is the difference &etween QA and testing4

Q!ality Ass!rance is that set of activities that are carried o!t to set standards and to

monitor and improve performance so that the care provided is as effective and as

safe as possi&le. Testing provides information whether or not a certain prod!ct

meets the re#!irements. It also provides information where the prod!ct fails to

meet the re#!irements.

2hat are &enefits of the test a!tomation4

1. Fast

$. *elia&le

'. *epeata&le

). =rogramma&le

+. 8omprehensive

. *e!sa&le

%escri&e some pro&lems that yo! had with a!tomation testing tools

5ne of the pro&lems with A!tomation tools is 5&ject recognition

8an test a!tomation improver test effectiveness4

es/ &eca!se of the advantages offered &y test a!tomation/ which incl!des

repeata&ility/ consistency/ porta&ility and extensive reporting feat!res.

2hat are the main !se of test a!tomation4

*egression Testing.

%oes a!tomation replace man!al testing4

:o/ it does not. There co!ld &e several scenarios that cannot &e a!tomated or simply

too complicated that man!al testing wo!ld &e easier and cost effective. F!rther

a!tomation tools have several constrains with regard the environment in which they

r!n and I%Es they s!pport.

7ow will yo! choose a tool for test a!tomation4

5*

7ow we decide which a!tomation tool we are going to !se for the regression testing4

"ased on ris analysis lie> personnel sills/ companies software reso!rces

"ased on 8ost analysis


13/30

8omparing the tools feat!res with test re#!irement.

S!pport for the applications I%E/ s!pport for the application

environment6platform.

2hat co!ld wrong with a!tomation testing4

There are several things. For ex. Script errors can ca!se a gen!ine &!g to go!ndetected or report a &!g in the application when the &!g does not act!ally exist.

7ow will yo! descri&e testing activities4

Testing planning/ scripting/ exec!tion/ defect reporting and tracing/ regression

testing.

2hat type of scripting techni#!es for test a!tomation do yo! now4

?od!lar tests and data driven test

2hat are good principles for test scripts4

1. =orta&le$. *epeata&le

'. *e!sa&le

). ?aintaina&le

2hat type of doc!ment do yo! need for QA/ Q8 and testing4

Following is the list of doc!ments re#!ired &y QA and Q8 teams

"!siness re#!irements

S*S

-se cases

Test plan

Test cases

2hat are the properties of a good re#!irement4

-nderstanda&le/ 8lear/ 8oncise/ Total 8overage of the application

2hat inds of testing have yo! done4

?an!al/ a!tomation/ regression/ integration/ system/ stress/ performance/ vol!me/

load/ white &ox/ !ser acceptance/ recovery.

7ave yo! ever written test cases or did yo! j!st exec!te those written &y others4

es/ I was involved in preparing and exec!ting test cases in all the project.

7ow do yo! determine what to test4

%epending !pon the -ser *e#!irement doc!ment.

7ow do yo! decide when yo! have Jtested eno!gh4@

-sing Exit 8riteria doc!ment we can decide that we have done eno!gh testing.


14/30

*ealising yo! won@t &e a&le to test everything,how do yo! decide what to test first4

5*

2hat if there isn3t eno!gh time for thoro!gh testing4

-se ris analysis to determine where testing sho!ld &e foc!sed. Since it3s rarely

possi&le to test every possi&le aspect of an application/ every possi&le com&ination of

events/ every dependency/ or everything that co!ld go wrong/ ris analysis isappropriate to most software development projects. This re#!ires j!dgment sills/

common sense/ and experience. 9If warranted/ formal methods are also availa&le.;

8onsiderations can incl!de>

2hich f!nctionality is most important to the project3s intended p!rpose4

2hich f!nctionality is most visi&le to the !ser4

2hich f!nctionality has the largest safety impact4

2hich f!nctionality has the largest financial impact on !sers4

2hich aspects of the application are most important to the c!stomer4

2hich aspects of the application can &e tested early in the development

cycle4

2hich parts of the code are most complex/ and th!s most s!&ject to errors4

2hich parts of the application were developed in r!sh or panic mode4

2hich aspects of similar6related previo!s projects ca!sed pro&lems4

2hich aspects of similar6related previo!s projects had large maintenance

expenses4

2hich parts of the re#!irements and design are !nclear or poorly tho!ght

o!t4

2hat do the developers thin are the highest,ris aspects of the application4

2hat inds of pro&lems wo!ld ca!se the worst p!&licity4

2hat inds of pro&lems wo!ld ca!se the most c!stomer service complaints4

2hat inds of tests co!ld easily cover m!ltiple f!nctionalities4

2hich tests will have the &est high,ris,coverage to time,re#!ired ratio4

2here do yo! get yo!r expected res!lts4

-ser re#!irement doc!ment

If a!tomating,what is yo!r process for determining what to a!tomate and in what

order4 5*

8an yo! a!tomate all the test scripts4 Explain4 5*

7ow do yo! plan test a!tomation4 5*

2hat criteria do yo! !se when determining when to a!tomate a test or leave itman!al4

1. Test that need to &e r!n for every &!ild of the application

$. Tests that !se m!ltiple data val!es for the same actions9 data driven tests;

'. Tests that re#!ire detailed information from application internals

). Stress6 load testing


15/30

If yo!@re given a program that will average st!dent grades/ what inds of inp!ts

wo!ld yo! !se4

:ame of st!dent/ S!&ject/ Score

2hat is the exact difference &etween Integration and System testing/ give me

examples with yo!r project4Integration testing> An orderly progression of testing in which software

components or hardware components/ or &oth are com&ined and tested !ntil the

entire system has &een integrated.

System testing> The =rocess of testing an integrated hardware and software system

to verify that the system meets its specified re#!irements.

7ow do yo! go a&o!t testing a project4

1. Analy(e !ser re#!irement doc!ments and other doc!ments lie software

specifications/ design doc!ment etc.

$. 2rite master test plan which descri&e the scope/ o&jective/ strategy/

ris6contingencies/ reso!rces'. 2rite system test plan and detailed test cases

). Exec!te test cases man!ally and compare act!al res!lts against expected

res!lts.

+. Identify mismatches/ report defect to the development team !sing defect

reporting tool.

. Trac defect/ perform regression test to verify that defect is fixed and did not

dist!r& other parts of the application.

0. 5nce all the defects are closed and application is sta&ili(ed/ a!tomate the test

scripts for regression and performance testing.

7ow do yo! go a&o!t testing a we& application4

2e chec for -ser interface/ F!nctionality/ Interface testing/ 8ompati&ility/

F!nctional testing &ased on re#!irements with no nowledge of

the internal program str!ct!re or data. Also nown as closed,&ox testing.

2hite "ox testing> Testing approaches that examine the program str!ct!re and

device test data from the program logic.

2hat is config!ration management4 Tools !sed4

8onfig!ration management> helps teams control their day,to,day management of

software development activities as software is created/ modified/ &!ilt and delivered.

8omprehensive software config!ration management incl!des version control/

worspace management/ &!ild management/ and process control to provide &etter

project control and predicta&ility

2hat are Individ!al test case and 2orflow test case4 2hy we do worflow

scenarios


16/30

An individ!al test is one that is for a single feat!res or re#!irement. 7owever/ it is

important that related se#!ences of feat!res &e tested as well/ as these correspond to

!nits of wor that !ser will typically perform. It will &e important for the system

tester to &ecome familiar with what !sers intend to do with the prod!ct and how

they intend to do it. S!ch testing can reveal errors that might not ordinarily &e

ca!ght otherwise. For example while each operations in a series might prod!ce thecorrect res!lts it is possi&le that intermediate res!lts get lost or corr!pted &etween

operations.

2hat are the testing tools are yo! familiar with4

Test%irector/ 2in*!nner/ typically involves reviews and meetings to eval!ate doc!ments/ plans/

code/ re#!irements/ and specifications. This can &e done with checlists/ iss!es lists/

walthro!ghs/ and inspection meetings.

Calidation> typically involves act!al testing and taes place after verifications are

completed. The term 3IC K C3 refers to Independent Cerification and Calidation

Is coding re#!ired in SQA ro&ot4

es/ to enhance the script for testing the &!siness logic/ and when we write the !ser

define the f!nctions.

2hat do yo! mean &y Lset !p the test environment and provide f!ll platform

s!pport4

2e need to provide the following for setting !p the environment

1; *e#!ired software

$; *e#!ired hardware

'; *e#!ired testing tools

); *e#!ired test data

After providing these we need to provide s!pport for any pro&lems that occ!r

d!ring the testing process.


17/30

2hat are the two ways to copy a file in windows4

1; -sing the copy men! item in the edit men!.

$; "y dragging the file where ever yo! want to copy it lie a floppy

If the f!nctionality of an application had an in&!ilt &!g &eca!se of which the test

script fails/ wo!ld yo! a!tomate the test4:o/ we do the a!tomation once the application is tested man!ally and it is sta&ili(ed.

A!tomation is for regression testing.

2hat is the &!g reporting tool !sed4

*ational 8learQ!est

Test%irectror

=C8S Tracer

%id !se SQA ?anager4

es. For creating test plan and defect reporting6tracing.

o! find a &!g and the developer says LIt@s not possi&leM what do ! do4

I@ll disc!ss with him !nder what conditions 9woring environment; the &!g was

prod!ced. I@ll provide him with more details and the snapshot of the &!g.

7ow do yo! help developer to trac the fa!lt s in the software4

"y providing him with details of the defects which incl!de the environment/ test

data/ steps followed etcN and helping him to reprod!ce the defect in his

environment.

2ere yo! a&le to meet deadlines4

A&sol!tely.

2hat is =olymorphism4 Dive example.

In o&ject,oriented programming/ polymorphism refers to a programming

lang!age3s a&ility to process o&jects differently depending on their data type or

class. ?ore specifically/ it is the a&ility to redefine methods for derived classes.

For example/ given a &ase class shape/ polymorphism ena&les the programmer to

define different circ!mference methods for any n!m&er of derived classes/ s!ch as

circles/ rectangles and triangles.

:o matter what shape an o&ject is/ applying the circ!mference method to it will

ret!rn the correct res!lts. =olymorphism is considered to &e a re#!irement of any

tr!e o&ject,oriented programming lang!age 955=


18/30

Test metrics contains follwoing details>

Total test

Test r!n

Test passed

Test failed

Tests deferred

Test passed the first time

2hat is the !se of ?etrics4

=rovide the acc!rate meas!rement of test coverage.

If yo! have shortage of time/ how wo!ld yo! prioriti(e yo! testing4

-se ris analysis to determine where testing sho!ld &e foc!sed. Since it3s rarely

possi&le to test every possi&le aspect of an application/ every possi&le com&ination of

events/ every dependency/ or everything that co!ld go wrong/ ris analysis is

appropriate to most software development projects. 8onsiderations can incl!de>

2hich f!nctionality is most important to the project3s intended p!rpose4

2hich f!nctionality is most visi&le to the !ser4

2hich f!nctionality has the largest safety impact4

2hich f!nctionality has the largest financial impact on !sers4

2hich aspects of the application are most important to the c!stomer4

2hich aspects of the application can &e tested early in the development

cycle4

2hich parts of the code are most complex/ and th!s most s!&ject to errors4

2hich parts of the application were developed in r!sh or panic mode4

2hich aspects of similar6related previo!s projects ca!sed pro&lems4

2hich aspects of similar6related previo!s projects had large maintenance

expenses4

2hich parts of the re#!irements and design are !nclear or poorly tho!ght

o!t4

2hat do the developers thin are the highest,ris aspects of the application4

2hat inds of pro&lems wo!ld ca!se the worst p!&licity4

2hat inds of pro&lems wo!ld ca!se the most c!stomer service complaints4

2hat inds of tests co!ld easily cover m!ltiple f!nctionalities4

2hich tests will have the &est high,ris,coverage to time,re#!ired ratio4

2hat is the impact of environment on the act!al res!lts of performance testing4

Environment plays an important role in the res!lts and effectiveness of test/

partic!larly in the area of performance testing. Some of the factors will &e !nder

o!r control/ while others will not &e. These may involve the %"?S/ the operating

system or the networ. Some of the items that we cannot control !nless yo! can

sec!re a stand,alone environment 9which will generally &e !nrealistic; are>

- 5ther traffic on the networ


19/30

- 5ther process r!nning on the server- 5ther process r!nning on the %"?S

2hat is stress testing/ performance testing/ Sec!rity testing/ *ecovery testing and

vol!metesting.

Stress testing> Testing the system if it can handle pea !sage period loads that res!ltfrom large n!m&er of sim!ltaneo!s !sers/ transactions or devices. ?onitoring

sho!ld &e performed for thro!ghp!t and system sta&ility.

=erformance Testing> Testing the system whether the system f!nctions are &eing

performed in an accepta&le timeframe !nder sim!ltaneo!s !ser load. Timings for

&oth read and !pdate transactions sho!ld &e gathered to determine whether. This

sho!ld &e done stand,alone and then in a m!lti,!ser environment to determine the

transaction thro!ghp!t.

Sec!rity Testing> Testing the system for its sec!rity from !na!thori(ed !se and

!na!thori(ed data access.

*ecovery Testing> Testing a system to see how it responds to errors and a&normal

conditions/ s!ch as system crash/ loss of device/ comm!nications/ or power.

Col!me Testing> Testing to the system to determine if it can correctly process large

vol!mes of data fed to the system. Systems can often respond !npredicta&ly when

large vol!me ca!ses files to overflow and need extensions.

2hat criteria yo! will follow to assign severity and d!e date to the ?*4

%efects 9?*; are assigned severity as follows>

8ritical> show stoppers 9the system is !n!sa

7igh> The system is very hard to !se and some cases are prone to convert to critical

iss!es if not taen care of.

?edi!m> The system f!nctionality has a major &!g &!t is not too critical &!t needs

to &e fixed in order for the A-T to go to prod!ction environment.

cosmetic 9D-I related;

2hat is !ser acceptance testing4

It is also called as "eta Testing. 5nce System Testing is done and the system seems

sta&le to the developers and testers/ system engineers !s!ally invite the end !sers of

the software to see if they lie the software. If the !sers lie the software the way it

is then software will &e delivered to the !ser. 5therwise necessary changes will &e

made to the software and software will pass thro!gh all phases of testing again.

2hat is man!al testing and what is a!tomated testing4

?an!al testing involves testing of software application &y man!ally performing the

actions on the A-T &ased on test plans.


20/30

A!tomated testing involves testing of a software application &y performing the

actions on the A-T &y !sing a!tomated testing tool 9s!ch as 2in*!nner/

- Integration exit criteria have &een s!ccessf!lly met.- All installation doc!ments are completed.- All shippa&le software has &een s!ccessf!lly &!ilt- Syate/ test plan is &aselined &y completing the walthro!gh of the test plan.

- Test environment sho!ld &e set!p.- All severity 1 ?*@s of integration test phase sho!ld &e closed.

Exit 8riteria>

- All the test cases in the test plan sho!ld &e exec!ted.

- All ?*@s6defects are either closed or deferred.- *egression testing cycle sho!ld &e exec!ted after closing the ?*@s.- All doc!ments are reviewed/ finili(ed and signed,off.

If there are no re#!irements/ how will yo! write yo!r test plan4

If there are no re#!irements we try to gather as m!ch details as possi&le from>

"!siness Analysts

%evelopers 9If accessi

=revio!s Cersion doc!mentation 9if any;

Stae holders 9If accessi

=rototypes.

2hat is smoe testing4

The smoe test sho!ld exercise the entire system from end to end. It does not have to

&e exha!stive/ &!t it sho!ld &e capa&le of exposing major pro&lems. The smoe test

sho!ld &e thoro!gh eno!gh that if the &!ild passes/ yo! can ass!me that it is sta&le

eno!gh to &e tested more thoro!ghly.

The daily &!ild has little val!e witho!t the smoe test. The smoe test is the sentry

that g!ards against deteriorating prod!ct #!ality and creeping integration

pro&lems. 2itho!t it/ the daily &!ild &ecomes j!st a time,wasting exercise in

ens!ring that yo! have a clean compile every day.

The smoe test m!st evolve as the system evolves. At first/ the smoe test will

pro&a&ly test something simple/ s!ch as whether the system can say/ H7ello/

2orld.H As the system develops/ the smoe test will &ecome more thoro!gh. The

first test might tae a matter of seconds to r!nB as the system grows/ the smoe test

can grow to 'O min!tes/ an ho!r/ or more.


21/30

2hat is soa testing4

The software system will &e r!n for a total of 1) ho!rs contin!o!sly. If the system is

a control system/ it will &e !sed to contin!o!sly move each of the instr!ment

mechanisms d!ring this time. Any other system will &e expected to perform its

intended f!nction contin!o!sly d!ring this period. The software system m!st not

fail d!ring this period.

2hat is a pre,condition data4

%ata re#!ired to set!p in the system &efore the test exec!tion.

2hat are the different doc!ments in QA4

*e#!irements %oc!ment/ Test =lan/ Test cases/ Test ?etrics/ Tas %istri&!tion

%iagrams 9 =erformance;/ Transaction ?ix/ -ser =rofiles/ Test 66www.software#atest.com6

http>66s#p.as#.org6

Is defect resol!tion a technical sill or interpersonal sill from QA view point4

It is a com&ination of &oth / &eca!se it deals with the interaction with developer

either directly or indirectly which needs interpersonal sills and is also &ased on the

sills of the QA personnel to provide a detailed proof to the developer lie snap

shots and system reso!rce !tili(ation and some s!ggestions which are little &it

technical.

2hat is End to End &!siness logic testing4

Testing the integration of all the mod!les of the A-T.

2hat is an e#!ivalence class4

A portion of a component3s inp!t or o!tp!t domains for which the component3s

&ehavio!r is ass!med to &e the same from the component3s specification

2hat is the tas &ar and where does it reside4

The tas &ar shows a tas &!tton for each open application. At a glance/ it shows

yo! which applications are r!nningB yo! can switch applications &y clicing

different tas &!ttons. In most cases the tas &ar is located at the very &ottom of

yo!r destop or comp!ter screen. 7owever the tas &ar can &e moved to the sides

or top.

7ow do yo! analy(e yo!r test res!lts4 what metrics do yo! try to provide4

5*

7ow do yo! view test res!lts4
http://www.softwareqatest.com/http://www.softwareqatest.com/


22/30

Test log is created for analy(ing the test res!lts.This is a chronological record of the

Test exec!tions and events that happened d!ring testing. It incl!des the following

sections>

%escription> 2hat@s &eing tested/ incl!ding Cersion I%/ where testing is &eing done/

what hardware and all other config!ration information.Activity and Event Entries> 2hat happened incl!ding Exec!tion %escription> The

proced!re !sed.

=roced!re *es!lt> 2hat happened. 2hat did yo! see and where did yo! store the

o!tp!t4

Environment Information> Any changes 9hardware s!&stit!tion; made specifically

for this test.

-nexpected Events> 2hat happened &efore and after pro&lem6&!g occ!rred.

Incident6"!g *eport Identifiers> =ro&lem *eport n!m&er

If yo! come on&oard/ give me a general idea of what yo!r first overall tass will &e

as far as as starting a #!ality effort4Try to learn a&o!t the application/ Environment and =rototypes to have the &etter

!nderstanding of application and existing testing efforts

7ow do yo! differentiate the roles of Q!ality Ass!rance ?anager and =roject

?anager4

Q!ality ass!rance manager responsi&ilites incl!des seting !p the standards/ the

methodology and the strategies for testing the application and providing g!idelines

to the QA team. =roject ?anager is reponsi&le to testing and development activities.

2hat do yo! lie a&o!t QA4

QA is the field where in one will &e woring to m!ltiple environments and can learn

more.

2ho in the company is responsi&le for Q!ality4

"oth development and #!ality ass!rance departments are responsi&le for the final

prod!ct #!ality.

Sho!ld we test every possi&le com&ination6scenario for a program4

Ideally/ yes we sho!ld test every possi&le scenario/ &!t this may not always &e

possi&le. It depends on many factors vi(./ deadlines/ &!dget/ complexity of software

and so on. In s!ch cases/ we have to prioriti(e and thoro!ghly test the critical areas

of the application.

2hat is client,server architect!re4

8lient,server architect!re/ a client is defined as a re#!ester of services and a server

is defined as the provider of services. 8omm!nication taes place in the form a

re#!est message from the client to the server asing for some wor to &e done. Then

the server does the wor and sends &ac the reply.


23/30

7ow Intranet is different from client,server4

Internet applications are essentially client6server applications , with we& servers and

3&rowser3

2hat is three,tier and m!lti,tier architect!re4

A design which separate 91; client/ 9$; application/ and 9'; data each into their ownseparate areas which allows for more scala&le/ ro&!st sol!tions

A three,tier system is one that has presentation components/ &!siness logic and data

access physically r!nning on different platforms. 2e& applications are perfect for

three,tier architect!re/ as the presentation layer is necessarily separate/ and the

&!siness and data components can &e divided !p m!ch lie a client,server

application

2hat is Internet4

The Internet/ sometimes called simply Hthe :et/H is a worldwide system of comp!ter

networs , a networ of networs in which !sers at any one comp!ter can/ if theyhave permission/ get information from any other comp!ter. =hysically/ the Internet

!ses a portion of the total reso!rces of the c!rrently existing p!&lic

telecomm!nication networs. Technically/ what disting!ishes the Internet is its !se

of a set of protocols called T8=6I= 9for Transmission 8ontrol =rotocol6Internet

=rotocol;. Two recent adaptations of Internet technology/ the intranet and the

extranet/ also mae !se of the T8=6I= protocol.

2hat is Intranet4

An intranet is a private networ that is contained within an enterprise. It may

consist of many interlined local area networs and also !se leased lines in the 2ide

Area :etwor. The main p!rpose of an intranet is to share company information

and comp!ting reso!rces among employees. An intranet can also &e !sed to

facilitate woring in gro!ps and for teleconferences.

2hat is Extranet4

An extranet is a private networ that !ses the Internet protocol and the p!&lic

telecomm!nication system to sec!rely share part of a &!siness3s information or

operations with s!ppliers/ vendors/ partners/ c!stomers/ or other &!sinesses. An

extranet can &e viewed as part of a company3s intranet that is extended to !sers

o!tside the company. It has also &een descri&ed as a Hstate of mindH in which the

Internet is perceived as a way to do &!siness with other companies as well as to sell

prod!cts to c!stomers.

2hat is a &yte code file4

?achine,independent code generated &y the Pava9T?; compiler and exec!ted &y

the Pava interpreter

2hat is an applet4


24/30

A program written in the Pava9T?; programming lang!age to r!n within a we&

&rowser compati&le with the Pava platform/ s!ch as 7ot Pava9T?; or :etscape

:avigator9T?;.

7ow applet is different from application4

An applet is an application program that !ses the client3s we& &rowser to provide a!ser interface while an application is a comp!ter program with a !ser interface.

2hat is Pava Cirt!al ?achine4

Pava9T?; Cirt!al ?achine. The part of the Pava *!ntime Environment

responsi&le for interpreting &ytecodes

2hat is IS5,ROOO4

A set of international standards for &oth #!ality management and #!ality ass!rance

that has &een adopted &y over RO co!ntries worldwide. The IS5 ROOO standards

apply to all types of organi(ations/ large and small/ and in many ind!stries. The IS5

ROOO series classifies prod!cts into generic prod!ct categories> hardware/ software/processed materials/ and services.


25/30

2hat is Q?54

The Q?5 is a set of processes and g!idelines that software systems projects and

prod!cts that are &!ilt !nder a contract 9with a c!stomer ; m!st follow to comply

with IS5,ROOO standards. IS5,ROOO states that the g!idelines for software

development m!st &e doc!mented.

2hat is 5&ject 5riented model4

In a 5&ject 5riented model each class is a separate mod!le and has a position in a

class hierarchy. ?ethods or code in one class can &e passed down the hierarchy to a

s!&class or inherited from a s!per class. This is called inheritance.

2hat is =roced!ral model4

A term !sed in contrast to declarative lang!ageto descri&e a lang!age where the

programmer specifies an explicit se#!ence of steps to follow to prod!ce a res!lt.

8ommon proced!ral lang!ages incl!de "asic and 8.

2hat is an 5&ject4

An o&ject is a software &!ndle of related varia&les and methods. Software o&jects

are often !sed to model real,world o&jects yo! find in everyday life

2hat is class4

A class is a &l!eprint or prototype that defines the varia&les and the methods

common to all o&jects of a certain ind.

2hat is encaps!lation4 Dive one example.

Encaps!lation is the a&ility to provide a well,defined interface to a set of f!nctions

in a way which hides their internal worings. In o&ject,oriented programming/ the

techni#!e of eeping together data str!ct!res and the methods 9proced!res; which

act on them.

2hat is inheritance4 Dive example.

In o&ject,oriented programming/ the a&ility to derive new classes from existing

classes. A derived class 9or Hs!&classH; inherits the instance varia&les and methods

of the H&ase classH 9or Hs!perclassH;/ and may add new instance varia&les and

methods. :ew methods may &e defined with the same names as those in the &ase

class/ in which case they override the original one.

2hat is the difference a&o!t we&,testing and client server testing4

2e& applications are essentially client6server applications , with we& servers and

3&rowser3 clients. 8onsideration sho!ld &e given to the interactions &etween html

pages/ T8=6I= comm!nications/ Internet connections/ firewalls/ applications that

r!n in we& pages 9s!ch as applets/ javascript/ pl!g,in applications;/ and applications

that r!n on the server side 9s!ch as cgi scripts/ data&ase interfaces/ logging

applications/ dynamic page generators/ asp/ etc.;. Additionally/ there are a wide

variety of servers and &rowsers/ vario!s versions of each/ small &!t sometimes


26/30

significant differences &etween them/ variations in connection speeds/ rapidly

changing technologies/ and m!ltiple standards and protocols. The end res!lt is that

testing for we& sites can &ecome a major ongoing effort.

Is a LFast data&ase retrieval rateM a testa&le re#!irement4

This is not a testa&le re#!irement. JFast@ is a s!&jective term. It co!ld meandifferent things depending on a person@s perception. For a re#!irement to &e

testa&le/ it sho!ld &e #!antified and repeata&le/ so that the act!al val!e co!ld &e

meas!red against the expected val!e.

2hat different type of test cases yo! wrote in the test plan4

Test cases for interface/ f!nctionality/ sec!rity/ load and performance testing.

2hat development model sho!ld programmers and the test gro!p !se4

A %evelopment ?odel/ which helps adopt a str!ct!red approach in assessment/

design/ integration and implementation of a project and in extending relevant

training and s!pport. Each of these stages is necessarily accompanied with clientinp!ts/ checpoints and reviews to ens!re s!ccessf!l systems implementation.

"asically there are many types of development models to s!pport the development

of high,#!ality software prod!cts. The two most widely !sed models are 2aterfall

and Spiral development model.

2aterfall development model enco!rages the development team to specify the

&!siness f!nctionality of the software prior to developing a system.

Spiral development model com&ines the waterfall development model and the

prototype approach/ which is a series of partial implementations of the prod!ct.

A typical project may incl!de some or all of the following phases>

re#!irements analysis

f!nctional specifications

architect!ral design

detailed design

coding

!nit testing

integration testing

deployment and

maintenance.

2hat are the ey challenges of load testing4

The ey challenges to load testing is handling vario!s components from vario!s

vendors.

7ave yo! done explanatory or specification,driven testing4

es/ specification,driven testing means checing the prod!ct@s confirmance with

every statement in every spec/ re#!irements doc!ement/ etc.


27/30


28/30

2hat is the role of QA in development project4

%eploy and enforce standards

8ontin!ally improve standards/ QA process &ased on previo!s experiences

=romote effective means for reporting and comm!nication.

7ow do yo! promote the concept of phase containment and defect prevention4=hase 8ontainment refers to detecting and correcting defects in the same phase in

which they@re created.

The p!rpose of %efect =revention is to identify the ca!se of defects and prevent

them from rec!rring.

2hat is 2althro!gh42althro!gh > A 3walthro!gh3 is an informal meeting for eval!ation or informational

p!rposes. An inspection is more formali(ed than a 3walthro!gh3/ typically with ',

people incl!ding a moderator/ reader/ and a recorder to tae notes. The s!&ject of

the inspection is typically a doc!ment s!ch as a re#!irements spec or a test plan/

and the p!rpose is to find pro&lems and see what3s missing/ not to fix anything.

Attendees sho!ld prepare for this type of meeting &y reading thr! the doc!mentB

most pro&lems will &e fo!nd d!ring this preparation. The res!lt of the inspection

meeting sho!ld &e a written report. Thoro!gh preparation for inspections is

diffic!lt/ painstaing wor/ &!t is one of the most cost effective methods of ens!ring

#!ality.

5*

Inspectionis a formal eval!ation techni#!e in which artifacts are examined in detail

&y a person or gro!p other than the a!thor to detect errors/ violations of

development standards/ and other pro&lems.

2hat is Software *eview4

Software *eview> An eval!ation techni#!e that involves the &ringing together a

gro!p of technical personnel to analy(e a software artifact in order to improve its

#!ality.

*eview types>

Informal> adhoc process/ no planning/ no str!ct!re


29/30

Formal 9Formal Technical *eview;> Follow a str!ct!red process =rod!ce

written report on artifact stat!s 8ollect and analy(e review metrics

2hat if the application has f!nctionality that wasn3t in the re#!irements4

It may tae serio!s effort to determine if an application has significant !nexpectedor hidden f!nctionality/ and it wo!ld indicate deeper pro&lems in the software

development process. If the f!nctionality isn3t necessary to the p!rpose of the

application/ it sho!ld &e removed/ as it may have !nnown impacts or dependencies

that were not taen into acco!nt &y the designer or the c!stomer. If not removed/

design information will &e needed to determine added testing needs or regression

testing needs. ?anagement sho!ld &e made aware of any significant added riss as

a res!lt of the !nexpected f!nctionality. If the f!nctionality only effects areas s!ch

as minor improvements in the !ser interface/ for example/ it may not &e a significant

ris.

Sec!rity Testing1. What is Security Testing?

2. What is Secure Socket Layer (SSL)? What is does?

3. What is Firewall?

. What is !ro"y Ser#er?

$. What is %igital &erti'icate and how it is linked to &erti'icate

uthority (&)?

. What is !*+?

,. What is the di''erence etween TT! and TT!S?


30/30

CASE Tool

CASE (computer-aided software engineering) is the use of a computer-assisted method toorganize and control the development of software, especially on large, comple pro!ectsinvolving many software components and people" #sing CASE allows designers, codewriters, testers, planners, and managers to share a common view of where a pro!ect stands

at each stage of development" CASE helps ensure a disciplined, chec$-pointed process" ACASE tool may portray progress (or lac$ of it) graphically" %t may also serve as a repositoryfor or &e lin$ed to document and program li&raries containing the pro!ect's &usiness plans,design reuirements, design specifications, detailed code specifications, the code units,test cases and results, and mar$eting and service plans"

CASE originated in the *+s when computer companies were &eginning to &orrow ideasfrom the hardware manufacturing process and apply them to software development (whichgenerally has &een viewed as an insufficiently disciplined process)" Some CASE toolssupported the concepts of structured programming and similar organized developmentmethods" ore recently, CASE tools have had to encompass or accommodate visualprogramming tools and object-oriented programming" %n corporations, a CASE tool may &epart of a spectrum of processes designed to ensure uality in what is developed" (any

companies have their processes audited and certified as &eing in conformance with the %S.* standard")

Some of the &enefits of CASE and similar approaches are that, &y ma$ing the customer partof the process (through mar$et analysis and focus groups, for eample), a product is moreli$ely to meet real-world reuirements" /ecause the development process emphasizestesting and redesign, the cost of servicing a product over its lifetime can &e reducedconsidera&ly" An organized approach to development encourages code and design reuse,reducing costs and improving uality" 0inally, uality products tend to improve acorporation's image, providing a competitive advantage in the mar$etplace"
http://searchwin2000.techtarget.com/sDefinition/0,,sid1_gci212681,00.htmlhttp://searchwin2000.techtarget.com/sDefinition/0,,sid1_gci212681,00.html

Date post:	04-Jun-2018
Category:	Documents
Upload:	naren3456
View:	217 times
Download:	0 times

FAQ_Testingdocument1

Documents