You are on page 1of 95

Software

Testing
Index

World

Brings you the complete knowledge

Complete Testing Notes - Manual

1. 2. ". ). *. +. -. /. 9. 11. 11. 12. 1". 1). 1*. 1+. 1-. 1/. 15. 21. 21. 22.

Introduction rinciple o! Testing #o!tware $e%elopment &i!e Cycle '#$&C( #o!tware $e%elopment &i!ecycle Models #ome o! the #o!tware Testing Terms and $e!initions ,eri!ication and %alidation ro.ect Management 0uality Management Risk Management Con!iguration Management Types o! #o!tware Testing Testing le%els Types o! Testing Techni2ues Testing &i!e Cycle $e!ect Tracking Test 3eports #o!tware Metric 4ther Testing Terms Test #tandards 6e7 Testing Testing Terms Technical 0uestions

#o!tware Testing

Introduction
Software testing is a critical element of software quality assurance and represents the ultimate process to ensure the correctness of the product. The quality product always enhances the customer confidence in using the product thereby increases the business economics. In other words, a good quality product means ero defects, which is deri!ed from a better quality process in testing. Software is an integrated set of "rogram codes, designed logically to implement a particular function or to automate a particular process. To de!elop a software product or pro#ect, user needs and constraints must be determined and e$plicitly stated. The de!elopment process is broadly classified into two. %. "roduct de!elopment &. "ro#ect de!elopment "roduct de!elopment is done assuming a wide range of customers and their needs. This type of de!elopment in!ol!es customers from all domains and collecting requirements from many different en!ironments. "ro#ect 'e!elopment is done by focusing a particular customer(s need, gathering data from his en!ironment and bringing out a !alid set of information that will help as a pillar to de!elopment process.

Testing is a necessary stage in the software life cycle) it gi!es the programmer and user some sense of correctness, though ne!er *proof of correctness. +ith effecti!e testing techniques, software is more easily debugged, less likely to *break,* more *correct*, and, in summary, better.

Most de!elopment processes in the IT industry always seem to follow a tight schedule. ,ften, these schedules ad!ersely affect the testing process, resulting in step motherly treatment meted out to the testing process. -s a result, defects accumulate in the application and are o!erlooked so as to meet deadlines. The de!elopers con!ince themsel!es that the o!erlooked errors can be rectified in subsequent releases.

The definition of testing is not well understood. "eople use a totally incorrect definition of the word testing, and that this is the primary cause for poor program testing. Testing the product means adding !alue to it by raising the quality or reliability of the product. Raising the reliability of the product means finding and remo!ing errors. .ence one should not test a product to show that it works/ rather, one should start with the assumption that the program contains errors and then test the program to find as many of the errors as possible.

$e!initions o! Testing8 0Testing is the process of e$ecuting a program with the intent of finding errors 1 ,r 0Testing is the process of e!aluating a system by manual or automatic means and !erify that it satisfies specified requirements1 ,r *... the process of e$ercising or e!aluating a system or system component by manual or automated means to !erify that it satisfies specified requirements or to identify differences 2 between e$pected and actual results...*

6hy so!tware Testing9


Software testing helps to deli!er quality software products that satisfy user3s requirements, needs and e$pectations. If done poorly, 4 defects are found during operation, 4 it results in high maintenance cost and user dissatisfaction 4 It may cause mission failure 4 Impact on operational performance and reliability S o m e o f t h e c a s e s t u d i e s % 9 9 7 8 % 9 9 9

' i s n e y 3 s

5 i o n

6 i n g ,

In the fall of %997, 'isney company Released its first multimedia :'8R,M game for children, The 5ion 6ing -nimated storybook. This was 'isney3s first !enture into the market and it was highly promoted and ad!ertised. Sales were huge. It was 0the game to buy1 for children that holiday season. +hat happened, howe!er, was a huge debacle. ,n 'ecember &;, the day after :hristmas, 'isney3s customer support phones began to ring, and ring, and ring. Soon the phones support technicians were swamped with calls from angry parents with crying children who couldn3t get the software to work. <umerous stories appeared in newspapers and on T= news. This problem later was found out, due to non performance of software testing for all conditions.

#o!tware Bug8 : ;ormal $e!inition


:alling any and all software problems bugs may sound simple enough, but doing so hasn3t really addressed the issue. To keep from running in circular definitions, there needs to be a definiti!e description of what a bug is. - software bug occurs when one or more of the following fi!e rules is true) %> &> ?> 7> 9> The software doesn3t do something that the product specification says it should do. The software does something that the product specification says it shouldn3t do. The software does something that the product specification doesn3t mention. The software doesn3t do something that the product specification doesn3t mention but should. The software is difficult to understand, hard to use, slow, or @in the software tester3s eyes8 will be !iewed by the end user as #ust plain not right.

6hat exactly does #o!tware Tester $o9 '4r 3ole o! Tester(


Arom the abo!e B$amples you ha!e seen how nasty bugs can be and you know what is the definition of a bug is, and you can think how costly they can be. So main goal of tester is 0The goal of Software Tester is to find bugs1 -s a software tester you shouldn3t be content at #ust finding bugs, you should think about how to find them sooner in the de!elopment process, thus making them cheaper to fi$. 0The goal of a Software Tester is to find bugs, and find them as early as possible1. Cut, finding bugs early isn3t enough. 0The goal of a Software Tester is to find bugs, and find them as early as possible and make sure they get fi$ed1

rinciple o! Testing
The main ob#ecti!e of testing is to find defects in requirements, design, documentation, and code as early as possible. The test process should be such that the software product that will be deli!ered to the customer is defect less. -ll Tests should be traceable to customer requirements. Test cases must be written for in!alid and une$pected, as well as for !alid and e$pected input conditions. - necessary part of a test case is a definition of the e$pected output or result. - good test case is one that has high probability of detecting an as8 yet undisco!ered error.

<ight Basic
D D D D D

rinciples o! Testing

'efine the e$pected output or result. 'on(t test your own programs. Inspect the results of each test completely. Include test cases for in!alid or une$pected conditions. Test the program to see if it does what it is not supposed to do as well as what it is supposed to do.

D D

-!oid disposable test cases unless the program itself is disposable. 'o not plan tests assuming that no errors will be found.

The probability of locating more errors in any one module is directlyproportional to the number of errors already found in that module. Best Testing ractices to 7e !ollowed during testing D D D D Testing and e!aluation responsibility is gi!en to e!ery member, so as to generate team responsibility among all. 'e!elop Master Test "lan so that resource and responsibilities are understood and assigned as early in the pro#ect as possible. Systematic e!aluation and preliminary test design are established as a part of all system engineering and specification work. Testing is used to !erify that all pro#ect deli!erables and components are complete, and to demonstrate and track true pro#ect progress.

D D

-8risk prioriti ed list of test requirements and ob#ecti!es Esuch as requirements8based, design8based, etc> are de!eloped and maintained. :onduct Re!iews as early and as often as possible to pro!ide de!eloper feedback and get problems found and fi$ed as they occur.

#o!tware $e%elopment &i!e Cycle '#$&C(

5et us look at the Traditional Software 'e!elopment life cycle !s "resently or Mostly commonly used life cycle.

Requirements

Requirements

Design

Design

Development

Development

Testing

Implementation

Implementation

Maintenance

Maintenance

Aig - ETraditional>

Aig C EMost commonly used>

In the abo!e Aig -, the Testing "hase comes after the 'e!elopment or coding is complete and before the product is launched and goes into Maintenance phase. +e ha!e some disad!antages using this model 8 cost of fi$ing errors will be high because we are not able to find errors until coding is completed. If there is error at Requirements phase then all phases should be changed. So, total cost becomes !ery high. The Aig C shows the recommended Test "rocess in!ol!es testing in e!ery phase of the life cycle. 'uring the Requirements phase, the emphasis is upon !alidation to determine that the defined requirements meet the needs of the organi ation. 'uring 'esign and 'e!elopment phases, the emphasis is on !erification to ensure that the design and program accomplish the defined requirements. 'uring the Test and Installation phases, the emphasis is on inspection to determine that the implemented system meets the system specification. 'uring the maintenance phases, the system will be re8tested to determine that the changes work and that the unchanged portion continues to work.

3e2uirements and :nalysis #peci!ication


The main ob#ecti!e of the requirement analysis is to prepare a document, which includes all the client requirements. That is, theSoftware Requirement Specification requirements and specifications are critical for ha!ing a successful

pro#ect. Remo!ing errors at this phase can reduce the cost as much as errors found in the 'esign phase. -nd also you should !erify the following acti!ities) ESRS> document is the primary output of this phase. "roper D D D D 'etermine =erification -pproach. 'etermine -dequacy of Requirements. Fenerate functional test data. 'etermine consistency of design with requirements.

' e s i g n

p h a s e

In this phase we are going to design entire pro#ect into two D .igh @5e!el 'esign or System 'esign.

5ow @5e!el 'esign or 'etailed 'esign. o r S y s t e m

. i g h @ 5 e ! e l ' e s i g n ' e s i g n E . 5 ' >

.igh @ le!el 'esign gi!es the o!erall System 'esign in terms of ;unctional :rchitecture and $ata7ase design . This is !ery useful for the de!elopers to understand the flow of the system. In this phase design team, re!iew team Etesters> and customers plays a ma#or role. Aor this the entry criteria are the requirement document that is SRS. -nd the e$it criteria will be .5', pro#ects standards, the functional design documents, and the database design document. &ow = &e%el $esign '&&$( 'uring the detailed phase, the !iew of the application de!eloped during the high le!el design is broken down into modules and programs. 5ogic design is done for e!ery program and then documented as program speci!ications. Aor e!ery program, a unit test plan is created. The entry criteria for this will be the .5' document. -nd the e$it criteria will the program specification and unit test plan E55'>.

$e%elopment

hase

This is the phase where actually coding starts. -fter the preparation of .5' and 55', the de!elopers know what is their role and according to the specifications they de!elop the pro#ect. This stage produces the source code, e$ecutables, and database. The output of this phase is the sub#ect to subsequent testing and !alidation. -nd we should also !erify these acti!ities) D D 'etermine adequacy of implementation. Fenerate structural and functional test data for programs.

The inputs for this phase are the physical database design document, pro#ect standards, program specification, unit test plan, program skeletons, and utilities tools. The output will be test data, source data, e$ecutables, and code re!iews. Testing phase

This phase is intended to find defects that can be e$posed only by testing the entire system. This can be done by Static Testing or 'ynamic Testing. Static testing means testing the product, which is not e$ecuting, we do it by e$amining and conducting the re!iews. 'ynamic testing is what you would normally think of testing. +e test the e$ecuting part of the pro#ect. - series of different tests are done to !erify that all system elements ha!e been properly integrated and the system performs all its functions.

<ote that the system test planning can occur before coding is completed. Indeed, it is often done in parallel with coding. The input for this is requirements specification document, and the output are the system test plan and test result. Implementation phase or the :cceptance phase This phase includes two basic tasks ) D D Fetting the software accepted Installing the software at the customer site.

-cceptance consist of formal testing conducted by the customer according to the -cceptance test plan prepared earlier and analysis of the test results to determine whether the system satisfies its acceptance criteria. +hen the result of the analysis satisfies the acceptance criteria, the user accepts the software. Maintenance phase This phase is for all modifications, which is not meeting the customer requirements or any thing to append to the present system. -ll types of corrections for the pro#ect or product take place in this phase. The cost of risk will be !ery high in this phase. This is the last phase of software de!elopment life cycle. The input to this will be pro#ect to be corrected and the output will be modified !ersion of the pro#ect.

#o!tware $e%elopment &i!ecycle Models


The process used to create a software product from its initial conception to its public release is known as the software de!elopment lifecycle model. There are many different methods that can be used for de!eloping software, and no model is necessarily the best for a particular pro#ect. There are four frequently used models) D D D D Cig @Cang Model +aterfall Model "rototype Model Spiral Model

Bin = Bang Model The Cig8 Cang Model is the one in which we put huge amount of matter Epeople or money> is put together, a lot of energy is e$pended @ often !iolently @ and out comes the perfect software product or it doesn3t. The beauty of this model is that it3s simple. There is little planning, scheduling, or Aormal de!elopment process. -ll the effort is spent de!eloping the software and writing the code. It3s and ideal process if the product requirements aren3t well understood and the final release date is fle$ible. It3s also important to ha!e fle$ible customers, too, because they won3t know what they3re getting until the !ery end.

6ater!all Model
- pro#ect using waterfall model mo!es down a series of steps starting from an initial idea to a final product. -t the end of each step, the pro#ect team holds a re!iew to determine if they3re ready to mo!e to the ne$t step. If the pro#ect isn3t ready to progress, it stays at that le!el until it3s ready. Bach phase requires well8defined information, utili es well8defined process, and results in well8defined outputs. Resources are required to complete the process in each phase and each phase is accomplished through the application of e$plicit methods, tools and techniques.

The +aterfall model is also called the "hased model because of the sequential mo!e from one phase to another, the implication being that systems cascade from one le!el to the ne$t in smooth progression. It has the following se!en phases of de!elopment)

The figure represents the +aterfall Model.

<otice three important points about this model. G


G G

There3s a large emphasis on specifying what the product will be.


The steps are discrete/ there3s no o!erlap. There3s no way to back up. -s soon as you3re on a step, you need to complete the tasks for that step and then mo!e on.

rototype model
The "rototyping model, also known as the B!olutionary model, came into S'5: because of certain failures in the first !ersion of application software. - failure in the first !ersion of an application ine!itably leads to need for redoing it. To a!oid failure of S'5:, the concept of "rototyping is used. The basic idea of "rototyping is that instead of fi$ing requirements before the design and coding can begin, a prototype is to understand the requirements. The prototype is built using known requirements. Cy !iewing or using the prototype, the user can actually feel how the system will work. The prototyping model has been defined as)

>: model whose stages consist o! expanding increments o! an operational so!tware with the direction o! e%olution 7eing determined 7y operational experience.1
rototyping rocess

The following acti!ities are carried out in the prototyping process) D D D D D D The de!eloper and die user work together to define the specifications of the critical parts of the system. The de!eloper constructs a working model of the system. The resulting prototype is a partial representation of the system. The prototype is demonstrated to the user. The user identifies problems and redefines the requirements. The designer uses the !alidated requirements as a basis for designing the actual or production software rototyping is used in the !ollowing situations8 D D D D +hen an earlier !ersion of the system does not e$ist. +hen the user(s needs are not clearly definable2identifiable. +hen the user is unable to state his2her requirements. +hen user interfaces are an important part of the system being de!eloped.

#piral model The traditional software process models don(t deal with the risks that may be faced during pro#ect de!elopment. ,ne of the ma#or causes of pro#ect failure in the past has been negligence of pro#ect risks. 'ue to this, nobody was prepared when something unforeseen happened. Carry Coehm recogni ed this and tried to incorporate the factor, pro#ect risk, into a life cycle model. The result is the Spiral model, which was first presented in %9H;. The new model aims at incorporating the strengths and a!oiding the different of the other models by shifting the management emphasis to risk e!aluation and resolution. <ach phase in the spiral model is split into !our sectors o! ma.or acti%ities. These acti!ities are as follows) 47.ecti%e setting8 This acti!ity in!ol!es specifying the pro#ect and process ob#ecti!es in terms of their functionality and performance. 3isk analysis8 It in!ol!es identifying and analy ing alternati!e solutions. It also in!ol!es identifying the risks that may be faced during pro#ect de!elopment. <ngineering8 This acti!ity in!ol!es the actual construction of the system. Customer e%aluation8 'uring this phase, the customer e!aluates the product for any errors and modifications.

#o!tware Testing and $e!initions


D ,eri!ication and %alidation D ro.ect Management D 0uality Management D 3isk Management D Con!iguration Management D Cost Management Compati7ility Management

Terms

D
6

=erificationI !alidation

=erification and !alidation are often used interchangeably but ha!e different definitions. These differences are important to software testing. =erification is the process confirming that software meets its specifications. ,alidation is the process confirming that it meets the user3s requirements.

=erification can be conducted through 3e%iews. Juality re!iews pro!ides !isibility into the de!elopment process throughout the software de!elopment life cycle, and help teams determine whether to continue de!elopment acti!ity at !arious checkpoints or milestones in the process. They are conducted to identify defects in a product early in the life cycle.

Types o! 3e%iews
D In-process 3e%iews )8

They look at the product during a specific time period of life cycle, such as during the design acti!ity. They are usually limited to a segment of a pro#ect, with the goal of identifying defects as work progresses, rather than at the close of a phase or e!en later, when they are more costly to correct. D $ecision-point or phase-end 3e%iews8 This type of re!iew is helpful in determining whether to continue with planed acti!ities or not. They are held at the end of each phase.

ost implementation 3e%iews8 These re!iews are held after implementation is complete to audit the process based on actual results. "ost8implementation re!iews are also know as 0 "ostmortems1, and are held to assess the success of the o!erall process after release and identify any opportunities for process impro!ements.

Classes o! 3e%iews
D In!ormal or eer 3e%iew) 8

In this type of re!iew generally a one8to one meeting between the author of a work product and a peer, initiated as a request for input regarding a particular artifact or problem. There is no agenda, and results are not formally reported. These re!iews occur as need8based through each phase of a pro#ect. D #emi!ormal or 6alkthrough 3e%iew8 The author of the material being re!iewed facilitates this. The participants are led through the material in one of the two formats) the presentation is made without interruptions and comments are made at the end, or comments are made throughout. "ossible solutions for unco!ered defects are not discussed during the re!iew. D ;ormal or Inspection 3e%iew8 -n inspection is more formali ed than a (walkthrough(, typically with ?8H people including a moderator, reader, and a recorder to take notes. The sub#ect of the inspection is typically a document such as a requirements spec or a test plan, and the purpose is to find problems and see what(s missing, not to fi$ anything. -ttendees should prepare for this type of meeting by reading thru the document/ most problems will be found during this preparation. The result of the inspection meeting should be a written report. Thorough preparation for inspections is difficult, painstaking work, but is one of the most cost effecti!e methods of ensuring quality.

Three rules should be followed for all re!iews) %. &. ?. The product is re!iewed, not the producer. 'efects and issues are identified, not corrected. -ll members of the re!iewing team are responsible for the results of the re!iew.

"ro#ect Management
"ro#ect management is ,rgani ing, "lanning and Scheduling software pro#ects. It is concerned with acti!ities in!ol!ed in ensuring that software is deli!ered on schedule and in accordance with the requirements of the organi ation de!eloping and procuring the software. "ro#ect management is needed because software de!elopment is always sub#ect to budget and schedule constraints that are set by the organi ation de!eloping the software. "ro#ect management acti!ities includes D D "ro#ect planning.

D D D

"ro#ect scheduling.

Iterati!e :ode2Test2Release "hases "roduction "hase "ost Mortem

ro.ect planning

This is the most time8consuming pro#ect management acti!ity. It is a continuous acti!ity from initial concept through to system deli!ery. "ro#ect "lan must be regularly updated as new information becomes a!ailable. +ith out proper plan, the de!elopment of the pro#ect will cause errors or it may lead to increase the cost, which is higher than the schedule cost. Re!iew.

ro.ect scheduling This acti!ity in!ol!es splitting pro#ect into tasks and estimate time and resources required to complete each task. ,rgani e tasks concurrently to make optional use of workforce. Minimi e task dependencies to a!oid delays caused by one task waiting for another to complete. "ro#ect Manager has to take into consideration !arious aspects like scheduling, estimating manpower resources, so that the cost of de!eloping a solution is within the limits. "ro#ect Manager also has to allow for contingency in planning.

I t e r a t i ! e " h a s e s

: o d e 2 T e s t 2 R e l e a s e

-fter the planning and design phases, the client and de!elopment team has to agree on the feature set and the timeframe in which the product will be deli!ered. This includes iterati!e releases of the product as to let the client see fully implemented functionality early and to allow the de!elopers to disco!er performance and architectural issues early in the de!elopment. Bach iterati!e release is treated as if the product were going to production. Aull testing and user acceptance is performed for each iterati!e release. B$perience shows that one should space iterations at least & @ ? months a part. If iterations are closer than that, more time will be spent on con!ergence and the pro#ect timeframe e$pands. 'uring this phase, code re!iews must be done weekly to ensure that the de!elopers are deli!ering to specification and all source code is put under source control. -lso, full installation routines are to be used for each iterati!e release, as it would be done in production. $eli%era7les
D D D D D D D Triage +eekly Status with "ro#ect "lan and Cudget -nalysis Risk -ssessment System 'ocumentation Kser 'ocumentation Eif needed> Test Signoff for each iteration :ustomer Signoff for each iteration

" r o d u c t i o n

" h a s e

,nce all iterations are complete, the final product is presented to the client for a final signoff. Since the client has been in!ol!ed in all iterations, this phase should go !ery smoothly. $eli%era7les
D D Ainal Test Signoff Ainal :ustomer Signoff " o s t M o r t e m " h a s e

The post mortem phase allows to step back and re!iew the things that went well and the things that need impro!ement. "ost mortem re!iews co!er processes that need ad#ustment, highlight the most effecti!e processes and pro!ide action items that will impro!e future pro#ects. To conduct a post mortem re!iew, announce the meeting at least a week in ad!ance so that e!eryone has time to reflect on the pro#ect issues they faced. B!eryone has to be asked to come to the meeting with the following) %. &. ?. Items that were done well during the pro#ect Items that were done poorly during the pro#ect Suggestions for future impro!ements 'uring the meeting, collection of the information listed abo!e is required. -s each person offers their input, categori e the input so that all comments are collected. This will allow one to see how many people had the same obser!ations during the pro#ect. -t the end of obser!ation re!iew, a list of the items will be a!ailable that were mentioned most often. The list of items allowing the team to prioriti e the importance of each item has to be perused. This will allow drawing a distinction of the most important items. Ainally, a list of action items has to be made that will be used to impro!e the process and publish the results. +hen the ne$t pro#ect begins, e!eryone on the team should re!iew the "ost Mortem Report from the prior release as to impro!e the ne$t release.

0uality Management

The pro#ect quality management knowledge area is comprised of the set of processes that ensure the result of a pro#ect meets the needs for which the pro#ect was e$ecuted. "rocesses such as quality planning, assurance, and control are included in this area. Bach process has a set of input and a set of output. Bach process also has a set of tools and techniques that are used to turn input into output. 'efinition of Juality) Juality is the totality of features and characteristics of a product or ser!ice that bare on its ability to satisfy stated or implied needs. ,r

Juality is defined as meeting the customer3s requirement for the first time and for e!ery time. This is much more that absence of defects which allows us to meet the requirements. Some goals of quality programs include) D D D Aitness for use. EIs the product or ser!ice capable of being usedL> Aitness for purpose. E'oes the product or ser!ice meet its intended purposeL> :ustomer satisfaction. E'oes the product or ser!ice meet the customer(s e$pectationsL>

0uality Management

rocesses

Juality "lanning) The process of identifying which quality standards is rele!ant to the pro#ect and determining how to satisfy them. Input includes) Juality policy, scope statement, product description, standards and regulations, and other process ,utput. Methods used) benefit 2 cost analysis, benchmarking, flowcharting, and design of e$periments. ,utput includes) Juality Management "lan, operational definitions, checklists, and Input to other processes.

Juality -ssurance The process of e!aluating o!erall pro#ects performance on a regular basis to pro!ide confidence that the pro#ect will satisfy the rele!ant quality standards. Input includes) Juality Management "lan, results of quality control measurements, and operational definitions. Methods used) quality planning tools and techniques and quality audits. ,utput includes) quality impro!ement.

Juality :ontrol The process of monitoring specific pro#ect results to determine if they comply with rele!ant quality standards and identifying ways to eliminate causes of unsatisfactory performance. Input includes) work results, Juality Management "lan, operational definitions, and checklists.

Methods used include) inspection, control charts, pareto charts, statistical sampling, flowcharting, and trend analysis. ,utput includes) quality impro!ements, acceptance decisions, rework, completed checklists, and process ad#ustments.

0uality

olicy

The o!erall quality intentions and direction of an organi ation as regards quality, as formally e$pressed by top management Total 0uality Management 'T0M( - common approach to implementing a quality impro!ement program within an organi ation

Juality :oncepts
D D D D

Mero 'efects The :ustomer is the <e$t "erson in the "rocess 'o the Right Thing Right the Airst Time E'TRTRTAT> :ontinuous Impro!ement "rocess E:I"> EArom Napanese word, 6ai en>

Tools of Juality Management


ro7lem Identi!ication Tools 8
areto Chart %. &. ?. 7. Ranks defects in order of frequency of occurrence to depict %OOP of the defects. E'isplayed as a histogram> 'efects with most frequent occurrence should be targeted for correcti!e action. HO8&O rule) HOP of problems are found in &OP of the work. 'oes not account for se!erity of the defects

Cause and <!!ect $iagrams '!ish7one diagrams or Ishikawa diagrams( %. &. -naly es the Input to a process to identify the causes of errors. Fenerally consists of H ma#or Input to a quality process to permit the characteri ation of each input.

?istograms %.

Shows frequency of occurrence of items within a range of acti!ity.

&.

:an be used to organi e data collected for measurements done on a product or process.

#catter diagrams %. Ksed to determine the relationship between two or more pieces of corresponding data. &. The data are plotted on an *Q8R* chart to determine correlation Ehighly positi!e, positi!e, no correlation, negati!e, and highly negati!e> "roblem -nalysis Tools %. &. ?. Fraphs :heck sheets Etic sheets> and check lists Alowcharts

Risk Management

Risk management must be an integral part of any pro#ect. B!erything does not always happen as planned. "ro#ect risk management contains the processes for identifying, analy ing, and responding to pro#ect risk. Bach process has a set of input and a set of output. Bach process also has a set of tools and techniques that are used to turn the input into output

Risk Management "rocesses


Risk Management "lanning Ksed to decide how to approach and plan the risk management acti!ities for a pro#ect. Input includes) The pro#ect charter, risk management policies, and+CS all ser!e as input to this process Methods used) Many planning meeting will be held in order to generate the risk management plan ,utput includes) The ma#or output is the risk management plan, which does not include the response to specific risks. .owe!er, it does include methodology to be used, budgeting, timing, and other information Risk Identification 'etermining which risks might affect the pro#ect and documenting their characteristics Input includes) The risk management plan is used as input to this process Methods used) 'ocumentation re!iews should be performed in this process. 'iagramming techniques can also be used ,utput includes) Risk and risk symptoms are identified as part of this process. There are generally two types of risks. They are business risks that are risks of gain or loss. Then there are pure risks that represent only a risk of loss. "ure risks are also known as insurable risks Risk -nalysis - qualitati!e analysis of risks and conditions is done to prioriti e their affects on pro#ect ob#ecti!es. Input includes) There are many items used as input into this process. They include things such as the risk management plan. The risks should already be identified as well. Kse of low precision data may lead to an analysis that is not useable. Risks are rated against how they impact the pro#ects ob#ecti!es for cost, schedule, scope, and quality Methods used) Se!eral tools and techniques can be used for this process. "robability and Impact will ha!e to be e!aluated ,utput includes) -n o!erall pro#ect risk ranking is produced as a result of this process. The risks are also prioriti ed. Trends should be obser!ed. Risks calculated as high or moderate are prime candidates for further analysis Risk Monitoring and :ontrol Ksed to monitor risks, identify new risks, e$ecute risk reduction plans, and e!aluate their effecti!eness throughout the pro#ect life cycle. Input includes) Input to this process includes the risk management plan, risk identification and analysis, and scope changes

Methods used) -udits should be used in this process to ensure that risks are still risks as well as disco!er other conditions that may arise. ,utput includes) ,utput includes work8around plans, correcti!e action, pro#ect change requests, as well as other items

Risk Management :oncepts


B$pected Monetary =alue EBM=> D - Risk Juantification Tool D BM= is the product of the risk e!ent probability and the risk e!ent !alue D Risk B!ent "robability) -n estimate of the probability that a gi!en risk e!ent will occur 'ecision Trees - diagram that depicts key interactions among decisions and associated chance e!ents as understood by the decision maker. :an be used in con#unction with BM= since risk e!ents can occur indi!idually or in groups and in parallel or in sequence.

:onfiguration Management

:onfiguration management E:M> is the processes of controlling, coordinate, and tracking the Standards and procedures for managingchanges in an e!ol!ing software product. :onfiguration Testing is the process of checking the operation of the software being tested on !arious types of hardware. :onfiguration management in!ol!es the de!elopment and application of procedures and standards to manage an e!ol!ing software product. This can be seen as part of a more general quality managementprocess. +hen released to :M, software systems are sometimescalled baselines, as they are a starting point for further de!elopment.The best bet in this situation is for the testers to go through the process of reporting whate!er bugs or blocking8type problems initially show up, with the focus being on critical bugs. Since this type of problem can se!erely affect schedules, and indicates deeper problems in the software de!elopment process Esuch as insufficient unit testing or insufficient integration testing, poor design, improper build or release procedures, etc.> managers should be notified, and pro!ided with some documentation as e!idence of the problem. :onfiguration management can be managed through D D =ersion control. :hanges made in the pro#ect.

,ersion Control and 3elease management

=ersion is an instance of system, which is functionally distinct in some way from other system instances. It is nothing but the updated or added features of the pre!ious !ersions of software. It has to be planned as to when the new system !ersion is to be produced and it has to be ensured that !ersion management procedures and tools are properly applied. Release is the means of distributing the software outside the de!elopment team. Releases must incorporate changes forced on the system by errors disco!ered by users and by hardware changes. They must also incorporate new system functionality. Changes made in the pro.ect This is one of most useful way of configuring the system. -ll changes will ha!e to be maintained that were made to the pre!ious !ersions of the software. This is more important when the system fails or not meeting the requirements. Cy making note of it one can get the original functionality. This can include documents, data, or simulation.

Con!iguration Management lanning


This starts at the early phases of the pro#ect and must define the documents or document classes, which are to be managed. 'ocuments, which might be required for future system maintenance, should be identified and included as managed documents. It defines 4 4 4 4 the types of documents to be managed document8naming scheme who takes responsibility for the :M procedures and creation of baselines polices for change control and !ersion management.

This contains three important documents they are D D D :hange management items. :hange request documents. :hange control board. E::C>

Change management
Software systems are sub#ect to continual change requests from users, from de!elopers, from market forces. :hange management is concerned with keeping, managing of changes and ensuring that they are implemented in the most cost8 effecti!e way.

Change re2uest !orm


'efinition of change request form is part of :M planning process. It records changes required, reason *why change 8was suggested and urgency of change E from requestor of the change>. It also records change e!aluation, impact analysis, change cost and recommendations ESystem maintenance staff>, - ma#or problem in change management is tracking change status. :hange tracking tools keep track the status of each change request and automatically ensure that change requests are sent to the right people at the right time. Integrated with Bmail systems allowing electronic changerequest distribution.

Change control 7oard


- group, who decide, whether or not they are cost8effecti!e from a strategic, organi ational and technical !iewpoint, should re!iew the changes. This group is sometimes called a change control board and includes members from pro#ect team.

11

Types o! #o!tware Testing

Testing

#tatic Testing
Static testing refers to testing something that3s not running. It is e$amining and re!iewing it. The specification is a document and not an e$ecuting program, so it3s considered as static. It3s also something that was created using written or graphical documents or a combination of both. ?igh-le%el 3e%iews o! speci!ication

Re!iew and Test similar software. &ow-le%el 3e%iews o! speci!ication D Specification -ttributes checklist. D Specification terminology checklist.

D D D

"retend to be the customer. Research e$isting Standards and Fuidelines.

$ynamic Testing

Techniques used are determined by type of testing that must be conducted. D Structural Eusually called *white bo$*> testing. D Aunctional E*black bo$*> testing.

#tructural testing or 6hite 7ox testing


Structural tests !erify the structure of the software itself and require complete access to the source code. This is known as Swhite bo$3 testing because you see into the internal workings of the code. +hite8bo$ tests make sure that the software structure itself contributes to proper and efficient program e$ecution. :omplicated loop structures, common data areas, %OO,OOO lines of spaghetti code and nests of ifs are e!il. +ell8designed control structures, sub8routines and reusable modular programs are good. +hite8bo$ testing strength is also its weakness. The code needs to be e$amined by highly skilled technicians. That means that tools and skills are highly speciali ed to -lso, large or distributed system the particular language and en!ironment. program that pro!ides bad data.

e$ecution goes beyond one program, so a correct procedure might call another In large systems, it is the e$ecution path as defined by the program calls, their input and output and the structure of common files that is important. This gets into a hybrid kind of testing that is often employed in intermediate or integration stages of testing.

;unctional or Black Box Testing


Aunctional tests e$amine the beha!ior of software as e!idenced by its outputs without reference to internal functions. .ence it is also called Sblack bo$3 testing. If

the program consistently pro!ides the desired features with acceptable performance, then specific source code features are irrele!ant. It(s a pragmatic and down8to8earth assessment of software.

Aunctional or Clack bo$ tests better address the modern programming paradigm. -s ob#ect8oriented programming, automatic code generation and code re8use becomes more pre!alent, analysis of source code itself becomes less important and functional tests become more important. Clack bo$ tests also better attack the quality target. Since only the people paying for an application can determine if it meets their needs, it is an ad!antage to create the quality criteria from this point of !iew from the beginning. Clack bo$ tests ha!e a basis in the scientific method. 5ike the process of science, Clack bo$ tests must ha!e a hypothesis Especifications>, a defined method or procedure Etest plan>, reproducible components Etest data>, and a standard notation to record the results. ,ne can re8run black bo$ tests after a change to make sure the change only produced intended results with no inad!ertent effects.

12

T
There are se!eral types of testing in a comprehensi!e software test process, many of which occur simultaneously. D Knit Testing D Integration Testing D System Testing D "erformance 2 Stress Test D Regression Test D Juality -ssurance Test D Kser -cceptance Test and Installation Test

esting le%els

@nit Testing
Testing each module indi!idually is called Knit Testing. This follows a +hite8Co$ testing. In some organi ations, a peer re!iew panel performs the design and2or code inspections. Knit or component tests usually in!ol!e some combination of structural and functional tests by programmers in their own systems. e$ecute. :omponent tests often require building some kind of supporting framework that allows components to

Integration testing
The indi!idual components are combined with other components to make sure that necessary communications, links and data sharing occur properly. It is not truly system testing because the components are not implemented in the operating en!ironment. The integration phase requires more planning and some reasonable sub8set of production8type data. 5arger systems often require se!eral integration steps. There are three basic integration test methods) D D D all8at8once bottom8up top8down

The all-at-once method pre!iously tested modules.

pro!ides

useful

solution

for

simple

integration problems, in!ol!ing a small program possibly using a few Bottom-up testing in!ol!es indi!idual testing of each module using a dri!er routine that calls the module and pro!ides it with needed resources. Cottom8up testing often works well in less structured shops because there is less dependency on a!ailability of other resources to accomplish the test. It is a more intuiti!e approach to testing that also usually finds errors in critical routines earlier than the top8down method. .owe!er, in a new system many modules must be integrated to produce system8le!el beha!ior, thus interface errors surface late in the process. Top-down testing fits a prototyping en!ironment that establishes an initial skeleton that fills indi!idual modules that is completed. entire test process. #ystem Testing The system test phase begins once modules are integrated enough to perform tests in a whole system en!ironment. System testing can occur in parallel with integration test, especially with the top8down method. er!ormance A #tress Testing -n important phase of the system testing, often8called load or !olume or performance test, stress tests tries to determine the failure point of a system under e$treme pressure. Stress tests are most useful when systems are being scaled up to larger en!ironments or being implemented for the first time. +eb sites, like any other large8scale system that requires multiple accesses and processing, contain !ulnerable nodes that should be tested before deployment. Knfortunately, most stress testing can only simulate loads on !arious points of the system and cannot truly stress the entire network, as the users would e$perience it. Aortunately, once stress and load factors ha!e been successfully o!ercome, it is only necessary to stress test again if ma#or changes take place. - drawback of performance testing is it confirms the system can handle hea!y loads, but cannot so easily determine if the system is producing the correct information. 3egression Testing Regression tests confirm that implementation of changes ha!e not ad!ersely affected other functions. Regression testing is a type of test as opposed to a phase in testing. Regression tests apply at all phases whene!er a change is made. 0uality :ssurance Testing The method lends itself to more structured organi ations that plan out the -lthough interface errors are found earlier, errors in critical low8le!el modules can be found later than you would like.

Some organi ations maintain a Juality Froup that pro!ides a different point of !iew, uses a different set of tests, and applies the tests in a different, more complete test en!ironment. The group might look to see that organi ation standards ha!e been followed in the specification, coding and documentation of the software. They might check to see that the original requirement is documented, !erify that the software properly implements the required functions, and see that e!erything is ready for the users to take a crack at it. @ser :cceptance Test and Installation Testing Traditionally, this is where the users Sget their first crack3 at the software. Knfortunately, by this time, it(s usually too late. If the users ha!e not seen If one can perform prototypes, been in!ol!ed with the design, and understood the e!olution of the system, they are ine!itably going to be unhappy with the result. pro#ect. e!ery test as user acceptance tests, there is much better chance of a successful

13

Testing iques
+hite Co$ Testing Technique

Types of Techn

+hite bo$ testing e$amines the basic program structure and it deri!es the test data from the program logic, ensuring that all statements and conditions ha!e been e$ecuted at least once. +hite bo$ tests !erify that the software design is !alid and also whether it was built according to the specified design. 'ifferent methods used are) Statement co!erage @ e$ecutes all statements at least once. Eeach and e!ery line> 'ecision co!erage all Clack Co$ Testing Technique @ e$ecutes each decision direction at least once. possible outcomes at least once. :ondition co!erage @ e$ecutes each and e!ery condition in the program with

Clack8bo$ test technique treats the system as a *black8bo$*, so it doesn(t e$plicitly use knowledge of the internal structure. Clack8bo$ test design is usually described as focusing on testing functional requirements. Synonyms for black bo$ include) Ceha!ioral, Aunctional, ,paque8bo$, and :losed8bo$. Clack bo$ testing is conducted on integrated, functional components whose design integrity has been !erified through completion of traceable white bo$ tests. Clack bo$ testing traces the requirements focusing on system e$ternals. It !alidates that the software meets the requirements irrespecti!e of the paths of e$ecution taken to meet each requirements. Three successful techniques for managing the amount of input data required includes ) D D D Bqui!alence "artitioning Coundary -nalysis Brror Fuessing

Bqui!alence "artitioning) Bqui!alence partitioning is the process of methodically reducing the hugeEinfinite>set of possible test cases into a much smaller, but still equally effecti!e set. -n Bqui!alence class is a subset of data that is representati!e of a larger class. Bqui!alence partitioning is a technique for testing equi!alence classes rather than undertaking e$hausti!e testing of each !alue of the larger class, when looking for equi!alence partitions, think about ways to group similar inputs, similar outputs, and similar operations of the software. These groups are the equi!alence partitions. ;or example - program that edits credit limits within a gi!en range ET&O,OOO8T9O,OOO> would ha!e three equi!alence classes) 5ess than T&O,OOOEin!alid> Cetween T&O,OOO and T9O,OOO E!alid> Freater than T9O,OOOEin!alid> Boundary %alue analysis8 If one can safely and confidently walk along the edge of a cliff without falling off, he can almost certainly walk in the middle of a field. If software can operate on the edge of its capabilities, it will almost certainly operate well under normal conditions. This technique consist of de!eloping test cases and data that focus on the input and output boundaries of a gi!en function. In same credit limit e$ample, boundary analysis would test)

5ow boundary plus or minus one ET%9,999 and T&O,OO%> ,n the boundary ET&O,OOO and T9O,OOO> Kpper boundary plus or minus one ET79,999 and T9O,OO%> Brror Fuessing This is based on the theory that test cases can be de!eloped based upon the intuition and e$perience of the Test8Bngineer. B$ample) In the e$ample of date, where one of the inputs is the date, a test may try Aebruary &9, &OOO or 9.9.99 Incremental testing Incremental testing is a disciplined method of testing the interfaces between unit8 tested programs as well as between system components. It in!ol!es adding unit8 tested programs to a gi!en module or component one by one, and testing each result and combination. There are two types of incremental testing) Top8down) 8 This begins testing from top of the module hierarchy and work down to the bottom using interim stubs to simulate lower interfacing modules or programs. Modules are added in descending hierarchical order. Cottom8up) 8 This begins testing from the bottom of the hierarchy and works up to the top. Modules are added in ascending hierarchical order. Cottom8up testing requires the de!elopment of dri!er modules, which pro!ide the test input, call the module or program being tested, and display test output. There are procedures and constraints associated with each of these methods, although bottom8up testing is often thought to be easier to use. 'ri!ers are often easier to create than stubs, and can ser!e multiple purposes. ,utput is also often easier to e$amine in bottom8up testing, as the output always comes from the module directly abo!e the module under test. Thread testing This test technique, which is often used during early integration testing,

demonstrates key functional capabilities by testing a string of units that accomplish a specific function in the application. Thread testing and incremental testing are usually utili ed together. Aor e$ample, units can undergo incremental until enough

units are integrated and a single business function can be performed, threading through the integrated components.

14

Testing &i!e Cycle

Test

lan

reparation

The software test plan is the primary means by which software testers communicate to the product de!elopment team what they intend to do. The purpose of the software test plan is to prescribe the scope, approach, resource, and schedule of the testing acti!ities. To identify the items being tested, the features to be tested, the testing tasks to be preformed, the personnel responsible for each task, and the risks associated with the plan. The test plan is simply a by8product of the detailed planning process that3s undertaken to create it. It3s the planning that matters, not the resulting documents. The ultimate goal of the test planning process is communicating the software test team3s intent, its e$pectations, and its understanding of the testing that3s to be performed. The following are the important topics, which helps in preparation of Test plan. D ?igh-&e%el <xpectations The first topics to address in the planning process are the ones that define the test team3s high8le!el e$pectations. They are fundamental topics that must be agreed to, by e!eryone on the pro#ect team, but they are often o!erlooked. They might be considered 0too ob!ious1 and assumed to be understood by e!eryone, but a good tester knows ne!er to assume anything. D eopleB laces and Things Test plan needs to identify the people working on the pro#ect, what they do, and how to contact them. The test team will likely work with all of them and knowing who they are and how to contact them is !ery important.

Similarly, where documents are stored, where the software can be downloaded from, where the test tools are located, and so on need to be identified. D Inter-Croup 3esponsi7ilities responsibilities identify tasks and deli!erables that Inter8Froup

potentially affect the test effort. The test team3s work is dri!en by many other functional groups @ programmers, pro#ect manages, technical writers, and so on. If the responsibilities aren3t planned out, the pro#ect, specifically the testing, can become a worst or resulting in important tasks been forgotten. D Test phases To plan the test phases, the test team will look at the proposed de!elopment model and decide whether unique phases, or stages, of testing should be performed o!er the course of the pro#ect. The test planning process should identify each proposed test phase and make each phase known to the pro#ect team. This process often helps the entire team from and understands the o!erall de!elopment model. D Test strategy The test strategy describes the approach that the test team will use to test the software both o!erall and in each phase. 'eciding on the strategy is a comple$ task8 one that needs to be made by !ery e$perienced testers because it can determine the successes or failure of the test effort.

Bug 3eporting

B$actly what process will be used to manage the bugs needs to be planned so that each and e!ery bug is tracked, from when it3s found to when it3s fi$ed @ and ne!er, e!er forgotten. D Metrics and #tatistics

Metrics and statistics are the means by which the progress and the success of the pro#ect, and the testing, are tracked. The test planning process should identify e$actly what information will be gathered, what decisions will be made with them, and who will be responsible for collecting them. D 3isks and Issues

- common and !ery useful part of test planning is to identify potential problem or risky areas of the pro#ect @ ones that could ha!e an impact on the test effort.

Test Case $esign The test case design specification refines the test approach and identifies the features to be co!ered by the design and its associated tests. It also identifies the test cases and test procedures, if any, required to accomplish the testing and specifics the feature pass or fail criteria. The purpose of the test design specification is to organi e and describe the testing needs to be performed on a specific feature. The following topics address this purpose and should be part of the test design specification that is created) D Test case I$ or identi!ication - unique identifier that can be used to reference and locate the test design specification the specification should also reference the o!erall test plan and contain pointers to any other plans or specifications that it references. D Test Case $escription

It is a description of the software feature co!ered by the test design specification for e$ample, 0 the addition function of calculator,1 0font si e selection and display in word pad,1 and 0!ideo card configuration testing of quick time.1 D Test case procedure It is a description of the general approach that will be used to test the features. It should e$pand on the approach, if any, listed in the test plan, describe the technique to be used, and e$plain how the results will be !erified. D Test case Input or Test $ata It is the input the data to be tested using the test case. The input may be in any form. 'ifferent inputs can be tried for the same test case and test the data entered is correct or not. D <xpected result It describes e$actly what constitutes a pass and a fail of the tested feature. +hich is e$pected to get from the gi!en input. Test <xecution and Test &og reparation

-fter test case design, each and e!ery test case is checked and actual result obtained. -fter getting actual result, with the e$pected column in the design stage is compared, if both the actual and e$pected are same, then the test is passed otherwise it will be treated as failed.

<ow the test log is prepared, which consists of entire data that were recorded, whether the test failed or passed. It records each and e!ery test case so that it will be useful at the time of re!ision. <xample Test case ID Sys_xyz_01 Sys_xyz_02 Test case Description Checking the login window Checking the main window Test status! result Fail True

15

$e!ect Tracking

- defect can be defined in one or two ways. Arom the producer(s !iewpoint, a defect is a de!iation from specifications, whether missing, wrong, etc. Arom the :ustomer(s !iewpoint, a defect is any that causes customer dissatisfaction, whether in the requirements or not, this is known as *fit for use*. It is critical that defects identified at each stage of the pro#ect life cycle be tracked to resolution.

'efects are recorded for following ma#or purposes) D D D D To correct the defect To report status of the application To gather statistics used to de!elop defect e$pectations in future applications To impro!e the software de!elopment process

Most pro#ect teams utili e some type of tool to support the defect tracking process. This tool could be as simple as a white board or a table created and maintained in a word processor or one of the more robust tools a!ailable today, on the market, such as Mercury(s Test 'irector etc. Tools marketed for this purpose usually come with some number of customi able fields for tracking pro#ect specific data in addition to the basics. They also pro!ide ad!anced features such as standard and ad8hoc reporting, e8mail notification to de!elopers and2or testers when a problem is assigned to them, and graphing capabilities.

-t a minimum, the tool selected should support the recording and communication significant information about a defect. Aor e$ample, a defect log could include) D D D D D D D D D D D D #e%erity %ersus 'efect I' number 'escripti!e defect name and type Source of defect 8test case or other source 'efect se!erity 'efect priority 'efect status Ee.g. open, fi$ed, closed, user error, design, and so on> 8more robust tools pro!ide a status history for the defect 'ate and time tracking for either the most recent status change, or for each change in the status history 'etailed description, including the steps necessary to reproduce the defect :omponent or program where defect was found Screen prints, logs, etc. that will aid the de!eloper in resolution process Stage of origination "erson assigned to research and2or correct the defect riority

The se!erity of a defect should be assigned ob#ecti!ely by the test team based on predefined se!erity descriptions. Aor e$ample a *se!erity one* defects maybe defined as one that causes data corruption, a system crash, security !iolations, etc. In large pro#ect, it may also be necessary to assign a priority to the defect, which determines the order

in which defects should be fi$ed. The priority assigned to a defect is usually more sub#ecti!e based upon input from users regarding which defects are most important to them, and therefore should be fi$ed first.

It is recommended that se!erity le!els be defined at the start of the pro#ect so that they intently assigned and understood by the team. This foresight can help test teams a!oid the common disagreements with de!elopment teams about the criticality of a defect. #ome general principles D The primary goal is to pre!ent defects. +here!er this is not possible or practical, the goals are to both find the defect as quickly as possible and minimi e the impact of the defect. D The defect management process, like the entire software

de!elopment process, should be risk dri!en, i.e., strategies, priorities and resources should be based on an assessment of the risk and the degree to which the e$pected impact of risk can be reduced. D 'efect measurement should be integrated into the de!elopment process and be used by the pro#ect team to impro!e the de!elopment process. In other words, information on defects should be captured at the source as a natural by8product of doing the #ob. "eople unrelated to the pro#ect or system should not do it. D -s much as possible, the capture and analysis of the information should be automated. There should be a document, which includes a list of tools, which ha!e defect management capabilities and can be used to automate some of the defect management processes. D 'efect information should be used to impro!e the process. This, in fact, is the primary reason for gathering defect information. D Imperfect or flawed processes cause most defects. Thus, to pre!ent defects, the process must be altered.

The $e!ect Management

rocess

The key elements of a defect management process are as follows. D D D D D D 'efect pre!ention 'eli!erable base8lining 'efect disco!ery2defect naming 'efect resolution "rocess impro!ement Management reporting

16

16

Test 3eports
- final test report should be prepared at the conclusion of each test acti!ity. This might include

D D D D

Indi!idual "ro#ect Test Report Ee.g., a single software system> Integration Test Report System Test Report -cceptance Test Report

The test reports are designed to document the results of testing as defined in the test plan. +ithout a well8de!eloped test plan, which has been e$ecuted in accordance with its criteria, it is difficult to de!elop a meaningful test report. It is designed to accomplish three ob#ecti!es) D D D 'efine the scope of testing 8 normally a brief recap of the test plan/ "resent the results of testing/ and 'raw conclusions and make recommendations based on those results The test report may be a combination of electronic data and hard copy. Aor e$ample, if the function test matri$ is maintained electronically, there is no reason to print that, as the paper report will summari e that data, draws the appropriate conclusions, and present recommendations. The test report has one immediate and three long8term purposes. The immediate purpose is to pro!ide information to the customers of the software system so that they can determine whether the system is ready for production) and if so, to assess the potential consequences and initiate appropriate actions to minimi e those consequences. The first of the three long8term uses is for the pro#ect to trace problems in the e!ent the application malfunctions in production. 6nowing which functions ha!e been correctly tested and which ones still contain defects can assist in taking correcti!e action. The second long8term purpose is to use the data to analy e the rework process for making changes to pre!ent defects from occurring in the future. -ccumulating the results of many test reports to identify which components of the rework process are detect8prone does this. These defect8prone components identify tasks2steps that, if impro!ed, could eliminate or minimi e the occurrence of high8frequency defects. The third long8term purpose is to show what was accomplished. Indi%idual ro.ect Test 3eport

These reports focus on indi!idual pro#ects Ee.g., software system>. +hen different testers test indi!idual pro#ects, they should prepare a report on their results. Integration Test 3eport Integration testing tests the interfaces between indi!idual pro#ects. - good test plan will identify the interfaces and institute test conditions that will !alidate interfaces. Fi!en this, the interface report follows the same format as the indi!idual "ro#ect Test report, e$cept that the conditions tested are the interfaces. #ystem Test 3eport - system test plan standard that identified the ob#ecti!es of testing, what was to be tested, how it was to be tested and when tests should occur. The System Test report should present the results of e$ecuting that test plan. If this is maintained electronically, it need only be referenced, not included in the report. :cceptance Test 3eport There are two primary ob#ecti!es for testing. The first is to ensure that the system as implemented meets the real operating needs of the user or customer. If the defined requirements are those true needs, the testing should ha!e accomplished this ob#ecti!e. The second ob#ecti!e is to ensure that the software system can operate in the real8world user en!ironment, which includes people skills and attitudes, time pressures, changing business conditions, and so forth.

<ight Interim 3eports8 %. Aunctional Testing Status &. Aunctions +orking Timeline ?. B$pected !erses -ctual 'efects 'etected Timeline 7. 'efects 'etected !erses :orrected Fap Timeline 9. -!erage -ge of 'etected 'efects by Type ;. 'efect 'istribution U. Relati!e 'efect 'istribution H. Testing -ction ;unctional Testing #tatus 3eport This report will show percentages of the functions, which ha!e been) D D D Aully Tested Tested +ith ,pen 'efects <ot Tested

;unctions 6orking Timeline report This report will show the actual plan to ha!e all functions working !erses the current status of functions working. -n ideal format could be a line graph. <xpected %erses :ctual $e!ects $etected report This report will pro!ide an analysis between the number of defects being generated against the e$pected number of defects e$pected from the planning stage $e!ects $etected %erses Corrected Cap report This report, ideally in a line graph format, will show the number of defects unco!ered !erses the number of defects being corrected and accepted by the testing group. If the gap grows too large, the pro#ect may not be ready when originally planned.

:%erage :ge $etected $e!ects 7y Type report This report will show the a!erage outstanding defects by type Ese!erity %, se!erity &, etc.>. In the planning stage, it is benefic determine the acceptable open days by defect type.

$e!ect $istri7ution report This report will show the defect distribution by function or module. It can also include items such as numbers of tests completed. 3elati%e $e!ect $istri7ution report This report will take the pre!ious report E'efect 'istribution> and normali e the le!el of defects. -n e$ample would be one application might be more in depth than another, and would probably ha!e a higher le!el of defects. .owe!er, when normali ed o!er the number of functions or lines of code, would show a more accurate le!el of defects. Testing action report This report can show many different things, including possible shortfalls in testing. B$amples of data to show might be number of se!erity defects, tests that are behind schedule, and other information that would present an accurate testing picture

17

#o!tware Metric
Bffecti!e management of any process requires quantification, measurement, and modeling. Software metrics pro!ide a quantitati!e basis for the de!elopment and !alidation of models of the software de!elopment process. Metrics can be used to impro!e software producti!ity and quality. This module introduces the most commonly used software and re!iews their use in constructing models of the software de!elopment process. $e!inition o! #o!tware Metrics - metric is a mathematical number that shows a relationship between two !ariables. It is a quantitati!e measure of the degree to which a system, component or process possesses a gi!en attribute. Software Metrics are measures that are used to quantify the software, software de!elopment resource and software de!elopment process. Metric generally classified into & types. D "rocess Metric D "roduct Metric rocess Metric a metric used to measure the characteristic of the methods, techniques and tools employed in de!eloping, implementing and maintaining the software system.

roduct Metric a metric used to measure the characteristic of the documentation and code The metrics for the test process would include status of test acti!ities against the plan, test co!erage achie!ed so far, among others. -n important metric is the number of defects found in internal testing compared to the defects found in customer tests, which indicate the effecti!eness of the test process itself. Test Metrics The following are the Metrics collected in testing process @ser participation V Kser "articipation Test Time =s Total Test Time ath Tested V <umber of "ath Tested Total <umber of "aths

:cceptance Criteria Tested V -cceptance :riteria =erified =s Total -cceptance :riteria Cost to &ocate $e!ect V Test :ost <o of 'efects located in the Testing This metric shows the cost to locate a defect 'etected roduction $e!ect <o of 'efects detected in production V -pplication System si e Test :utomation :ost of Manual Test Bffort V Total Test :ost

18

4ther Testing Terms

@sa7ility Testing 'etermines how well the user will be able to understand and interact with the system. It identifies areas of poor human factors design that may make the system difficult to use. Ideally this test is conducted on a system prototype before de!elopment actually beings. If a na!igational or operational prototype is not a!ailable, screen prints of all of the applications screens or windows can be used to walk the user through !arious business scenarios. Con%ersion Testing Specifically designed to !alidate the effecti!eness of the con!ersion process. This test may be conducted #ointly by de!elopers and testers during integration testing, or at

the start of system testing, since system testing must be conducted with the con!erted data. Aield 8to 8Aield mapping and data translation is !alidated and, if a foil copy of production data will be used in the test. ,endor ,alidation Testing =erifies that the functionality of contracted or third party software meets the organi ation(s requirements, prior to accepting it and installing it into a production en!ironment. This test can be conducted #ointly by the software !endor and the test team, and focuses on ensuring that all requested functionality has been deli!ered.

#tress A &oad Testing :onducted to !alidate the application, database, and network, they may handle pro#ected !olumes of users and data effecti!ely. The test is conducted #ointly by de!elopers, testers, 'C-(s and network associates after the system testing. 'uring the test, the complete system is sub#ected to en!ironmental conditions that defer e$pectations to answer question such as) D D D .ow large can the database grow before performance degradesL -t what point will more storage space be requiredL .ow many users can use the system simultaneously before it slows down or failsL

er!ormance Testing Ksually conducted in parallel with stress and load testing in order to measure performance against specified ser!ice8le!el ob#ecti!es under !arious conditions. Aor instance, one may need to ensure that batch processing will complete within the allocated amount of time, or that on8line response times meet performance requirements. 3eco%ery Testing B!aluates the contingency features built into the application for handling inter and for returning to specific points in the application processing. -ny restoration, and restart capabilities are also tested here. The test team may conduct this test during system test or by another team specifically gathered for this purpose.

Con!iguration Testing In the IT Industry, a large percentage of new applications are either client2ser!er or web8based, !alidating that they will run on the !arious combinations of hardware and software. would Aor instance, configuration testing for an web8based application

incorporate !ersions and releases of operating systems, internet browsers, modem speeds, and !arious off the shelf applications that might be integrated Ee.g. e8mail application>

Bene!its 3ealiDation Test +ith the increased focus on the !alue of business returns obtained from in!estments information technology this type of test or analysis is becoming more critical. The benefits Reali ation Test is a test or analysis conducted after an application is mo!ed into production in order to determine whether the application is likely to deli!er the original pro#ected benefits. The analysis is usually conducted by8 the business user or client group who requested the pro#ect, and results are reported back to e$ecuti!e management.

19

Test #tandards

<xternal #tandards8 Aamiliarity with and adoption of industry test standards from ,rgani ations. Internal #tandards8'e!elopment and enforcement of the test standards that testers must meet

I<<<
D D D D Institute of Blectrical and Blectronics Bngineers Aounded in %HH7 .a!e an entire set of standards de!oted to Software Testers should be familiar with all the standards mentioned in IBBB.

I<<< #T:N$:3$#8 That a Tester should 7e aware o! %.;%O.%&8%99O &. U?O8%99H ?. H&H8%99H 7.H&98%99H 9. H?O8%99H Requirement IBBB Standard Flossary of Software Bngineering Terminology IBBB Standard for Software Juality -ssurance "lans IBBB Standard for Software :onfiguration Management "lan IBBB Standard for Software Test 'ocumentation. IBBB Recommended "ractice for Software Specification

;.%OOH8%9HU ER%99?> IBBB Standard for Software Knit Testing E-<SI>

U.

%O%&8%99H

IBBB Standard for Software =erification and =alidation. for Software Supplement =erification and to %O%&8%99H

H. %O%&a8%99H IBBB Standard =alidation :ontent Map to IBBB %&&&OU.% 9. %O%;8%99H IBBB Recommended

"ractice

for Software 'escriptions

%O. %O&H8%99U %%. %O778%99? %&. %O798%99& %?. %O9H8%99H %7. %O9H.%8%9HU %9. %O;%8%99H.%

IBBB Standard for Software Re!iews IBBB Standard classification for Software -nomalies IBBB Standard for Software "roducti!ity MetricsE-<SI> IBBB Standard for Software "ro#ect Management "lans IBBB Standard for Software Management IBBB Standard for Software Juality Metrics Methodology.

4ther #tandards8 D D D D I#48International ,rgani ation for Standards # IC< 8Software "rocess Impro!ement and :apability 'etermination NI#T 8<ational Institute of Standards and Technology $o$8'epartment of 'efense

Internal #tandards The use of Standards... D D D D D D Simplifies communication "romotes consistency and uniformity Bliminates the need to in!ent yet another solution to the same problem "ro!ides continuity "resents a way of preser!ing pro!en practices Supplies benchmarks and framework

6e7 Testing
Introduction The +eb Testing is mainly concerned on ; parts they are D D D D D D Ksability Aunctionality Ser!er side Interface :lient side :ompatibility "erformance Security

@sa7ility ,ne of the reasons the web browser is being used as the front end to applications is the ease of use. Ksers who ha!e been on the web before will probably know how to na!igate a well8built web site. +hile UO%& are concentrating on tin(s portion of

testing it is important to !erify that the application is easy to use. Many will belie!e that this is the least important area to test, the site should be better and easy to use. B!en if the web site is simple, there will always be some one who needs some clarification. -dditionally, the documentation needs also to be !erified, so that the instructions are correct.

The following are the some of the things to be checked for easy na!igation through website) D #ite map or na%igational 7ar

'oes the site ha!e a mapL Sometimes power users know e$actly where they want to go and don(t want to go through lengthy introductions. ,r new users get lost easily. Bither way a site map and2or e!er8present na!igational map can guide the user. The site map needs to be !erified for its correctness. 'oes each link on the map actually e$istL -re there links on the site that are not represented on the mapL Is the na!igational bar present on e!ery screenL Is it consistentL 'oes each link work on each pageL Is it organi ed in an intuiti!e mannerL

Content

To a de!eloper, functionality comes before wording. -nyone can slap together some fancy mission statement later, but while they are de!eloping, they #ust need some filler to !erify alignment and layout. Knfortunately, te$t produce like this may sneak through the cracks. It is important to check with the public relations department on the e$act wording of the content. ,therwise, the company can get into a lot of trouble, legally. ,ne has to make sure the site looks professional. ,!eruse of bold te$t, big fonts and blinking can turn away a customer quickly. It might be a good idea to consult a graphic designer to look o!er the site during Kser -cceptance Testing. Ainally, one has to make sure that any time a web reference is gi!en, that it is hyper linked. "lenty of sites ask them to email them at a specific address or to download a browser from an address. Cut if the user can(t click on it, they are going to be annoyed. D ColorsA7ackgrounds

B!er since the web became popular, e!eryone thinks they are a graphic designer. Knfortunately, some de!elopers are more interested in their new backgrounds, than ease of use. Sites will ha!e yellow te$t on a purple picture of a fractal pattern. This may seem *pretty neat*, but it(s not easy to use. Ksually, the best idea is to use little or no background. If there is a background, it might be a single color on the left side of the page, containing the na!igational bar. Cut, patterns and pictures distract the user.

Images

+hether it(s a screen grab or a little icon that points the way, a picture is worth a thousand words. Sometimes, the best way to tell the user something is to simply show them. .owe!er, bandwidth is precious to the client and the ser!er, so you need to conser!e memory usage. 'o all the images and !alue to each page, or do they simply waste bandwidthL :an a different file type E.FIA, N"F> be used for ?Ok lessL In general, one doesn(t want large pictures on the front page, since most users who abandon a load will do it on the front page. If the front page is a!ailable quickly, it will increase the chance they will stay.

Ta7les

It has to be !erified that tables are setup properly. 'oes the user constantly ha!e to scroll right to see the price of the itemL +ould it be more efficient to put the price closer to the left and put miniscule details to the rightL -re the columns wide enough or does e!ery row ha!e to wrap aroundL -re certain rows e$cessi!ely high because of one entryL These are some of the points to be taken care of. D 6rap-around

Ainally, it has to be !erified whether the wrap8around occurs properly. If the te$t refers to a picture on the right, make sure the picture is on the right. Make sure that widow and orphan sentences and paragraphs don(t layout in an awkward manner because of pictures. ;unctionality The functionality of the web site is why the company hired a de!eloper and not #ust an artist. This is the part that interfaces with the ser!er and actually *does stuff*. D &inks

- link is the !ehicle that gets the user from page to page. Two things has to be !erified for each link 8 that the link which brings to the page it said it would and

that the pages it is trying to link, e$ist. It may sound a little silly but many of the web sites e$ist with internal broken links.

;orms

+hen a user submits information through a form it needs to work properly. The submit button needs to work If the form is for an online registration, the user should be gi!en login information Ethat works> after successful completion. If the form gathers shipping information, it should be handled properly and the customer should recei!e their package. In order to test this, you need to !erify that the ser!er stores the information properly and that systems down the line can interpret and use that information. D $ata %eri!ication

If the system !erifies user input according to business rules, then that needs to work properly. Aor e$ample, a State field may be checked against a list of !alid !alues. If this is the case, you need to !erify that the list is complete and that the program actually calls the list properly Eadd a bogus !alue to the list and make sure the system accepts it>. D Cookies

Most users only like the kind with sugar, but de!elopers lo!e web cookies. If the system uses them, you need to check them. If they store login information, make sure the cookies work and make sure it(s encrypted in the cookie file. If the cookie is used for statistics, !erify that totals are being counted properly. -nd you(ll probably want to make sure those cookies are encrypted too, otherwise people can edit their cookies and skew your statistics. D :pplication speci!ic !unctional re2uirements

Most importantly, one may want to !erify the application specific functional requirements, Try to perform all functions a user would) place an order, change an order, cancel an order, check the status of the order, change shipping information before an order is shipped, pay online, ad naseum. This is why users will show up on the de!eloper3s doorstep, so one need to make sure that he can do what is ad!ertised.

#er%er side Inter!ace Many times, a web site is not an island. The site will call e$ternal ser!ers for additional data, !erification of data or fulfillment of orders. D #er%er inter!ace

The first interface one should test is the interface between the browser and the ser!er, transactions should be attempted, then the ser!er logs !iewed and !erified that what is seen in the browser is actually happening on the ser!er. It(s also a good idea to run queries on the database to make sure the transaction data is being stored properly. D <xternal inter!aces

Some web systems ha!e e$ternal interfaces. Aor e$ample, a merchant might !erify credit card transactions real8time in order to reduce fraud. Se!eral test transactions may ha!e to be sent using the web interface. Try credit cards that are !alid, in!alid, and stolen. If the merchant only takes =isa and Master:ard, try using a 'isco!er card. E- simple client8side script can check ? for -merican B$press, 7 for =isa, 9 for Master:ard, or ; for 'isco!er, before the transaction is sent.> Casically, it has to be ensured that the software can handle e!ery possible message returned by the e$ternal ser!er. D <rror handling

,ne of the areas left untested most often is interface error handling. Ksually we try to make sure our system can handle all our errors, but we ne!er plan for the other systems( errors or for the une$pected. Try lea!ing the site mid8transaction 8 what happensL 'oes the order complete anywayL Try losing the Internet connection from the user to the ser!er. Try losing the connection from the ser!er to the credit card !erification ser!er. Is there proper error handling for all these situationsL -re charges still made to credit cardsL Is the interruption is not user initiated, does the order get stored so customer ser!ice reps can call back if the user doesn(t come back to the siteL

Client side Compati7ility It has to be !erified that the application can work on the machines your customers will be using. If the product is going to the web for the world to use, e!ery operating system, browser, !ideo setting and modem speed has to be tried with !arious combinations. D 4perating systems

'oes the site work for both M-: and ICM :ompatiblesL Some fonts are not a!ailable on both systems, so make sure that secondary fonts are selected. Make sure that the site doesn(t use plug8ins only a!ailable for one ,S, if the users using both. D Browsers

'oes the site work with <etscapeL Internet B$plorerL 5inu$L Some .TM5 commands or scripts only work for certain browsers. Make sure there are alternate tags for images, in case someone is using a te$t browser. If SS5 security is used, it has to be checked whether browsers ?.O and higher, but it has to be !erified that there is a message for those using older browsers. D ,ideo settings

'oes the layout still look good on ;7O$7OO or ;OO$HOOL -re fonts too small to readL -re they too bigL 'oes all the te$t and graphic alignment still workL D ModemAconnection speeds

'oes it take %O minutes to load a page with a &H.H modem, but whether it is tested after hooking up to high8speed connectionsL Ksers will e$pect long download times when they are grabbing documents or demos, but not on the front page. It has to be ensured that the images aren(t too large. Make sure that marketing don(t put 9Ok of font si e 8; keywords for search engines.

rinters

Ksers like to print. The concept behind the web should sa!e paper and reduce printing, but most people would rather read on paper than on the screen. So, you need to !erify that the pages print properly. Sometimes images and te$t align on the screen differently than on the printed page. It has to be !erified that order confirmation screens can be printed properly. D Com7inations

- different combination has to be tried. Maybe ;OO$HOO looks good on the M-: but not on the ICM. Maybe ICM with <etscape works, but not with 5inu$. If the web site will be used internally it might make testing a little easier. If the company has an official web browser choke, then it has to be !erified that it works for that browser. If e!eryone has a high8speed connection, load times need not be checked. ECut it has to be kept in mind, some people may dial in from home.> +ith internal applications, the de!elopment team can make disclaimers about system requirements and only support those systems setups. Cut, ideally, the site should work on all machines without limit growth and changes in the future. er!ormance Testing It need to be !erified that the system can handle a large number of users at the same time, a large amount of data from each user, and a long period of continuous use. -ccessibility is e$tremely important to users. If they get a *busy signal*, they hang up and call the competition. <ot only must the system be checked so the customers can gain access, but many times hackers will attempt to gain access to a system by o!erloading it, Aor the sake of security, the system needs to know what to do when it(s o!erloaded/ not simply blow up. D Concurrent users at the same time

If the site #ust put up the results of a national lottery, it will be better to handle millions of users right after the winning numbers are posted. - load test tool would be able simulate concurrent users accessing the site at the same time. D &arge amount o! data !rom each user

Most customers may only order %89 books from your new online bookstore, but what if a uni!ersity bookstore decides to order 9OOO copies of Intro to "sychologyL ,r what if one user wants to send a gift to larger number of his2her friends for :hristmas Eseparate mailing addresses for each, of course.> :an the system handle large amounts of from a single userL

&ong period o! continuous use

If the site is intended to take orders for specific occasion, then it will be better to handle well before the occasion. If the site offers web8based email, it will be better to run months or e!en years, without downtimes. It may probably be required to use an automated test tool to implement these types of tests, since they are difficult to do manually. Imagine coordinating %OO people to hit the site at the same time. <ow try %OO,OOO people. Fenerally, the tool will pay for itself the second time you use it. ,nce the tool is set up, running another test is #ust a click away. #ecurity B!en if credit card payments are not accepted, security is !ery important. The web site will be the only e$posure for some customers to know about a company. -nd, if that e$posure is a hacked page, the customers won(t feel safe doing business with the company using internet. D $irectory setup

The most elementary step of web security is proper setup of directories. Bach directory should ha!e an inde$.html or main.html page so a directory listing doesn(t appear. D ##& '#ecured #ocket &ayer(

Many sites use SS5 for secure transactions. +hile entering an SS5 site, there will be a browser warning and the .TT" in the location field on the browser will change to .TT"S. If the de!elopment group uses SS5 it is to be ensured that, there is an alternate page for browser with !ersions less than ?.O, since SS5 is not compatible with those browsers. Sufficient warnings while entering and lea!ing the secured site are to be pro!ided. -lso it needs to be checked whether there is a time8out limit or what happens if the user tries a transaction after the timeoutL

&ogins

In order to !alidate users, se!eral sites require customers to login. This makes it easier for the customer since they don(t ha!e to re8enter personal information e!ery time. Rou need to !erify that the system does not allow in!alid usernames2password and that does allow !alid logins. Is there a ma$imum number of failed logins allowed before the ser!er locks out the current userL Is the lockout based on I"L +hat happens after the ma$imum failed login attempts/ what are the rules for password selection @ these needs to be checked. D &og !iles

Cehind the scenes, it needs to be !erified that ser!er logs are working properly. 'oes the log track e!ery transactionL 'oes it track unsuccessful login attemptsL 'oes it only track stolen credit card usageL +hat does it store for each transactionL I" addressL Kser nameL D #cripting languages

Scripting languages are a constant source of security holes. The details are different for each language. Some allow access to the root directory. ,thers only allow access to the mail ser!er, but a resourceful hacker could mail the ser!ers username and password files to themsel!es. Aind out what scripting languages are being used and research the loopholes. It might also be a good idea to subscribe to a security newsgroup that discusses the language that is being tested. Conclusion +hether an Internet or intranet or e$tranet application is being tested, testing for the web can be more challenging than non8web applications. Ksers ha!e high e$pectations for web page quality. In many cases, the page is up for public relations, #ust as much as functionality, so the impression must be perfect.

21

Tes ting Terms

:pplication8 - single software product that mayor may not fully support a business function. :udit) This is an inspection2assessment acti!ity that !erifies compliance with plans, policies, and procedures, and ensures that resources are conser!ed. -udit is a staff function/ it ser!es as the *eyes and ears* of management Baseline8 - quantitati!e measure of the current le!el of performance. Benchmarking8 :omparing your company(s products, ser!ices, or processes

against best practices, or competiti!e practices, to help define superior performance of a product, ser!ice, or support process. Bene!its 3ealiDation Test8 - test or analysis conducted after an application is mo!ed into production to determine whether it is likely to meet the originating business case.

Black-7ox Testing8 - test technique that focuses on testing the functionality of the program, component, or application against its specifications without knowledge of how the system is constructed/ usually data or business process dri!en. Boundary ,alue :nalysis8 - data selection technique in which test data is chosen from the *boundaries* of the input or output domain classes, data structures, and procedure parameters. :hoices often include the actual minimum and ma$imum boundary !alues, the ma$imum !alue plus or minus one, and the minimum !alue plus or minus one. Bug8 - catchall term for all software defects or errors. Certi!ication8 -cceptance of software by an authori ed agent after the software has been !alidated by the agent or after its !alidity has been demonstrated to the agent. Check sheet8 - form used to record data as it is gathered. Checkpoint8 - formal re!iew of key pro#ect deli!erables. ,ne checkpoint is defined for each key pro#ect deli!erable, and !erification and !alidation must be done for each of these deli!erables that is produced. Condition Co%erage) - white8bo$ testing technique that measures the number of percentage of decision outcomes co!ered by the test cases designed. %OOP :ondition co!erage would indicate that e!ery possible outcome of each decision had been e$ecuted at least once during testing. Con!iguration Testing) Testing of an application on all supported hardware and software platforms. This may include !arious combinations of hardware

types, configuration settings, and software !ersions. Cost o! 0uality 'C40() Money spent abo!e and beyond e$pected production costs Elabor, materials, equipment> to ensure that the product the customer recei!es is a quality Edefect free> product The :ost of Juality includes pre!ention, appraisal, and correction or repair costs. Con%ersion Testing) =alidates the effecti!eness of data con!ersion processes, including field8to8field mapping, and data translation. $ecision Co%erage) - white8bo$ testing technique that measures the number of 8or percentage 8of decision directions e$ecuted by the test case designed. %OOP 'ecision co!erage would indicate that all decision directions had been e$ecuted at

least once during testing. -lternati!ely, each logical path through the program can be tested. ,ften, paths through the program are grouped into a finite set of classes, and one path from each class is tested $ecisionACondition Co%erage) white8bo$ testing technique that e$ecutes

possible combinations of condition outcomes in each decision. $e!ect8 ,perationally, it is useful to work with two definitions of a defect) E%> Arom the producer(s !iewpoint) a product requirement that has not been met or a product attribute possessed by a product or a function performed by a product that is not in the statement of requirements that define the product/ or E&> Arom the customer(s !iewpoint) anything that causes customer dissatisfaction, whether in the statement of requirements or not. $ri%er8 :ode that sets up an en!ironment and calls a module for test. $e!ect Tracking Tools8 Tools for documenting defects as they are found during testing and for tracking their status through to resolution. $esk Checking8 The most traditional means for analy ing a system to a program. The de!eloper of a system or program conducts desk checking. The process in!ol!es re!iewing the complete product to ensure that it is structurally sound and that the standards and requirements ha!e been met. This tool can also be used on artifacts created during analysis and design. <ntrance Criteria8 Required conditions and standards for work product quality that must be present or met for entry into the ne$t stage of the software

de!elopment process. <2ui%alence artitioning8 - test technique that utili es a subset of data that

is representati!e of a larger class. This is done in place of undertaking e$hausti!e testing of each !alue of the larger class of data. Aor e$ample, a business rule that indicates that a program should edit salaries within a gi!en range ET%O,OOO 8T%9,OOO> might ha!e ? equi!alence classes to test) 5ess than T%O,OOO Ein!alid> Cetween T%O,OOO and T%9,OOO E!alid>Freater than T%9,OOO Ein!alid>

<rror or $e!ect8 %. - discrepancy between a computed, obser!ed, or measured !alue or condition and the true, specified, or theoretically corrects !alue or condition. &. .uman action that results in software containing a fault Ee.g., omission or misinterpretation of user requirements in a software specification, incorrect

translation, or omission of a requirement in the design specification>. <rror Cuessing8 The data selection technique for picking !alues that seems likely to cause defects. This technique is based upon the theory that test cases and test data can be de!eloped based on the intuition and e$perience of the tester. <xhausti%e Testing8 B$ecuting the program through all possible combinations of !alues for program !ariables. B$it :riteria) Standards for work product quality, which block the promotion of incomplete or defecti!e work products to subsequent stages of the software de!elopment process. ;unctional Testing8 -pplication of test data deri!ed from the specified

functional requirements without regard to the final program structure. Inspection8 - formal assessment of a work product conducted by one or more qualified independent re!iewers to detect defects, !iolations of de!elopment standards, and other problems. Inspections in!ol!e authors only when specific questions

concerning deli!erables e$ist. -n inspection identifies defects, but does not attempt to correct them. -uthors take correcti!e actions and arrange follow8up re!iews as needed. Integration Testing8 This test begins after two or more programs or

application components ha!e been successfully unit tested. The de!elopment team to !alidate the technical quality or design of the application conducts it. It is the first le!el of testing which formally integrates a set of programs that communicate among themsel!es !iamessages or files Ea client and its ser!erEs>, a string of batch programs, or a set of on8line modules within a dialog or con!ersation>. &i!e Cycle Testing8 The process of !erifying the consistency, completeness, and correctness of software at each stage of the de!elopment lifecycle. er!ormance Test8 =alidates that both the on8line response time and batch run times meet the defined performance requirements. 0uality8 - product is a quality product if it is defect free. To the producer, a product is a quality product if it meets or conforms to the statement of requirements that defines

the product. This statement is usually shortened to) quality means meets requirements. Arom a customer(s perspecti!e, quality means *fit for use*.

0uality

:ssurance EJ->)

The

set

of

support

acti!ities

Eincluding

facilitation,

training, measurement, and analysis> needed to pro!ide adequate confidence that processes are established and continuously impro!ed to produce products that meet specifications and are fit for use. 0uality Control EJ:>) The process by which product quality is compared

with applicable standards, and the action taken when nonconformance is detected. Its focus is defect detection and remo!al. This is a line function/ that is, the performance of thesetasks is the responsibility of the people working within the process. 3eco%ery Test8 B!aluate the contingency features built into the application for handling interruptions and for returning to specific points in 5ife application processing cycle, including. 8checkpoints, backups, restores, and restarts. This test also assures that disasterreco!ery is possible. 3egression Testing8 Regression testing is the process of retesting software to detect errors that may ha!e been caused by program changes. The technique requires the use of a set of test cases that ha!e been de!eloped to test all of the software(s functional capabilities. #tress Testing8 This test sub#ects a system, or components of a system, to !arying en!ironmental conditions that delay normal e$pectations. Aor e$ample) high transaction !olume, large database si e or restart2reco!ery circumstances. The intention of stress testing is to identify constraints and to ensu7re that there are no performance problems,

#tructural Testing8 - testing method in which the test data are deri!ed solely from the program structure. #tu78 Special code segments 8that when in!oked by a code segment under testing sinuate the beha!ior of designed and specified modules not I yet

constructed.

#ystem test) 'uring this e!ent, the entire system is tested to !erify that all functional, information, structural and quality requirements ha!e been met. predetermined combination of tests is designed that, when e$ecuted successfully, satisfy management that the system meets specifications. System testing !erifies the functional quality of the system in addition to all e$ternal interfaces, manual procedures, restart and reco!ery, and human8computer interfaces. It also !erifies that interfaces between the application and open en!ironment work correctly, that N:5 functions correctly, and that the application functions appropriately with the 'atabase Management System, ,perations en!ironment, and any communications systems. Test :ase 8 - test case is a document that describes an input, action, or e!ent and an e$pected response, to determine if a feature of an application is working correctly. - test case should contain particulars such as test case identifier, test case name, ob#ecti!e, test conditions2setup, input data requirements, steps, and e$pected results. Test Case #peci!ication8 8-n indi!idual test condition, e$ecuted as part of a larger test contributes to the test(s ob#ecti!es. Test cases document the input, e$pected results, e$ecution conditions of a gi!en test item. Test cases are broken down into one or more detailed test scripts and test data conditions for e$ecution. Test $ata #et8 Set of input elements used in the testing process Test $esign #peci!ication8 - document that specifies the details of the test approach for a software feature or a combination of features and identifies the associated tests. Test Item8 - software item that is an ob#ect of testing. Test &og8 - chronological record of rele!ant details about the e$ecution of tests. Test lan8 - document describing the intended scope, approach, resources, and

schedule of testing acti!ities. It identifies test items, the features to be tested, the testing tasks, the personnel performing each task, and any risks requiring contingency planning. Test rocedure #peci!ication8 - document specifying a sequence of actions for

the e$ecution of a test.

Test #ummary 3eport - document that describes testing acti!ities and results and e!aluates the corresponding test items. Testing8 B$amination by manual or automated means of the beha!iour of a program by e$ecuting the program on sample data sets to !erify that it satisfies specified requirements or to !erify differences between e$pected and actual results. Test #cripts8 - tool that specifies an order of actions that should be performed during a test session. The script also contains e$pected results. Test scripts may be manually prepared using paper forms, or may be automated using capture2playback tools or other kinds of automated scripting tools. @sa7ility Test8 The purpose of this e!ent is to re!iew the application user interface and other human factors of the application with the people who will be using the application. This is to ensure that the design Elayout and sequence, etc.> enables the business functions to be e$ecuted as easily and intuiti!ely as possible. This re!iew includes assuring that the user interface adheres to documented Kser Interface standards, and should be conducted early in the design stage of de!elopment. Ideally, an application prototype is used to walk the client group through !arious business scenarios, although paper copies of screens, windows, menus, and reports can be used. @ser :cceptance Test8 Kser -cceptance Testing EK-T> is conducted to ensure that the system meets the needs of the organi ation and the end user2customer. It !alidates that the system will work as intended by the test in the real world, and is based on real world business scenarios, not system requirements. Bssentially, this test !alidates that the RIF.T system was built. ,alidation8 'etermination of the correctness of the final program or software produced from a de!elopment pro#ect with respect to the user needs and requirements. =alidation is usually accomplished by !erifying each stage of the software de!elopment life cycle. ,eri!ication8 I> The process of determining whether the products of a gi!en phase of the software de!elopment cycle fulfill the requirements established during the pre!ious phase.

II>

The act of re!iewing, inspecting, testing, checking, auditing, or otherwise establishing and documenting whether items, processes, ser!ices, or documents conform to specified requirements.

6alkthrough8 - manual analysis technique in which the module author describes the module(s structure and logic to an audience of colleagues. Techniques focus on error detection, not correction. +ill usually sue a formal set of standards or criteria as the basis of the re!iew. 6hite-7ox Testing8 - testing technique that assumes that the path of the logic in a program unit or component is known. +hite8bo$ testing usually consists of testing paths, branch by branch, to produce predictable results. This technique is usually used during tests e$ecuted by the de!elopment team, such as Knit or :omponent testing.

22

Technical 0uestions

1. 6hat is #o!tware Testing9 The process of e$ercising or e!aluating a system or system component by manual or automated means to !erify that it satisfies specified requirements or to identify differences between e$pected and actual results. 2. 6hat is the D D D urpose o! Testing9 To unco!er hidden errors To achie!e the ma$imum usability of the system To 'emonstrate e$pected performance of the system.

". 6hat types o! testing do testers per!orm9 Clack bo$ testing, +hite bo$ testing is the basic type of testing testers performs. -part from that they also perform a lot of tests like -d 8 .oc testing, :ookie Testing,

:BT

E:ustomer

B$perience

Test>,

:lient8Ser!er

Test,

:onfiguration

Tests,

:ompatibility testing, :onformance Testing ). 6hat is the 4utcome o! Testing9 - stable application, performing its task as e$pected. *. 6hat is the need !or testing9 The "rimary need is to match requirements get satisfied with the functionality and also to answer two questions D D +hether the system is doing what it supposes to doL +hether the system is not performing what it is not suppose to doL er!ormance testing9

+. 6hat are the entry criteria !or ;unctionality and ;unctional testing8

Aunctional Specification 2B3# 'C3#>2Kser Manual. -n integrated application, Stable for testing. -. 6hy do you go !or 6hite 7ox testingB when Black 7ox testing is a%aila7le9 - benchmark that certifies :ommercial ECusiness> aspects and also functional Etechnical> aspects is ob#ecti!es of black bo$ testing. .ere loops, structures, arrays, conditions, files, etc are !ery micro le!el but they arc Casement for any application, So +hite bo$ takes these things in Macro le!el and test these things /. 6hat are the entry criteria !or :utomation testing9 -pplication should be stable. :lear 'esign and Alow of the application is needed 5. 6hat is Baseline documentB Can you say any two9 - baseline document, which starts the understanding of the application before the tester, starts actual testing. Aunctional Specification and Cusiness Requirement 'ocument 11. 6hat are the 0ualities o! a Tester9 D D Should be perfectionist Should be tactful and diplomatic

D D D D

Should be inno!ati!e and creati!e Should be relentless Should possess negati!e thinking with good #udgment skills Should possess the attitude to break the system

11. Tell names o! some testing type which you learnt or experienced9 -ny 9 or ; types which are related to companies profile is good to say in the inter!iew, D D D D D D D D D D D -d 8 .oc testing :ookie Testing :BT E:ustomer B$perience Test> 'epth Test B!ent8'ri!en "erformance Testing Reco!ery testing Sanity Test Security Testing Smoke testing +eb Testing

12. 6hat exactly is ?euristic checklist approach !or unit testing9 It is method of achie!ing the most appropriate solution of se!eral found by alternati!e methods is selected at successi!e stages testing. The checklist "repared to "roceed is called .euristic checklist 1". :!ter completing testingB what would you deli%er to the client9 Test deli!erables D D D namely Test plan Test 'ata Test design 'ocuments

E:ondition2:ases> 'efect Reports Test :losure 'ocuments Test Metrics

1). 6hat is a Test Bed9 Cefore Starting the -ctual testing the element// which supports the testing acti!ity such as Test data, 'ata guide lines. -re collecti!ely called as test Ced.

1*. 6hat is a $ata Cuideline9 'ata Fuidelines are used to specify the data required to populate the test bed and prepare test scripts. It includes all data parameters that are required to test the conditions deri!ed from the requirement 2 specification The 'ocument, which supports in preparing test data are called 'ata guidelines 1+. 6hy do you go !or Test Bed9 +hen Test :ondition is e$ecuted its result should be compared to Test result Ee$pected result>, as Test data is needed for this here comes the role of test Ced where Test data is made ready.

1-. Can :utomation testing replace manual testing9 I! it soB how9 -utomated testing can ne!er replace manual Testing. -s these tools to Aollow FIF, principle of computer tools. -bsence of creati!ity and inno!ati!e thinking. Cut It speeds up the process. Aollow a clear "rocess, which can be re!iewed easily. Cetter Suited for Regression testing of Manually tested -pplication and "erformance testing.

1/. 6hat is the di!!erence 7etween 2uality and testing9 *Juality is gi!ing more cushions for user to use system with all its e$pected characteristics1. It is usually said as Nourney towards B$cellence. 0Testing is an acti!ity done to achie!e the quality1. 15. 6hy do we prepare test conditionB test casesB test script 'Be!ore #tarting Testing(9 These are test design document which are used to e$ecute the actual testing +ithout which e$ecution of testing is impossible, finally this e$ecution is going to find the bugs to be fi$ed so we ha!e prepare this documents.

21. Is it not waste o! time in preparing the test conditionB test case E Test #cript9 <o document prepared in any process is waste of rime, That too test design documents which plays !ital role in test e$ecution can ne!er be said waste of time as without which proper testing cannot be done. 21. ?ow do you go a7out testing o! 6e7 :pplication9 To approach a web application testing, the first attack on the application should be on its performance beha!ior as that is !ery important for a web application and then transfer of data between web ser!er and .front end ser!er, security ser!er and back end ser!er. 22. 6hat kind o! $ocument you need !or going !or a ;unctional testing9 Aunctional specification is the ultimate document, which e$presses all the

functionalities of the application and other documents like user manual and CRS are also need for functional testing. Fap analysis document will add !alue to understand e$pected and e$isting system. 2". Can the #ystem testing 7e done at any stage9 <o, .The system as a whole can be tested only if all modules arc integrated and all modules work correctly System testing should be done before K-T EKser -cceptance testing> and Cefore Knit Testing.

2). 6hat is Mutation testing E when can it 7e done9 Mutation testing is a powerful fault8based testing technique for unit le!el testing. Since it is a fault8based testing technique, it is aimed at testing and unco!ering some specific kinds of faults, namely simple syntactic changes to a program. Mutation testing is based on two assumptions) the competent programmer hypothesis and the coupling effect. The competent programmer hypothesis assumes that competent programmers turn to write nearly *correct* programs. The coupling effect stated that a set of test data that can unco!er all simple faults in a program is also capable of detecting more comple$ faults. Mutation testing in#ects faults into code to determine optimal test inputs.

2*. 6hy it is impossi7le to test a program completely9 +ith any software other than the smallest and simplest program, there are too many inputs, too many outputs, and too many path combinations to fully test. -lso, software specifications can be sub#ecti!e and be interpreted in different ways. Test :utomation8 2+. 6hat automating testing tools are you !amiliar with9 +inRunner and 5oadRunner 2-. 6hat is the use o! automating testing tools in any .o79 The automation testing tools are used for Regression and "erformance testing. 2/. $escri7e some pro7lem with automating testing tool. Se!eral problems are encountered while working with test automation tools like,

a. b. c. d. e.

Tools 5imitations for ,b#ect 'etections Tools :onfiguration 2 'eployment in !arious Bn!ironments Tools "recision 2 'efault Skeleton Script Issues like window synchroni ation issues etc. Tools bugs with respect to e$ception handling. Tools abnormal polymorphism in beha!ior like sometimes it works but sometimes not for the same application 2 same script2same en!ironment etc.

25. ?ow test automation is planned9 "lanning is the most important task in Test -utomation. Test -utomation "lan should co!er the following task items, a. b. c. d. e. f. Tool Selection) Type of Test -utomation B$pected ERegression 2 "erformance etc.> Tool B!aluation) Tool -!ailability 2 Tool 5icense -!ailability 2 Tool 5icense 5imitations. Tool :ost Bstimation =s "ro#ect :ost Bstimation Statistics for Testing. Resource Requirements =s -!ailability Study. Time -!ailability =s Time Bstimations :alculations and 'efinitions. "roduction Requirements -nalysis Results :onsideration with respect to Aactors like 5oad8"erformance 2 Aunctionality B$pected 2 Scalability etc.

g. h. i. #.

Test -utomation "rocess 'efinitions including Standard to be followed while performing Test -utomation. Test -utomation Scope 'efinition. -utomation Risk -nalysis and planning to o!ercome if defined Risks Bmerge in the -utomation "rocess. Reference 'ocument Requirement as "erquisites for Test -utomation.

"1. Can test automation impro%e test e!!ecti%eness9 Res, 'efinitely Test -utomation plays a !ital role in impro!ing Test Bffecti!eness in !arious ways like, a. b. c. Reduction in Slippage caused due to human errors. ,b#ect 2 ,b#ect "roperties 5e!el KI =erifications. =irtual 5oad 2 Ksers usage in 5oad2"erformance Testing wherein its not possible to use so many resources physically performing test and get so accurate results. d. "rWcised Time :alculations. e. -nd many moreX "1. 6hat is data - dri%en automation9 'ata 'ri!en -utomation is the most important part of test automation where the requirement is to e$ecute the same test cases for different set of test input data so that test can e$ecuted for pre8defined iterations with different set of test input data for each iteration. "2. 6hat are the main attri7utes o! test automation9 .ere are some of the attributes of test automation that can be measured, Maintaina7ility 'efinition) The effort needed to update the test automation suites for each new release. "ossible measurements) The possible measurements can be e.g. the a!erage work effort in hours to update a test suite. 3elia7ility 'efinition) The accuracy and repeatability of your test automation. "ossible measurements) <umber of times a test failed due to defects in the tests or in the test scripts. ;lexi7ility 'efinition) The ease of working with all the different kinds of automation test ware. "ossible measurements) The time and effort needed to identify, locate, restore, combine and e$ecute the different test automation test ware. <!!iciency 'efinition) The total cost related to the effort needed for the automation. "ossible measurements) Monitoring o!er time the total cost of automated testing, i.e. resources, material, etc. orta7ility 'efinition) The ability of the automated test to run on different en!ironments.

"ossible measurements) The effort and time needed to set8up and run test automation in a new en!ironment.

3o7ustness 'efinition) The effecti!eness of automation on an unstable or rapidly changing system. "ossible measurements) <umber of tests failed due to une$pected e!ents. @sa7ility 'efinition) The e$tent to which automation can be used by different types of users E'e!elopers, non8technical people or other users etc.,> "ossible measurements) The time needed to train users to become confident and producti!e with test automation. "". $oes automation replace manual testing9 +e cannot actually replace manual testing %OOP using -utomation but yes definitely it can replace almost 9OP of the manual test efforts if the automation is done efficiently. "). ?ow a tool !or test automation is chosen9 Celow are factors to be considered while choosing Test -utomation Tool, a. b. c. d. e. f. Test Type B$pected. EB.g. Regression Testing 2 Aunctional Testing 2 "erformance85oad Testing> Tool :ost =s "ro#ect Testing Cudget Bstimation. "rotocol Support by Tool =s. -pplication 'esigned "rotocol. Tools 5imitations =s -pplication Test Requirements .2+, S2+ I "latform Support of Tool =s -pplication test Scope for these attributes. Tool 5icense 5imitations 2 -!ailability =s Test Requirements.ETools Scalability>

"*. ?ow one will e%aluate the tool !or test automation9 +hene!er a Tool has to be e!aluated one need to go through few important !erifications 2 !alidations of the tool like, a. b. c. d. e. f. "latform Support from the Tool. "rotocols 2 Technologies Support. Tool :ost Tool Type with its Aeatures =s ,ur Requirements -nalysis. Tool Ksage :omparisons with other similar a!ailable tools in market.

Tool3s :ompatibility with our -pplication -rchitecture and 'e!elopment Technologies. g. Tool :onfiguration I 'eployment Requirements. h. Tools 5imitations -nalysis.

"+. 6hat are main 7ene!its o! test automation9 The main benefits of Test -utomation are, a. b. c. d. Test -utomation Sa!es Ma#or Testing Time. Sa!es Resources E.uman 2 .2w 2 S2+ resources> Reduction in =erification Slippages cased due to human errors. ,b#ect "roperties 5e!el =erifications can be done which is difficult manually. e. =irtual 5oad 2 Ksers Feneration for load testing which is not worth doing manually as it needs lots of resources and also it might not gi!e that precise results which can be achie!ed using a -utomation Tool. f. Regression Testing "urposes. g. Aor 'ata 'ri!en Testing. "-. 6hat could go wrong with test automation9 +hile using Test -utomation there are !arious factors that can affect the testing process like, a. b. Tool3s 5imitations might result in -pplication 'efects. -utomation Tool3s abnormal beha!ior like Scalability =ariations due to memory !iolations might be considered as -pplications memory !iolation in hea!y load tests. c. Bn!ironment Settings Required for Tool Ee.g. Na!a8:,RC- required N'6 to be present in System> causes -pplication to show up Cugs which are #ust due to the N'6 installation in System which I had e$perienced myself as on un8installation of N'6 and Na!a8-ddins my application works fine. "/. ?ow are the testing acti%ities descri7ed9 The basic Testing acti!ities are as follows) a. b. c. d. e. f. g. h. Test "lanning E"re8Requisite) Fet -dequate 'ocuments of the "ro#ect to test> Test :ases E"re8Requisite) Fet -dequate 'ocuments of the "ro#ect to test> :ursor Test E- =ery Casic Test to make sure that all screens are coming and application is ready for test or to automate> Manual Testing Test -utomation E"ro!ided if the product had reached Stability enough to be automated>. Cug Tracking I Cug Reporting. -nalysis of the Test and Test Report :reation. If Cug Ai$ing :ycle repeats then Steps c8h repeats.

"5. 6hat testing acti%ities one may want to automate9 -nything, which is repeated, should be automated if possible. Thus the following testing acti!ities can be automated,

a. b. c. d. e.

Test :ase "reparation Tests like :ursor, Regression, Aunctional I 5oad 2 "erformance testing. Test Report Feneration. Test Status2Results <otifications. Cug Tracking System. Btc.

)1. $escri7e common pro7lems o! test automation9 In Test -utomation we come across se!eral problems, out of which I would like to highlight few as gi!en below, a. b. c. d. e. f. -utomation Script Maintenance, which becomes tough if product gets through frequent changes. -utomation Tool3s 5imitations for ob#ects Recogni ing. -utomation Tool3s Third "art Integration 5imitations. -utomation Tool3s abnormal beha!ior due to its Scalability Issues. 'ue to Tool3s 'efects, +e might assume its -pplication 'efect and consider any issue as -pplication Cug. Bn!ironmental Settings and -"I3s 2 -ddins Required by Tool to make it compatible to work with Speciali ed Bn!ironments like N-=-8:,RCcreates N-=- Bn!ironmental Issues for the -pplication to work. EB.g. +inRunner U.O9 Na!a8Support Bn!ironmental =ariables :reates -pplication g. Knder Test Oto malfunction> There are many issues, which we come across while actual automation.

)1. 6hat are the types o! scripting techni2ues !or test automation 9 Scripting Technique) how to structure automated test scripts for ma$imum benefit and Minimum impact of software changes, scripting issues, scripting approaches) linear, Shared, data8dri!en and programmed, script pre8processing, minimi ing the impact of Software changes on test scripts. The ma#or ones used are, a. b. c. d. e. 'ata8'ri!en Scripting :entrali ed -pplication Specific 2 Feneric :ompiled Modules 2 5ibrary 'e!elopment. "arent :hild Scripting. Techniques to Fenerali e the Scripts. Increasing the factor of Reusability of the Script.

)2. 6hat are principles o! good testing scripts !or automation9

The ma#or principles of good testing script for -utomation are, a. b. c. d. e. f. g. h. -utomation Scripts should be reusable. :oding Standards should be followed for Scripting, which makes Script Kpdating, Knderstanding, 'ebugging easier. Scripts should be Bn!ironment, data Independent as much as possible which can be achie!ed using parameteri ation. Script should be generali ed. Scripts should be modular. Repeated Tasks should be kept in Aunctions while scripting to a!oid code repeat, comple$ity and make script easy for debugging. Script should be readable and appropriate comments should be written for each line 2 section of script. Script .eader should contain script de!eloper name, script updated date, script en!ironmental requirements, scripted en!ironmental details, script pre8requisites from application side, script description in brief, script contents, script scope etc. )". 6hat tools are a%aila7le !or support o! testing during so!tware de%elopment li!e cycle9 Test 'irector for Test Management, Cug illa for Cug Tracking and <otification etc are the tools for Support of Testing. )). Can the acti%ities o! test case design 7e automated9 Res, Test 'irector is one of such tool, which has the feature of Test :ase 'esign and e$ecution. )*. 6hat are the limitations o! automating so!tware testing9 If one talk about limitations of automating software testing, then to mention few, a. b. -utomation <eeds lots of time in the initial stage of automation. B!ery tool will ha!e its own limitations with respect to protocol support, technologies supported, ob#ect recognition, platform supported etc due to which not %OOP of the -pplication can be automation because there is always something limited to the tool which we ha!e to o!ercome with RI'.

c.

Tool3s Memory Ktili ation is also one the important factor which blocks the application3s memory resources and creates problems to application in few cases like Na!a -pplications etc.

Comments

&OOH.%%.%9 +ed l :ategory) <one l :omments E%%> Trackbacks EO> l top

Manul Testing 6indly sedn full details about Testing Comment is pending appro%al. :omment is pending administrator(s appro!al. "l send me testing notes 4nly the administrator may %iew. ,nly the administrator may read this comment. Comment is pending appro%al. :omment is pending administrator(s appro!al. Comment is pending appro%al. :omment is pending administrator(s appro!al. Comment is pending appro%al. :omment is pending administrator(s appro!al. Comment is pending appro%al. :omment is pending administrator(s appro!al. Comment is pending appro%al. :omment is pending administrator(s appro!al. Comment is pending appro%al. :omment is pending administrator(s appro!al. 4nly the administrator may %iew. ,nly the administrator may read this comment.
&O%?.O?.%? +ed l . l Bdit &O%&.OU.%H +ed l . l Bdit &O%&.O;.&H Thu l . l Bdit &O%&.O&.OU Tue l . l Bdit &OOH.%%.?O Sun l Sureshkumar. KR5 l Bdit

&O%%.OH.O& Tue l . l Bdit &O%%.%O.&U Thu l Shail. KR5 l Bdit

&O%&.O7.&? Mon l . l Bdit

&O%&.OU.O? Tue l . l Bdit

&O%?.O&.%7 Thu l . l Bdit

&O%?.OH.&U Tue l . l Bdit

ost a comment
<ame)

Title)
No title

B8mail address)

KR5)

Cody)

Track7acks

"ri!ate comment

Bdit password)

Send

Trackbacks KR5 http)22softwaretesting.blog%&;.fc&.com2tb.php2?8??Ub&97& Kse trackback on this entry.

l .,MB l Aundamental Test "rocessY

You might also like