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 after developers 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 wor1s with the development doc!ment staff to modify and enhance the application and the test team wor1s 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.

At what stage of the S%<8 does testing &egin in yo!r opinion4 QA process starts from the second phase of the Software %evelopment <ife 8ycle i.e. %efine the System. Act!al =rod!ct testing will &e done on Test the system phase 9=hase,+;. %!ring this phase test team will verify the act!al res!lts against expected res!lts. Explain the pre testing phase/ acceptance testing and testing phase. =re testing =hase> 1. *eview the re#!irements doc!ment for the testa&ility> 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 testing strategy. ). Setting !p ?* Tool> The ?* tool m!st &e set as soon as yo! 1now 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 networ1. This tas1 is performed &y the technical s!pport team. First time it ta1es 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 wal1thro!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. A. 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/ chec1 it has completed integration test and m!st meet the integration test exit criteria.

$. 8hec1 integration exit criteria and prod!ct test entrance criteria in the master test plan or test strategy doc!ments. '. 8hec1 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 wor1 and &!dget4 All software prod!cts contain defects6&!gs/ despite the &est efforts of their development 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 thin1 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

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 ris1 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 trac1 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 trac1ing 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!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 1nown as %efect *eport/ a re#!est to modify the program 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. After the pro&lem is resolved/ fixes sho!ld &e re,tested/ and determinations made regarding re#!irements for regression testing to chec1 that fixes didn3t create pro&lems elsewhere. If a pro&lem,trac1ing system is in place/ it sho!ld encaps!late these processes. A variety of commercial pro&lem,trac1ing6management software tools are availa&le. The following are items to consider in the trac1ing 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

%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#!ires detailed 1nowledge 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 networ1/ etc. This type of testing is especially relevant to client6server and distri&!ted systems. 2hat is "lac1 &ox testing4 "lac1 "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 1nowledge yo! re#!ire to do white &ox/ integration and &lac1 &ox testing4

For white &ox testing yo! need to !nderstand the internals of the mod!le li1e data str!ct!res and algorithms and have access to the so!rce code and for &lac1 &ox testing only !nderstanding6f!nctionality of the application. 2hat is *egression testing4 *egression testing> *e,testing after fixes or modifications of the software or its environment. 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 testing4 Cario!s a!tomation testing tools can &e !sed to perform regression testing li1e 2in*!nner/ *ational *o&ot and Sil1 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 networ1/ 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 &ac1 at a later time. The capt!re and play&ac1 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 networ1 load !nder different n!m&er of sim!lated !sers. 2hat are the roles of glass,&ox and &lac1,&ox testing tools4

Dlass,&ox testing also called as white,&ox testing refers to testing/ with detailed 1nowledge 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 li1ely than the whole application. "lac1,"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 <eader QA lead QA Analyst Tester 2hich ?* tool yo! !sed to write ?*4 Test %irector *ational 8learQ!est. =C8S Trac1er 2hat are the different a!tomation tools yo! 1now4 A!tomation tools provided &y ?erc!ry Interactive , 2in*!nner/ <oad*!nnerB *ational *ational *o&otB Seg!e, Sil1Test. 2hat is the role of a &!g trac1ing system4 "!g trac1ing system capt!res/ manages and comm!nicates changes/ iss!es and tas1s/ providing &asic process control to ens!re coordination and comm!nication within and across development and content teams at every step. 2hat is 5%"84 5pen %ata&ase 8onnectivity 95%"8; is an open standard application,programming interface 9A=I; for accessing a data&ase. 5%"8 is &ased on Str!ct!red Q!ery <ang!age 9SQ<; 8all,<evel Interface. It allows programs to !se SQ< re#!ests that will access data&ases witho!t having to 1now the proprietary interfaces to the data&ases. 5%"8 handles the SQ< re#!est and converts it into a re#!est the individ!al data&ase system !nderstands. %id yo! ever have pro&lems wor1ing with developers4 :5. I had a good rapport with the developers. %escri&e yo!r experience with code analy(ers4 8ode analy(ers generally chec1 for &ad syntax/ logic/ and other lang!age,specific programming errors at the so!rce level. This level of testing is often referred to as !nit testing and server component testing. I !sed code analy(ers as part of white &ox testing.

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 wor1. 2hat =rocess6?ethodologies are yo! familiar with4 2aterfall methodology Spiral methodology E5r tal1 a&o!t 8!stomi(ed methodology of the specific clientF 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/ tal1ing 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 ma1e the prod!ct s!ccessf!l. 2hat do yo! li1e 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 ma1es it easy for people to !nderstand how a program wor1sB when reading consistent codeB one s!&conscio!sly forms a n!m&er of ass!mptions and expectations a&o!t how the code wor1s/ so it is easier and safer to ma1e 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

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 "ec1/ %r Drace 7opper/ and %ennis *itchie4 Gent "ec1 is the a!thor of Extreme =rogramming Explained and The Smalltal1 "est =ractice =atterns. %r. Drace ?!rray 7opper was a remar1a&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 li1e waterfall/ spiral instead of !sing ad,hoc proced!res. 2hat is -?< and how it is !sed for testing4 The -nified ?odeling <ang!age 9-?<; is the ind!stry,standard lang!age for specifying/ vis!ali(ing/ constr!cting/ and doc!menting the artifacts of software systems. It simplifies the complex process of software design/ ma1ing a H&l!eprintH for constr!ction. -?< state charts provide a solid &asis for test generation in a form that can &e easily manip!lated. This techni#!e incl!des coverage criteria that ena&le highly effective tests to &e developed. A tool has &een developed that !ses -?< state charts prod!ced &y *ational Software 8orporation3s *ational *ose tool to generate test data.

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 1ey 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 91nown 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 &oo14 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 &oo1 is pac1ed with chec1lists/ wor1sheets 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.

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 Ies/ &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 ris1 analysis li1e> personnel s1ills/ companies software reso!rces "ased on 8ost analysis

8omparing the tools feat!res with test re#!irement. S!pport for the applications I%E/ s!pport environment6platform.

for

the

application

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 trac1ing/ regression testing. 2hat type of scripting techni#!es for test a!tomation do yo! 1now4 ?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 1inds 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 Ies/ 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.

*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 ris1 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/ ris1 analysis is appropriate to most software development projects. This re#!ires j!dgment s1ills/ 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 thin1 are the highest,ris1 aspects of the application4 2hat 1inds of pro&lems wo!ld ca!se the worst p!&licity4 2hat 1inds of pro&lems wo!ld ca!se the most c!stomer service complaints4 2hat 1inds of tests co!ld easily cover m!ltiple f!nctionalities4 2hich tests will have the &est high,ris1,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 it man!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

If yo!@re given a program that will average st!dent grades/ what 1inds 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 project4 Integration 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 li1e software specifications/ design doc!ment etc. $. 2rite master test plan which descri&e the scope/ o&jective/ strategy/ ris16contingencies/ 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. .. Trac1 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 chec1 for -ser interface/ F!nctionality/ Interface testing/ 8ompati&ility/ <oad6Stress/ and Sec!rity. %ifference &etween "lac1 and 2hite &ox testing4 "lac1 &ox testing> F!nctional testing &ased on re#!irements with no 1nowledge of the internal program str!ct!re or data. Also 1nown 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/ wor1space management/ &!ild management/ and process control to provide &etter project control and predicta&ility 2hat are Individ!al test case and 2or1flow test case4 2hy we do wor1flow scenarios

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 wor1 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 the correct 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/ <oad*!nner/ *ational *e#!isit=ro/ Test?anager/ *ational *o&ot/ *ational 8learQ!est and Sil1Test. *ational

7ow did yo! !se a!tomating testing tools in yo!r jo&4 A!tomating testing tools are !sed for preparing and managing regression test scripts and load and perofromenance tests. 2hat is data,driven a!tomation4 If yo! want to perform the same operations with differnet set of data/ we can create data driven test with loop. In each iteration test is driven &y differnet set of data. In order for a!tomation to !se data to drive the test/ we m!st s!&sit!te the fixed val!es in the test with varia&les. %escri&e me the difference &etween validation and verification4 Cerification> typically involves reviews and meetings to eval!ate doc!ments/ plans/ code/ re#!irements/ and specifications. This can &e done with chec1lists/ iss!es lists/ wal1thro!ghs/ and inspection meetings. Calidation> typically involves act!al testing and ta1es place after verifications are completed. The term 3IC K C3 refers to Independent Cerification and Calidation Is coding re#!ired in SQA ro&ot4 Ies/ 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.

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 li1e 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 Trac1er %id !se SQA ?anager4 Ies. For creating test plan and defect reporting6trac1ing. Io! find a &!g and the developer says LIt@s not possi&leM what do ! do4 I@ll disc!ss with him !nder what conditions 9wor1ing 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 trac1 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=<;. 2hat are the different types of ?*s4 ?* for s!ggestions/ ?* for defect reports/ ?* for doc!mentations changes 2hat is test ?etrics4

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 ris1 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/ ris1 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 thin1 are the highest,ris1 aspects of the application4 2hat 1inds of pro&lems wo!ld ca!se the worst p!&licity4 2hat 1inds of pro&lems wo!ld ca!se the most c!stomer service complaints4 2hat 1inds of tests co!ld easily cover m!ltiple f!nctionalities4 2hich tests will have the &est high,ris1,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 networ1. 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 networ1

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!me testing. Stress testing> Testing the system if it can handle pea1 !sage period loads that res!lt from 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&le; 7igh> The system is very hard to !se and some cases are prone to convert to critical iss!es if not ta1en 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. <ow> 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 li1e the software. If the !sers li1e 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.

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/ <oad*!nner; &ased on test plans 2hat are the entrance and exit criteria in the system test4 Entrance and exit criteria of each testing phase is written in the master test plan. Enterence 8riteria> - 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 wal1thro!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&le; =revio!s Cersion doc!mentation 9if any; Sta1e holders 9If accessi&le; =rototypes. 2hat is smo1e testing4 The smo1e 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 smo1e 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 smo1e test. The smo1e 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 smo1e test m!st evolve as the system evolves. At first/ the smo1e test will pro&a&ly test something simple/ s!ch as whether the system can say/ H7ello/ 2orld.H As the system develops/ the smo1e test will &ecome more thoro!gh. The first test might ta1e a matter of seconds to r!nB as the system grows/ the smo1e test can grow to 'O min!tes/ an ho!r/ or more.

2hat is soa1 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/ Tas1 %istri&!tion %iagrams 9 =erformance;/ Transaction ?ix/ -ser =rofiles/ Test <og/ Test Incident *eport/ Test S!mmary *eport 7ow do yo! rate yo!rself in software testing excellent 2hat are the &est we& sites that yo! fre#!ently visit to !pgrade yo!r QA s1ills4 http>66www.software#atest.com6 http>66s#p.as#.org6 Is defect resol!tion a technical s1ill or interpersonal s1ill 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 s1ills and is also &ased on the s1ills of the QA personnel to provide a detailed proof to the developer li1e 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 tas1 &ar and where does it reside4 The tas1 &ar shows a tas1 &!tton for each open application. At a glance/ it shows yo! which applications are r!nningB yo! can switch applications &y clic1ing different tas1 &!ttons. In most cases the tas1 &ar is located at the very &ottom of yo!r des1top or comp!ter screen. 7owever the tas1 &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

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 tas1s will &e as far as as starting a #!ality effort4 Try 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! li1e a&o!t QA4 QA is the field where in one will &e wor1ing 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 ta1es place in the form a re#!est message from the client to the server as1ing for some wor1 to &e done. Then the server does the wor1 and sends &ac1 the reply.

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 own separate 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 li1e a client,server application 2hat is Internet4 The Internet/ sometimes called simply Hthe :et/H is a worldwide system of comp!ter networ1s , a networ1 of networ1s in which !sers at any one comp!ter can/ if they have 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 networ1s. 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 ma1e !se of the T8=6I= protocol. 2hat is Intranet4 An intranet is a private networ1 that is contained within an enterprise. It may consist of many interlin1ed local area networ1s and also !se leased lines in the 2ide Area :etwor1. 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 wor1ing in gro!ps and for teleconferences. 2hat is Extranet4 An extranet is a private networ1 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

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 ?achineQ. 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.

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!age to 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 1ind. 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 wor1ings. In o&ject,oriented programming/ the techni#!e of 1eeping 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

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 mean different 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 client inp!ts/ chec1points 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 1ey challenges of load testing4 The 1ey challenges to load testing is handling vario!s components from vario!s vendors. 7ave yo! done explanatory or specification,driven testing4 Ies/ specification,driven testing means chec1ing the prod!ct@s confirmance with every statement in every spec/ re#!irements doc!ement/ etc.

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 2al1thro!gh4
2al1thro!gh > A 3wal1thro!gh3 is an informal meeting for eval!ation or informational p!rposes. <ittle or no preparation is !s!ally re#!ired.

5* A process in which a developer leads one or more mem&ers of the development team thro!gh a segment of an artifact that he or she has written while the other mem&ers as1 #!estions and ma1e comments a&o!t techni#!e/ style/ possi&le error/ violation of development standards/ and other pro&lems. 2hat is inspection4 Inspection> An inspection is more formali(ed than a 3wal1thro!gh3/ typically with ', A people incl!ding a moderator/ reader/ and a recorder to ta1e 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/ painsta1ing wor1/ &!t is one of the most cost effective methods of ens!ring #!ality. 5* Inspection is 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

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 ta1e serio!s effort to determine if an application has significant !nexpected or 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 !n1nown impacts or dependencies that were not ta1en 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 ris1s 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 ris1. Sec!rity Testing

1. 2. 3. . $.

What is Security Testing? What is Secure Socket Layer (SSL)? What is does? 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?

CASE Tool
CASE (computer-aided software engineering) is the use of a computer-assisted method to organize and control the development of software, especially on large, comple pro!ects involving many software components and people" #sing CASE allows designers, code writers, 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" A CASE tool may portray progress (or lac$ of it) graphically" %t may also serve as a repository for or &e lin$ed to document and program li&raries containing the pro!ect's &usiness plans, design re(uirements, 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 ideas from the hardware manufacturing process and apply them to software development (which generally has &een viewed as an insufficiently disciplined process)" Some CASE tools supported the concepts of structured programming and similar organized development methods" -ore recently, CASE tools have had to encompass or accommodate visual programming tools and object-oriented programming" %n corporations, a CASE tool may &e part 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 part of the process (through mar$et analysis and focus groups, for e ample), a product is more li$ely to meet real-world re(uirements" /ecause the development process emphasizes testing and redesign, the cost of servicing a product over its lifetime can &e reduced considera&ly" An organized approach to development encourages code and design reuse, reducing costs and improving (uality" 0inally, (uality products tend to improve a corporation's image, providing a competitive advantage in the mar$etplace"