Programming Portal: March 2009

Programming Development Process Overview

A process is a continuous series of activities that convey you to an end.Main activities in a software development process are

analysis— which focuses on understanding the problem and defining the requirements for the software portions of a system
design— which focuses on solving the problem in software
implementation— which focuses on translating the design into executable code
testing— which focuses on ensuring that inputs produce the desired results as specified by the requirements

Maintenance begins after deployment with a focus on bug repairs and enhancements. Maintenance usually involves further analysis, design, implementation, and testing. Among the testing activities during maintenance is regression testing, which ensures that successful test results after changes are the same as those before changes.

Under an incremental development process, a system is developed as a sequence of increments. An increment is a deliverable, including models, documentation, and code, which provides some of the functionality required for the system.

The products developed in one increment feed into the development of the next increment. Successive increments add (and sometimes change) system functionality. The final increment delivers a deployable system that meets all requirements. Increments can be developed in sequence or one or more can be developed concurrently.

To build each increment, developers analyze, design, code, and test as needed. They typically have to perform these activities repeatedly in building an increment because they find errors in previous work. As development progresses, they gain new insights into the problem and the solution. We prefer to acknowledge this iterative aspect of incremental development and make it part of the process.

In planning each increment, we include explicit steps for repeating various activities. Among these are steps for systematically reviewing current models, identifying errors based on experiences in later tasks, and modifying the models (or code) that have already been produced—not just those that will be produced in the future.

Object-oriented development is particularly well suited to evolutionary development because object-oriented analysis, design, and implementation entail the successive refinement of a single model. This is the case both within an increment and among increments.

In object-oriented analysis, we understand a problem by modeling it in terms of objects and classes of objects, their relationships and responsibilities. In object-oriented design, we solve the problem by manipulating those same objects and relationships identified in analysis and introducing solution-specific classes, objects, relationships, and responsibilities.

Implementation is straightforward from a well-specified set of design products. Thus, the entire development process involves a refinement of a model. Design products are primarily an extension of analysis products and implementation products are coded expressions of design products. The products of one increment are extended and refined in the next increment.

The incremental development of products requires the incremental testing of those products. Products can change from increment to increment in both planned and unplanned ways. Test suites must change in concert. Regression tests must be run between increments and within iterations to ensure that changes do not adversely affect correctly working code.

A process in which work on one increment overlaps work on another adds to the complexity of development and testing. Coordination is required to sequence the development of interacting increments so that objects that are associated with, but assigned to different increments, can be tested in a timely fashion.

Software testing other interesting topics:

Programming c language introduction
CLASSES AND OBJECTS IN JAVA

JAVA PROGRAMMING ENVIRONMENT

JAVA EXECUTION

JAVA CONSTRUCTORS

FIELD DECLARATIONS IN CLASS OF JAVA

EXCEPTIONS IN JAVA

EXCEPTIONS IN JAVA PART TWO

VARIABLE PARAMETERS IN JAVA

COMMENTS TYPES AND VARIABLES

JAVA JDBC AND ODBC

INTERFACE IN JAVA

OPERATORS IN JAVA

Programming C Language Introduction

C programming language is said to be a middle level language because it combines the best elements of high-level languages with the control and flexibility of assembly language .

As a middle-level language, C allows the manipulation of bits, bytes, and addresses the basic elements with which the computer functions and C code is also very portable.Portability means that it is easy to adapt software written for one type of computer or operating system to another type.

All high level programming languages support the concept of data types. A data type defines a set of values that a variable can store along with a set of operations that can be performed on that variable. Common data types are integer, character, and floating-point. Although C has several built in data types, it is not a strongly typed language, as are Pascal and Ada. C permits almost all type conversions.

C specifies almost no run time error checking. For example, no check is performed to ensure that array boundaries are not overrun. and these types of checks are the responsibility of the programmer.

C does not demand strict type compatibility between a parameter and an argument.C allows an argument to be of any type so long as it can be reasonably converted into the type of the parameter and C provides all of the automatic conversions to accomplish this.

C allows the direct manipulation of bits, bytes, words, and pointers. This makes it well suited for system-level programming, where these operations are common.

C has only a small number of keywords, which are the commands that make up the C language. For example, C89 defined 32 keywords, and C99 adds only 5 more. High-level languages typically have many more keywords.

C is a structured language. The distinguishing feature of a structured language is compartmentalization of code and data. This is the ability of a language to section off and hide from the rest of the program all information and instructions necessary to perform a specific task. One way that you achieve compartmentalization is by using subroutines that employ local (temporary) variables.

By using local variables, you can write subroutines so that the events that occur within them cause no side effects in other parts of the program. This capability makes it very easy for your C programs to share sections of code. If you develop compartmentalized functions, you need to know only what a function does, not how it does it.

Structured languages typically support several loop constructs, such as while, do-while, and for. In a structured language, the use of goto is either prohibited or discouraged and is not the common form of program control . A structured language allows you to place statements anywhere on a line and does not require a strict field concept.

In C, functions are the building blocks in which all program activity occurs. They allow you to define and code individually the separate tasks in a program, thus allowing your programs to be modular.

After you have created a function, you can rely on it to work properly in various situations without creating side effects in other parts of the program. Being able to create stand alone functions is extremely important in larger projects where one programmer's code must not accidentally affect another's.

Related posts

Software testing prospective
INTRODUCTION TO C PROGRAMMING

Programming with C an introduction part two

Data types for C programming

C PROGRAMMING CHARACTER SET

CONSTANTS IN C PROGRAMMING

PROGRAMMING C VARIABLES

C PROGRAM INSTRUCTIONS

COMPILATION AND EXECUTION OF C PROGRAM

C PROGRAMMING RULES PART ONE

C PROGRAMMING RULES PART TWO

COMPILATION AND EXECUTION OF C PROGRAM

INSTRUCTIONS TO WRITE C PROGRAM

ARITHMETIC INSTRUCTIONS TO WRITE C PROGRAM

CONVERSION OF CONSTANTS IN C PROGRAM

PRIORITY OF AR THEMATIC OPERATIONS IN C

OPERATORS ASSOCIATIVITY IN C

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE

BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING

Functions and usage in C part two

Coding in C functions

SoftwareTesting Perspective

The testing perspective is a way of looking at any development product and questioning its validity. The person examining work products from this perspective utilizes a thorough investigation of the software and all its representations to identify faults. The search for faults is guided by both systematic thinking and intuitive insights.

It is a perspective that makes reviews and inspections just as powerful a tool as execution-based testing. A review will almost never find something that is missing—that is, a review typically only seeks to validate what exists and does not systematically search to determine if all things that should be in the software actually are in it.

The testing perspective requires that a piece of software demonstrate that it not only performs according to its specification, but performs only to that specification. Thus, a product is tested to determine that it will do what it is supposed to do, and it is also tested to ensure that it does not do what it is not supposed to do.

Software testing is typically accomplished by a combination of inspections, reviews, and test executions. The purpose of these activities is to observe failures.

An inspection is an examination of software based on a checklist of typical problems. Most items on a checklist are based on programming language semantics and/or coding conventions—for example, ensuring that each program variable is initialized before its first use and that pointers or references have been set to reasonable values before they are used. Modern compilers for object-oriented programming languages can detect many of the problems called out on traditional inspection checklists.

A review is an examination of software with the purpose of finding errors and faults even before the software is executed. Reviews are made in the context of the system being developed and have a deeper interest in the software than do inspections.

A review delves into the meaning of each part of a program and whether it is appropriate for meeting some or all of the application's requirements. A review is intended to uncover errors such as missed or misunderstood requirements or faults in a program's logic. Some reviews examine programming details such as whether variable names are well chosen and whether algorithms are as efficient as they could be.

Test execution is testing software in the context of a running program. Through executing the software, a tester tries to determine whether it has the required behavior by giving the program some input and verifying that the resulting output is correct. Among the challenges to testers are identifying suitable inputs, determining correct outputs, and determining how to observe the outputs.

The testing perspective is

Skeptical: Wants proof of quality.
Objective: Makes no assumptions.
Thorough: Doesn't miss important areas.
Systematic: Searches are reproducible.

Functions in c programming
SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO

DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT

Function in C Programming

A computer program (except for the simplest one) cannot handle all the tasks by itself. Instead, it requests other program like entities—called ‘functions’ in C—to get its tasks done.

A function is a self-contained block of statements that perform a coherent task of some kind.

Example

main( )

{

message( ) ;

printf ( "\nCry!" ) ;

}

message( )

{ printf ( "\nSmile" ) ;

}

And here’s the output...

Smile...

Cry

Here, main( ) itself is a function and through it we are calling the function message( ). Main( ) ‘calls’ the function message( ) and it mean that the control passes to the function message( ).

The activity of main( ) is temporarily suspended; it falls asleep while the message( ) function wakes up and goes to work. When the message( ) function runs out of statements to execute, the control returns to main( ), which comes to life again and begins executing its code at the exact point where it left off. Thus, main( ) becomes the ‘calling’ function, whereas message( ) becomes the ‘called’ function.

Important points about Function

Any C program contains at least one function.

If a program contains only one function, it must be main( ).

If a C program contains more than one function, then one (and only one) of these functions must be main( ), because program execution always begins with main( ).

There is no limit on the number of functions that might be present in a C program.

Each function in a program is called in the sequence specified by the function calls in main( ).

After each function has done its thing, control returns to main( ).

When main( ) runs out of function calls, the program ends. The program execution always begins with main( ). Except for this all C functions enjoy a state of perfect equality. No precedence, no priorities.

One function can call another function it has already called but has in the meantime left temporarily in order to call a third function which will sometime later call the function that has called it.

Other C programming Related topics are

Switch statement in c programming
INTRODUCTION TO C PROGRAMMING

Programming with C an introduction part two

Data types for C programming

C PROGRAMMING CHARACTER SET

CONSTANTS IN C PROGRAMMING

PROGRAMMING C VARIABLES

C PROGRAM INSTRUCTIONS

COMPILATION AND EXECUTION OF C PROGRAM

C PROGRAMMING RULES PART ONE

C PROGRAMMING RULES PART TWO

COMPILATION AND EXECUTION OF C PROGRAM

INSTRUCTIONS TO WRITE C PROGRAM

ARITHMETIC INSTRUCTIONS TO WRITE C PROGRAM

CONVERSION OF CONSTANTS IN C PROGRAM

PRIORITY OF AR THEMATIC OPERATIONS IN C

OPERATORS ASSOCIATIVITY IN C

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE

BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING

Functions and usage in C part two

Coding in C functions

Switch in C Programming

The control statement that allows us to make a decision from the number of choices is called a switch, or more correctly a switch-case-default, since these three keywords go together to make up the control statement.

The syntax for this is

switch ( integer expression )
{
case constant 1 :
do this ;
case constant 2 :
do this ;
case constant 3 :
do this ;
default : do this ;
}

The integer expression following the keyword switch is any C expression that will yield an integer value. It could be an integer constant like 1, 2 or 3, or an expression that evaluates to an integer. The keyword case is followed by an integer or a character constant. Each constant in each case must be different from all the others. The “do this” lines in the above form of switch represent any valid C statement.

How it functions ?

First, the integer expression following the keyword switch is evaluated. The value it gives is then matched, one by one, against the constant values that follow the case statements. When a match is found, the program executes the statements following that case, and all subsequent case and default statements as well. If no match is found with any of the case statements, only the statements following the default are executed.

Example with only Switch

main( )
{
int i = 2 ;
switch ( i )
{
case 1 :
printf ( "I am in case 1 \n" ) ;
case 2 : printf ( "I am in case 2 \n" ) ;
case 3 : printf ( "I am in case 3 \n" ) ;
default : printf ( "I am in default \n" ) ;
}
}

The output of this program would be:

I am in case 2
I am in case 3
I am in default

The switch executes the case where a match is found and all the subsequent cases and the default as well.

If you want that only case 2 should get executed, it is upto you to get out of the switch then and there by using a break statement.There is no need for a break statement after the default, since the control comes out of the switch anyway.

Example with Break statement and Switch

main( )
{
int i = 2 ;
switch ( i )
{
case 1 : printf ( "I am in case 1 \n" ) ;
break ;
case 2 : printf ( "I am in case 2 \n" ) ;
break ;
case 3 : printf ( "I am in case 3 \n" ) ;
break ;
default : printf ( "I am in default \n" ) ;
}
}

The output of this program would be:

I am in case 2

Other C programming Related topics are

INTRODUCTION TO C PROGRAMMING

Programming with C an introduction part two

Data types for C programming

C PROGRAMMING CHARACTER SET

CONSTANTS IN C PROGRAMMING

PROGRAMMING C VARIABLES

C PROGRAM INSTRUCTIONS

COMPILATION AND EXECUTION OF C PROGRAM

C PROGRAMMING RULES PART ONE

C PROGRAMMING RULES PART TWO

COMPILATION AND EXECUTION OF C PROGRAM

INSTRUCTIONS TO WRITE C PROGRAM

ARITHMETIC INSTRUCTIONS TO WRITE C PROGRAM

CONVERSION OF CONSTANTS IN C PROGRAM

PRIORITY OF AR THEMATIC OPERATIONS IN C

OPERATORS ASSOCIATIVITY IN C

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE

BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING

Functions and usage in C part two

Coding in C functions

Software testing spiral model

Software Testing Spiral Model

The spiral model is based on the need to iterate. It contains as many iterations as are necessary to bring a product to fruition. Each iteration requires that the participants plan, define their life-cycle, prototype, analyze risks, write requirements, build models, detailed designs, code, unit, and system tests, and install.

Advantages :

It is flexible and allows for multiple iterations.
It employs prototyping extensively.
It allows for the coexistence of other models .
It makes risk evaluation explicit.
It acknowledges the need to validate requirements and design.
It was originally designed with a particular need to accommodate COTS, and is therefore more amenable to software reuse.

Disadvantages :

It is less easy to allocate phases to groups and responsibilities than other models.
It requires that staff are well-versed in software engineering.
It requires much team self-discipline in the capture of emerging requirements.
It does not acknowledge the need to have test input from the start of the project.
It allocates particular phases to requirements definition and high- and low-level design.
It doesn’t make the baselines explicit.
It doesn’t allow for process decomposition
Much prototype code may eventually be used in the final version.
It must be very tool-supported to work or it will either decay or become enmeshed in the
bureaucracy it was intended to minimize.

Implications :

• The status of emerging requirements must be constantly reviewed.
• The team is committed to validating both the requirements and the design.
• Any use of prototype code in the production version will require much more rigorous unit testing than is normal.

Software testing stage gate process model
SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO

DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT

Software Testing Stage Gate Process Model

Cooper’s stage gate model is a variant of the water fall. It splits the life-cycle into six stages separated by “gates.” Each gate is a decision point. It differs from the waterfall in that the activities in each stage may be simultaneous.

The different stages of this model are explained below.

Discovery stage: a product manager thinks of a new idea for a product.
Idea screen: the idea is presented to potential stakeholders for their buy-in.

Scoping stage: the market for the product is assessed and key features are identified.
Second screen: the idea is re-presented to potential stakeholders for their buy-in, but with more-rigorous requirements and other information.

The business case stage: in which the product, market, organization, project management and environment, competitors, budget, RoI, and legal issues are defined.
Go to development is the moment at which the organization can commit to the large budget required for development.

The development stage includes requirements refining, design, code, and build. Its output is a product ready for beta testing.
Go to testing is the moment when the testing budget and the marketing and operational plans must be committed to. It is based on the continued existence of a market opportunity.

Testing is system and acceptance testing at internal and friendly customer sites. It generates a
product fit for launch.
Go to launch: is the moment when marketing and training plans become operative and we can launch the product.

Problems with this model are

1• Half the activities are oriented to the development of a business case. Since this is likely to occupy between 5–10% of the total manpower, more detail on the other 90–95% of the manpower’s activities would be useful.

2• No allowance has been made for the requirements changes.

3• Testing is relegated to the penultimate activity. The possibility that the requirements are deeply flawed will thus tend to be hidden. Similarly the testers will not learn how to use the product until too late causing considerable delay. The tests they prepare may thus need much rewriting.

4• That a decision can be taken on the marketability of a product which has yet to enter beta testing requires enormous faith in the ability of developers. The amount of iteration between the development and testing groups is not shown, and the delays can be considerable.

To overcome all these problems

1• Focus on the earliest access to the requirements as they are assembled.
2• Get early access to prototype versions so they can prepare tests.
3• Provide review and possibly modeling feedback to management such that inconsistent or missing requirements be identified asap.

Related :

Software testing water fall model
SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO

DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT

Waterfall Model

The waterfall model consists of 5 phases:

1. Requirements (in which the customer requirements are written).
2. Design (in which the high and low-level design documents are written).
3. Code (in which the code is written and (hopefully) unit tested).
4. System test (which is where we come in).
5. Installation and cut over.

Disadvantages of waterfall model

Bureaucrats believe such phases are finite and cannot be iterated upon.
It doesn’t allow for parallel activities such as prototyping or the development of user interface.
specifications or for safety-critical system issues such as the development of a safety case.
It makes no mention of contract preparation, project management, reviews, or audits.
It implies that system testing starts only when coding is finished.
It says nothing about software reuse.

Advantages of waterfall model

Each phase generates some baseline deliverable.
It is well-known.
It has been used for many years.
It is very adaptable.
Each process can be decomposed into others.
You can add any process you want.

Here

Each phase may have to be repeated (as requirements change, as prototypes evolve).
It needs to be seen in parallel with a number of other life-cycles with which it must stay synchronized.
It can be modified for prototypes and software reuse.
Testing input begins at least as early as requirements definition .
Any change to requirements, design, or code must be manually reflected through all levels of documentation to ensure all documents are consistent . then it is perfectly usable.

Managing Risk in Software Project

Plan how to manage the project’s risks: The Risk Management Plan documents how risks will be managed. It is a subset of the project plan and is written before the project begins.
Identify risks: One simple approach is to get representatives of all the affected groups in a room and have a workshop. Circulate a provisional list to excite attention. Get their ideas down onto large sheets of paper you can blu-tack to the walls. Circulate a revised list after the meeting.

Repeat the process half-way through the project, and identify how many have not occurred, and how many unforeseen ones had occurred.

Risk Alerts are the triggers used to identify when a risk is imminent. Typical test-related triggers are:

Reduction in the number of lines of code per bug found.
Finding an unacceptably-high number of priority-1 and -2 bugs in a build.
Finding an unacceptably-high number of bugs in a component.
Late arrival of signed-off specifications for use as a baseline.
Failure of performance tests to achieve targets.
Growing code complexity.
Growing code turmoil.

Monitoring such risks is easier when an alerting system is in place. The existence of a risk log allows the test team to identify priorities and provides a good basis for deciding the mix of tests to be planned.

Risks can be grouped by sources and by kinds and a risk kind is for example that something doesn’t work, that it works too late, too slowly, at the wrong time, or that it has unintended side-effects. These groups are sensitive to risk drivers in that a driver can change a whole group of risks.

The failure of the project to use an appropriate development method was having a knock-on effect throughout the whole of the project. It was a source of risks and a major driver. Here are some more are

Use of an inappropriate (unrelated to the risk) method or process.
Lack of customer involvement:Apart from the obvious need for a sufficient set of requirements
There is the need for feedback to users of (fragments of) the proposed solution.
Dissimilarity to previous projects: If “we’ve never done anything as (big/complex/different) as this before” is an issue, then beware.
Project complexity: This is relative to the experience of an organization. What might exhaust some organizations will be run-of-the-mill to others.
• Requirements volatility:If such changes aren’t allowed for, the project will soon deteriorate.(56)

How do we test a software ?

The following are the different techniques of software testing on the open basis.

Functional (black-box) methods can be applied to any unit, build, or system, since they assume no knowledge of how either was constructed or what it contains. Such methods require a sufficient and unambiguous specification if they are to be effective. (Devising black-box tests for some code from its specification at the time the specification is written is a useful verification of the specification; if it can’t be done, the specification isn’t good enough.) This is what you will normally do for a system test.

Structural (white-box) methods can also be used on any unit or build, but are cheapest to devise when used on structured programs, e.g., well-written programs in a structured language. These are usually applied to unit tests.

Dynamic analysis techniques are derivative methods which assume that a particular technique such as condition tables, finite state machines, object-orientation, or functional programming, has been used to develop the software; we use knowledge of that technique to determine the test cases, so these have very special areas of application. These can be applied at both system test and unit test times. These are usually applied to unit tests.

Static analysis techniques can best be used before integration, and can also point to the need for more-rigorous unit testing. These require using tools to analyze the source code .These are usually applied to unit tests.

Symbolic evaluation carried out by an automated symbolic evaluation tool places no special requirement on the unit, except of course that it be in the language evaluated by the tool. This involves “dry-running” the code, and recording the output values of variables algebraically rather than using specific values for input variables . This is usually applied to unit tests.

Other Programming Courses :

TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique

XML Logical Structure

HTML uses its tags as if they were style switches. The start tag turns a feature on, such as underlining, and an end tag turns it off again. XML uses its start tags and end tags as containers.

The start tag, the content, and the end tag all form a single element. Elements are the building bricks out of which an XML document is assembled. Each XML document must have only one root element, and all the other elements must be perfectly nested inside that element. This means that if an element contains other elements, those elements must be completely enclosed within that element.

If we sketch out the structure of the elements in this XML document, you’ll obtain the kind of tree structure of elements shown in figure below.

As we can see from figure , the document has a sort of tree-like structure, with the root element (&lthome.page>) at the top of the tree (or the base, depending on how you look at it). All the elements that are inside this element are neatly contained within each other. An XML document must contain one and only one root element, and there must not be any elements that are either partially or completely outside, before or after, that element.

To make it easier to refer to the relationships between elements and to elements with respect to other elements, we could say that an element is the parent of the elements that it contains. The elements that are inside an element are called its children. Elements that share the same parent element are called siblings.

In the simple example shown in Figure , &lthome.page> is the parent of all the other elements, &lttext> is the parent of &ltpara>, &lttitle> is a child of &lthead>, and &lttitle> and &ltbanner> are siblings. Going down the element tree, each child element must be fully contained within its parent element. Sibling elements may not overlap.

The arrangement of the elements in an XML document is called the logical structure. As you will see next, an XML document also has a physical structure. In order to be usable the logical and physical structure of an XML document must be synchronous; they must be completely and properly nested inside each other.

XML anatomy part two
TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique

Top Tabs