testing concepts ebook

8/14/2019 Testing Concepts eBook

1/28

Software Testing Concepts eBook from www.OneStopTesting.com

Worlds Largest Portal on Software Testing Information & Jobs - http://www.OneStopTesting.comJoin Software Testing Community at

http://groups.yahoo.com/group/OneStopTesting/ Over 5,000 Testing Interview Questions at

http://www.CoolInterview.com

Software Testing ConceptsFree Study Material from

www.OneStopTesting.com


2/28





Testing Concepts

Testing is a process used to help identify the correctness, completeness and quality ofdeveloped computer software. With that in mind, testing can never completely establish thecorrectness of computer software.

There are many approaches to software testing, but effective testing of complex products is

essentially a process of investigation, not merely a matter of creating and following rote

procedure. One definition of testing is "the process of questioning a product in order toevaluate it", where the "questions" are things the tester tries to do with the product, and the

product answers with its behavior in reaction to the probing of the tester. Although most of

the intellectual processes of testing are nearly identical to that of review or inspection, theword testing is connoted to mean the dynamic analysis of the productputting the productthrough its paces.

The quality of the application can and normally does vary widely from system to system butsome of the common quality attributes include reliability, stability, portability, maintainability

and usability. Refer to the ISO standard ISO 9126 for a more complete list of attributes andcriteria.

Testing helps is Verifying and Validating if the Software is working as it is intended to beworking. Thins involves using Static and Dynamic methodologies to Test the application.

Because of the fallibility of its human designers and its own abstract, complex nature,software development must be accompanied by quality assurance activities. It is not unusual

for developers to spend 40% of the total project time on testing. For life-critical software (e.g.

flight control, reactor monitoring), testing can cost 3 to 5 times as much as all other activitiescombined. The destructive nature of testing requires that the developer discard preconceivednotions of the correctness of his/her developed software.


3/28





Software Testing Fundamentals

Testing objectives include

1. Testing is a process of executing a program with the intent of finding an error.2. A good test case is one that has a high probability of finding an as yet undiscovered error.

3. A successful test is one that uncovers an as yet undiscovered error.

Testing should systematically uncover different classes of errors in a minimum amount of timeand with a minimum amount of effort. A secondary benefit of testing is that it demonstratesthat the software appears to be working as stated in the specifications. The data collectedthrough testing can also provide an indication of the software's reliability and quality. But,

testing cannot show the absence of defect -- it can only show that software defects arepresent.


4/28





Testing Start Process

Testing is sometimes incorrectly thought as an after-the-fact activity; performed after

programming is done for a product. Instead, testing should be performed at every

development stage of the product. Test data sets must be derived and their correctness andconsistency should be monitored throughout the development process.

If we divide the lifecycle of software development into Requirements Analysis, Design,

Programming/Construction and Operation and Maintenance, then testing shouldaccompany each of the above phases. If testing is isolated as a single phase late in the cycle,errors in the problem statement or design may incur exorbitant costs. Not only must the

original error be corrected, but the entire structure built upon it must also be changed.

Therefore, testing should not be isolated as an inspection activity. Rather testing should beinvolved throughout the SDLC in order to bring out a quality product.

Testing Activities in Each PhaseThe following testing activities should be performed during the phases:

1. Requirements Analysis- Determine correctness

- Generate functional test data.

2. Design- Determine correctness and consistency

- Generate structural and functional test data.

3. Programming/Construction- Determine correctness and consistency

- Generate structural and functional test data

- Apply test data- Refine test data

4. Operation and Maintenance- Retest


5/28





Requirements Analysis

The following test activities should be performed during this stage:

1.1 Invest in analysis at the beginning of the project - Having a clear, concise and formalstatement of the requirements facilitates programming, communication, error analysisand test data generation.

The requirements statement should record the following information and decisions:

a. Program function - What the program must do?

b. The form, format, data types and units for input.

c. The form, format, data types and units for output.

d. How exceptions, errors and deviations are to be handled.

e. For scientific computations, the numerical method or at least the required accuracy of thesolution.

f. The hardware/software environment required or assumed (e.g. the machine, the operatingsystem, and the implementation language).

Deciding the above issues is one of the activities related to testing that should be performedduring this stage.

1.2 Start developing the test set at the requirements analysis phase - Data should be

generated that can be used to determine whether the requirements have been met. To dothis, the input domain should be partitioned into classes of values that the program will treat

in a similar manner and for each class a representative element should be included in the testdata.

In addition, following should also be included in the data set:

(1) boundary values

(2) any non-extreme input values that would require special handling.


6/28





The output domain should be treated similarly.

Invalid input requires the same analysis as valid input.

1.3 The correctness, consistency and completeness of the requirements should also beanalyzed - Consider whether the correct problem is being solved, check for conflicts and

inconsistencies among the requirements and consider the possibility of missing cases.

Design

The design document aids in programming, communication, and error analysis and test data

generation. The requirements statement and the design document should together give the

problem and the organization of the solution i.e. what the program will do and how it will bedone.

The design document should contain:

Principal data structures. Functions, algorithms, heuristics or special techniques used for processing. The program organization, how it will be modularized and categorized into external

and internal interfaces. Any additional information.

Here the testing activities should consist of:

- Analysis of design to check its completeness and consistency - the total process should beanalyzed to determine that no steps or special cases have been overlooked. Internalinterfaces, I/O handling and data structures should specially be checked for inconsistencies.

- Analysis of design to check whether it satisfies the requirements - check whether both

requirements and design document contain the same form, format, units used for input and

output and also that all functions listed in the requirement document have been included inthe design document. Selected test data which is generated during the requirements analysis

phase should be manually simulated to determine whether the design will yield the expected

values.- Generation of test data based on the design - The tests generated should cover thestructure as well as the internal functions of the design like the data structures, algorithm,

functions, heuristics and general program structure etc. Re-examination and refinement ofthe test data set generated at the requirements analysis phase.


7/28





The first two steps should also be performed by some colleague and not only thedesigner/developer.

Programming/Construction

Here the main testing points are:

- Check the code for consistency with design - the areas to check include modular structure,

module interfaces, data structures, functions, algorithms and I/O handling.

- Perform the Testing process in an organized and systematic manner with test runs dated,

annotated and saved. A plan or schedule can be used as a checklist to help the programmerorganize testing efforts. If errors are found and changes made to the program, all tests

involving the erroneous segment (including those which resulted in success previously) mustbe rerun and recorded.

- Asks some colleague for assistance - Some independent party, other than the programmerof the specific part of the code, should analyze the development product at each phase. The

programmer should explain the product to the party who will then question the logic andsearch for errors with a checklist to guide the search. This is needed to locate errors the

programmer has overlooked.

- Use available tools - the programmer should be familiar with various compilers and

interpreters available on the system for the implementation language being used becausethey differ in their error analysis and code generation capabilities.

- Apply Stress to the Program - Testing should exercise and stress the program structure, the

data structures, the internal functions and the externally visible functions or functionality.Both valid and invalid data should be included in the test set.

- Test one at a time - Pieces of code, individual modules and small collections ofmodules should be exercised separately before they are integrated into the

total program, one by one. Errors are easier to isolate when the no. of potentialinteractions should be kept small. Instrumentation-insertion of some code intothe program solely to measure various program characteristics can be useful

here. A tester should perform array bound checks, check loop control variables,determine whether key data values are within permissible ranges, traceprogram execution, and count the no. of times a group of statements isexecuted.


8/28





- Measure testing coverage/When should testing stop? - If errors are still foundevery time the program is executed, testing should continue. Because errors tend

to cluster, modules appearing particularly error-prone require specialscrutiny.

The metrics used to measure testing thoroughness include statement testing(whether each statement in the program has been executed at least once), branchtesting (whether each exit from each branch has been executed at least once) and

path testing (whether all logical paths, which may involve repeated execution ofvarious segments, have been executed at least once). Statement testing is thecoverage metric most frequently used as it is relatively simple to implement.

The amount of testing depends on the cost of an error. Critical programs orfunctions require more thorough testing than the less significant functions.

Operations and Maintenance

Corrections, modifications and extensions are bound to occur even for small programs and

testing is required every time there is a change. Testing during maintenance is termed

regression testing. The test set, the test plan, and the test results for the original programshould exist. Modifications must be made to accommodate the program changes, and then all

portions of the program affected by the modifications must be re-tested. After regression

testing is complete, the program and test documentation must be updated to reflect the

changes.


9/28





Testing Stop Process

This can be difficult to determine. Many modern software applications are so complex, and

run in such as interdependent environment, that complete testing can never be done. "Whento stop testing" is one of the most difficult questions to a test engineer. Common factors indeciding when to stop are:

Deadlines ( release deadlines,testing deadlines.) Test cases completed with certain percentages passed Test budget depleted Coverage of code/functionality/requirements reaches a specified point The rate at which Bugs can be found is too small Beta or Alpha Testing period ends The risk in the project is under acceptable limit.

Practically, we feel that the decision of stopping testing is based on the level of the riskacceptable to the management. As testing is a never ending process we can never assumethat 100 % testing has been done, we can only minimize the risk of shipping the product to

client with X testing done. The risk can be measured by Risk analysis but for small duration

/ low budget / low resources project, risk can be deduced by simply: -

Measuring Test Coverage. Number of test cycles. Number of high priority bugs.

The Software Assurance Technology Center (SATC) in the Systems Reliability and SafetyOffice at Goddard Space Flight Center (GSFC) is investigating the use of software error data

as an indicator of testing status. Items of interest for determining the status of testing includeprojections of the number of errors remaining in the software and the expected amount of

time to find some percentage of the remaining errors. To project the number of errors

remaining in software, one needs an estimate of the total number of errors in the software atthe start of testing and a count of the errors found and corrected throughout testing. There

are a number of models that reasonably fit the rate at which errors are found in software, themost commonly used is referred to in this paper as the Musa model. This model is not easilyapplicable at GSFC, however, due to the availability and the quality of the error data.

At GSFC, useful error data is not easy to obtain for projects not in the Software Engineering

Laboratory. Of the projects studied by the SATC, only a few had an organized accountingscheme for tracking errors, but they often did not have a consistent format for recordingerrors. Some projects record errors that were found but did not record any information about

resources applied to testing. The error data frequently contained the date of entry of the errordata rather than the actual date of error discovery.


10/28





In order to use traditional models such as the Musa model for estimating the cumulativenumber of errors, one needs fairly precise data on the time of discovery of errors and the

level of resources applied to testing. Real world software projects are generally not veryaccommodating when it comes to either accuracy or completeness of error data.

The models developed by the SATC to perform trending and prediction on error data attemptto compensate for these shortcomings in the quantity and availability of project data.

In order to compensate for the quality of the error data, the SATC developed a software errortrending models using two techniques, each based on the basic Musa model, but with theconstant in the exponential term replaced by a function of time that describes the 'intensity'

of the testing effort. The shape and the parameters for this function can be estimated using

measures such as CPU time or staff hours devoted to testing. The first technique involvesfitting cumulative error data to the modified Musa model using a least squares fit that is

based on gradient methods. This technique requires data on errors found and the number ofstaff hours devoted to testing each week of the testing activity. The second technique uses a

Kalman filter to estimate both the total number of errors in the software and the level oftesting being performed. This technique requires error data and initial estimates of the totalnumber of errors and the initial amount of effort applied to testing.

The SATC has currently examined and modeled error data from a limited number of projects.Generally, only the date on which an error was entered into the error tracking system was

available, not the date of discovery of the error. No useful data was available on human orcomputer resources expended for testing. What is needed for the most accurate model is the

total time expended for testing, even if the times are approximate. Using the sum of reported

times to find/fix individual errors did not produce any reasonable correlation with the resourcefunction required. Some indirect attempts to estimate resource usage, however, led to some

very good fits. On one project errors were reported along with the name of the person thatfound the error. Resource usage for testing was estimated as follows: A person was estimated

to be working on the testing effort over a period beginning with the first error that theyreported and ending with the last error that they reported. The percentage of time that each

person worked during that period was assumed to be an unknown constant that did not differ

from person to person. Using this technique led to a resource curve that closely resembledthe Rayleigh curve (Figure 1).


11/28





Testing Stop Process

On most of the projects, there was good conformity between the trend model and the

reported error data. More importantly, estimates of the total number of errors and the errordiscovery parameter, made fairly early in the testing activity, seemed to provide reliableindicators of the total number of errors actually found and the time it took to find futureerrors. Figures 2 shows the relationship between reported errors and the SATC trend model

for one project. The graph represents data available at the conclusion of the project. Thisclose fit was also found on other projects when sufficient data was available.

On another project, different estimates of the total number of errors were obtained whenestimates were made over different testing time intervals. That is, there was inconsistentagreement between the trend model and the error data over different time intervals.

Through subsequent discussion with the project manager it was learned that the rate of error

reporting by the project went from approximately 100% during integration testing to 40%

during acceptance testing.

Furthermore, there was a significant amount of code rework, and testing of the software

involved a sequential strategy of completely testing a single functional area before proceedingto test the next functional area of the code. Thus, the instability of the estimates of the total

errors was a useful indicator of the fact that there was a significant change in either the

project's testing and reporting process. Figure 3 shows the results for this project. Note thechange in slope of the reported number of errors occurring around 150 days. The data curve

flattens at the right end of the curve due to a pause in testing, rather than a lack of errordetection. This project is still undergoing testing. If error data is broken into the distinct

testing phases of the life cycle (e.g., unit, system, integration), the projected error curveusing the SATC model closely fits the rate at which errors are found in each phase.

Some points need to be clarified about the SATC error trend model. The formulation of the

SATC equation is the direct result of assuming that at any instant of time, the rate ofdiscovery of errors is proportional to the number of errors remaining in the software and to

the resources applied to finding errors. Additional conditions needed in order for the SATCtrending model to be a valid are:

1. The code being tested is not being substantially altered during the testing process,especially through the addition or rework of large amounts of code.

2. All errors found are reported.3. All of the software is tested, and testing of the software is uniform throughout the time of

the testing activity.

Condition 1 is present to ensure that the total number of errors is a relatively stable numberthroughout the testing activity.


12/28





Conditions 2 and 3 are present to ensure that the estimate of the total number of errors is infact an estimate of the total errors present in the software at the start of testing - no new

errors are introduced during testing.

If testing is not "uniform" then the rate of error discovery will not necessarily be proportional

to the number of errors remaining in the software and so the equation will not be an

appropriate model for errors found. No attempt will be made here to make precise themeaning of the word "uniform".

The SATC developed this model rather than using the standard Musa model because it seemsless sensitive to data inaccuracy and provides for non-constant testing resource levels. An

additional benefit from this work is the application of the Rayleigh curve for estimating

resource usage. Future work by the SATC will continue to seek a practical balance betweenavailable trend analysis theory and the constraints imposed by the limited accuracy and

availability of data from real-world projects.

Test Strategy

How we plan to cover the product so as to develop an adequate assessment of quality.

A good test strategy is:

SpecificPractical

Justified

The purpose of a test strategy is to clarify the major tasks and challenges of the test project.

Test Approach and Test Architecture are other terms commonly used to describe what Imcalling test strategy.

Example of a poorly stated (and probably poorly conceived) test strategy:

"We will use black box testing, cause-effect graphing, boundary testing, and white box testingto test this product against its specification."


13/28





Contents:

Creating Test Strategy Defining Test Strategy Requirements in Test Strategy Key points to remember


14/28





Risk Analysis:

A risk is a potential for loss or damage to an Organization from materialized threats. Risk

Analysis attempts to identify all the risks and then quantify the severity of the risks.A threatas we have seen is a possible damaging event. If it occurs, it exploits vulnerability in thesecurity of a computer based system.

Contents:

Risk Identification Schedule Risk Risk Assessment Risk Assessment in Public Health Risk Assessment in Auditing Criticisms of quantitative risk assessment Risk Management Create a risk management plan Implementation Review and evaluation of the plan Limitations


15/28





Test Metrics

Test metrics accomplish in analyzing the current level of maturity in testing and give a

projection on how to go about testing activities by allowing us to set goals and predict futuretrends.

Metrics Types Identifying Test Metrics Gathering Test Metrics Analyzing Test Metrics Applying Test Metrics Business Value of Test Metrics GQM Paradigm Summary


16/28





Release Life Cycle

A software release is the distribution, whether public or private, of an initial or new and

upgraded version of a computer software product. Each time a software program or system ischanged, the software engineers and company doing the work decide on how to distribute the

program or system, or changes to that program or system. Software patches are one method

of distributing the changes, as are downloads and compact discs. [ Ref:http://www.onestoptesting.com/release-life-cycle/software-release-stages.asp ]

Software release stages End of life


17/28





Proof of Concept & Interoperability Testing

Interoperability testing has become a requirement for companies that deploy multi-vendor

networks. To satisfy this requirement, network and storage providers and managers havethree options.

1. Set up an interoperability lab, an expensive and time-consuming project.2. Use a third-party interoperability lab, such as ISOCORE or the University of New

Hampshire.3. Create a proof-of-concept lab, such as the labs at Cisco or Spirent Communications.

These labs typically connect the devices with a copper or fiber-optic patch cable and run the tests.

Such testing reflects a best-case scenario that is useful for base-line interoperability testing but

doesnt represent how the devices will interoperate in an actual network.

It is analogous to testing the auto-pilot system of an airplane to see if it could land the plane

in ideal weather conditions. While the test proves the plane can land itself on a perfect day, it

is not a predictor of how the system will behave in wide range of weather conditions underwhich a plane will have to operate.

Sometimes spools of fiber are used to create the delay found in wide area networks. While

this is an improvement over patch cables, there are three major limitations to proof ofconcept and interoperability testing with spools of fiber:

1. Spools of fiber cannot provide dynamic tests. The tests must be manually stopped andrestarted to change out the spool of fiber for one with a different length.

2. Spools of fiber are expensive and impractical. Imagine the cost associated with movingan 50,000 km spool of fiber to another lab.

3. Spools of fiber only provide delay. They do not address the various other impairments thatexist in a network.

It is as if we improved our auto-pilot system testing to include fixed amounts of wind from a

single direction. Factors such as fog, rain, snow and wind sheers are still ignored in thetesting. Weather conditions are dynamic and multifaceted. Testing under a single condition is

not a realistic test. As with weather, so it is with networks. Impairments in real networks donot limit themselves to a single issue.

Anue Network Emulators allow you to land your plane under any combination of adverseweather conditions.


18/28





Extreme Programming

Extreme Programming is a discipline of software development based on values of simplicity,

communication, feedback, and courage. It works by bringing the whole team together in thepresence of simple practices, with enough feedback to enable the team to see where they areand to tune the practices to their unique situation.

Whole Team

All the contributors to an XP project sit together, members of one team. This team must include a

business representative -- the "Customer" -- who provides the requirements, sets the priorities, and

steers the project. It's best if the Customer or one of her aides is a real end user who knows the

domain and what is needed. The team will of course have programmers. The team may includetesters, who help the Customer define the customer acceptance tests. Analysts may serve as helpers

to the Customer, helping to define the requirements. There is commonly a coach, who helps the

team keep on track, and facilitates the process. There may be a manager, providing resources,

handling external communication, coordinating activities. None of these roles is necessarily the

exclusive property of just one individual: Everyone on an XP team contributes in any way that

they can. The best teams have no specialists, only general contributors with special skills.

Planning Game

XP planning addresses two key questions in software development: predicting what will be

accomplished by the due date, and determining what to do next. The emphasis is on steeringthe project -- which is quite straightforward -- rather than on exact prediction of what will be

needed and how long it will take -- which is quite difficult. There are two key planning steps inXP, addressing these two questions:

Release Planning is a practice where the Customer presents the desired features to the

programmers, and the programmers estimate their difficulty. With the cost estimates in hand,

and with knowledge of the importance of the features, the Customer lays out a plan for theproject. Initial release plans are necessarily imprecise: neither the priorities nor the estimatesare truly solid, and until the team begins to work, we won't know just how fast they will go.

Even the first release plan is accurate enough for decision making, however, and XP teamsrevise the release plan regularly.


19/28





Iteration Planning is the practice whereby the team is given direction every couple of weeks.XP teams build software in two-week "iterations", delivering running useful software at the

end of each iteration. During Iteration Planning, the Customer presents the features desiredfor the next two weeks. The programmers break them down into tasks, and estimate theircost (at a finer level of detail than in Release Planning). Based on the amount of workaccomplished in the previous iteration, the team signs up for what will be undertaken in the

current iteration.

These planning steps are very simple, yet they provide very good information and excellent

steering control in the hands of the Customer. Every couple of weeks, the amount of progress is

entirely visible. There is no "ninety percent done" in XP: a feature story was completed, or it was

not. This focus on visibility results in a nice little paradox: on the one hand, with so much

visibility, the Customer is in a position to cancel the project if progress is not sufficient. On the

other hand, progress is so visible, and the ability to decide what will be done next is so complete,that XP projects tend to deliver more of what is needed, with less pressure and stress.

Customer Tests

As part of presenting each desired feature, the XP Customer defines one or more automated

acceptance tests to show that the feature is working. The team builds these tests and usesthem to prove to themselves, and to the customer, that the feature is implemented correctly.

Automation is important because in the press of time, manual tests are skipped. That's liketurning off your lights when the night gets darkest.

The best XP teams treat their customer tests the same way they do programmer tests: oncethe test runs, the team keeps it running correctly thereafter. This means that the system onlyimproves, always notching forward, never backsliding.

Small Releases

XP teams practice small releases in two important ways:

First, the team releases running, tested software, delivering business value chosen by the

Customer, every iteration. The Customer can use this software for any purpose, whether

evaluation or even release to end users (highly recommended). The most important aspect isthat the software is visible, and given to the customer, at the end of every iteration. Thiskeeps everything open and tangible.


20/28





Second, XP teams release to their end users frequently as well. XP Web projects release as

often as daily, in house projects monthly or more frequently. Even shrink-wrapped productsare shipped as often as quarterly.

It may seem impossible to create good versions this often, but XP teams all over are doing it

all the time.

Simple Design

XP teams build software to a simple design. They start simple, and through programmer

testing and design improvement, they keep it that way. An XP team keeps the design exactly

suited for the current functionality of the system. There is no wasted motion, and the

software is always ready for what's next.

Design in XP is not a one-time thing, or an up-front thing, it is an all-the-time thing. There

are design steps in release planning and iteration planning, plus teams engage in quick designsessions and design revisions through refactoring, through the course of the entire project. In

an incremental, iterative process like Extreme Programming, good design is essential. That'swhy there is so much focus on design throughout the course of the entire development.

Pair Programming

All production software in XP is built by two programmers, sitting side by side, at the same

machine. This practice ensures that all production code is reviewed by at least one otherprogrammer, and results in better design, better testing, and better code.

Some programmers object to pair programming without ever trying it. It does take somepractice to do well, and you need to do it well for a few weeks to see the results. Ninetypercent of programmers who learn pair programming prefer it, so we highly recommend it toall teams.

Pairing, in addition to providing better code and tests, also serves to communicate knowledge

throughout the team. As pairs switch, everyone gets the benefits of everyone's specializedknowledge. Programmers learn, their skills improve, they become more valuable to the teamand to the company. Pairing, even on its own outside of XP, is a big win for everyone.


21/28





Test-Driven Development

Extreme Programming is obsessed with feedback, and in software development, goodfeedback requires good testing. Top XP teams practice "test-driven development", working invery short cycles of adding a test, then making it work. Almost effortlessly, teams producecode with nearly 100 percent test coverage, which is a great step forward in most shops.

(If your programmers are already doing even more sophisticated testing, more power to you.Keep it up, it can only help!)

It isn't enough to write tests: you have to run them. Here, too, Extreme Programming is

extreme. These "programmer tests", or "unit tests" are all collected together, and every time

any programmer releases any code to the repository (and pairs typically release twice a dayor more), every single one of the programmer tests must run correctly. One hundred percent,

all the time! This means that programmers get immediate feedback on how they're doing.Additionally, these tests provide invaluable support as the software design is improved.

Design Improvement

Extreme Programming focuses on delivering business value in every iteration. To accomplish

this over the course of the whole project, the software must be well-designed. The alternative

would be to slow down and ultimately get stuck. So XP uses a process of continuous designimprovement called Refactoring.

The refactoring process focuses on removal of duplication (a sure sign of poor design), and onincreasing the "cohesion" of the code, while lowering the "coupling". High cohesion and lowcoupling have been recognized as the hallmarks of well-designed code for at least thirty

years. The result is that XP teams start with a good, simple design, and always have a good,

simple design for the software. This lets them sustain their development speed, and in factgenerally increase speed as the project goes forward.

Refactoring is, of course, strongly supported by comprehensive testing to be sure that as the

design evolves, nothing is broken. Thus the customer tests and programmer tests are acritical enabling factor. The XP practices support each other: they are stronger together thanseparately.


22/28





Continuous Integration

Extreme Programming teams keep the system fully integrated at all times. We say that dailybuilds are for wimps: XP teams build multiple times per day. (One XP team of forty peoplebuilds at least eight or ten times per day!)

Infrequent integration leads to serious problems on a software project. First of all, althoughintegration is critical to shipping good working code, the team is not practiced at it, and oftenit is delegated to people who are not familiar with the whole system. Second, infrequently

integrated code is often -- I would say usually -- buggy code. Problems creep in at integrationtime that are not detected by any of the testing that takes place on an unintegrated system.Third, weak integration process leads to long code freezes.

Code freezes mean that you have long time periods when the programmers could be working

on important shippable features, but that those features must be held back. This weakensyour position in the market, or with your end users.

Collective Code Ownership

On an Extreme Programming project, any pair of programmers can improve any code at any

time. This means that all code gets the benefit of many people's attention, which increases

code quality and reduces defects. There is another important benefit as well: when code isowned by individuals, required features are often put in the wrong place, as one programmer

discovers that he needs a feature somewhere in code that he does not own. The owner is toobusy to do it, so the programmer puts the feature in his own code, where it does not belong.

This leads to ugly, hard-to-maintain code, full of duplication and with low (bad) cohesion.

Collective ownership could be a problem if people worked blindly on code they did notunderstand. XP avoids these problems through two key techniques: the programmer testscatch mistakes, and pair programming means that the best way to work on unfamiliar code is

to pair with the expert. In addition to ensuring good modifications when needed, this practice

spreads knowledge throughout the team.


23/28





Coding Standard

XP teams follow a common coding standard, so that all the code in the system looks as if it

was written by a single -- very competent -- individual. The specifics of the standard are notimportant: what is important is that all the code looks familiar, in support of collectiveownership.

Metaphor

Extreme Programming teams develop a common vision of how the program works, which we

call the "metaphor". At its best, the metaphor is a simple evocative description of how the

program works, such as "this program works like a hive of bees, going out for pollen andbringing it back to the hive" as a description for an agent-based information retrieval system.

Sometimes a sufficiently poetic metaphor does not arise. In any case, with or without vivid

imagery, XP teams use a common system of names to be sure that everyone understandshow the system works and where to look to find the functionality you're looking for, or to findthe right place to put the functionality you're about to add.

Sustainable Pace

Extreme Programming teams are in it for the long term. They work hard, and at a pace thatcan be sustained indefinitely. This means that they work overtime when it is effective, andthat they normally work in such a way as to maximize productivity week in and week out. It's

pretty well understood these days that death march projects are neither productive norproduce quality software. XP teams are in it to win, not to die.

Conclusion

Extreme Programming is a discipline of software development based on values of simplicity,

communication, feedback, and courage. It works by bringing the whole team together in the

presence of simple practices, with enough feedback to enable the team to see where they are and to

tune the practices to their unique situation.


24/28





Cyclomatic Complexity

Cyclomatic complexity is a software metric (measurement). It was developed by Thomas

McCabe and is used to measure the complexity of a program. It directly measures the numberof linearly independent paths through a program's source code.

The concept, although not the method, is somewhat similar to that of general text complexitymeasured by the Flesch-Kincaid Readability Test.

Contents:

Definition Key Concept Purpose and Origin Technical Detail Usage Considerations Maturity Costs and Limitations Alternatives


25/28





Equivalence Partitioning

Equivalence partitioning is a method for deriving test cases. In this method, classes of input

conditions called equivalence classes are identified such that each member of the class causesthe same kind of processing and output to occur. In this method, the tester identifies various

equivalence classes for partitioning. A class is a set of input conditions that are is likely to be

handled the same way by the system. If the system were to handle one case in the classerroneously, it would handle all cases erroneously.

Contents:

Definition The Theory Black Box vs. White Box Types of Equivalence Classes Why Learn Equivalence Partitioning? Designing Test Cases Using Equivalence Partitioning

Error Guessing

Error Guessing is a test case design technique where the tester has to guess what faultsmight occur and to design the tests to represent them.

Contents:

Definition Purpose Examples


26/28





Boundary Value Analysis

Boundary value analysis is a software testing design technique to determine test cases

covering off-by-one errors. The boundaries of software component input ranges are areas offrequent problems.

Contents:

Introduction What is Boundary Value Analysis? Purpose Applying Boundary Value Analysis Performing Boundary Value Analysis

Traceability Matrix

A method used to validate the compliance of a process or product with the requirements for that

process or product. The requirements are each listed in a row of the matrix and the columns of the

matrix are used to identify how and where each requirement has been addressed.

Contents:

Definition

Description Requirements of Traceability Matrix Baseline Traceability Matrix Building a Traceability Matrix Useful Traceability Matrices Sample Traceability Matrix


27/28





For more Software Testing Resources, please visithttp://www.OneStopTesting.com

Join largest Software Testing Community at

http://groups.yahoo.com/group/OneStopTesting/

Over 5,000 Software Testing Interview Questions at


and

http://www.TestingInterviewQuestions.com

and

http://www.NewInterviewQuestions.com


28/28





testing concepts ebook

Documents