The quality of software is assessed by a number of variables.

These variables can be divided into external and internal quality criteria. External quality is what a user experiences when running the software in its operational mode. Internal quality refers to aspects that are code-dependent, and that are not visible to the end-user. External quality is critical to the user, while internal quality is meaningful to the developer only. Some quality criteria are objective, and can be measured accordingly. Some quality criteria are subjective, and are therefore captured with more arbitrary measurements.

A fundamental framework and a set of basic principles for the measurement of product metrics for software should be established. Talking in terms of software engineering: - Measure provides a quantitative indication of extent, amount, dimension, size of an attribute of a product or process. Measure is established when a single data point has been collected. - Measurement is an act of determining a measure. Measurement occurs when one or more data points are collected. - Metric is the quantitative measure of the degree to which a system, component or process possess a given attribute. It relates individual measures in some way. - Indicator is a metric or combination of metrics providing insight into software process, project or product itself. There is a need to measure and control software complexity. It should be possible to develop measures of different attributes. These measures and metric can be used as independent indicators of the quality of analysis and design models. Product metrics assist in evaluation of analysis and design models, gives an indication of the complexity and facilitate design of more effective testing. Steps for an effective measurement process are: - Formulation which means the derivation of software measures and metrics. - Collection is the way ti accumulate data required to derive the metrics. - Analysis is the computation of metrics. - Interpretation is the evaluation of metrics. - Feedback is the recommendation derived after interpretation. Metrics characterization and validation includes: - Metric should have desirable mathematical properties. - The value of metric should increase or decrease in the manner in which a

software characteristic increases when positive trait occurs or decreases when undesirable traits are encountered. - Metric should be validated empirically.

WATERFALL MODEL
The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance.

The unmodified "waterfall model". Progress flows from the top to the bottom, like a waterfall.

The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. Many argue the waterfall model is a bad idea in practicebelieving it impossible for any nontrivial project to finish a phase of a software product's lifecycle perfectly before moving to the next phases and learning from them. For example, clients may not know exactly what requirements they need before reviewing a working prototype and commenting on it. They may change their requirements constantly. Designers and programmers may have little control over this. If clients change their requirements after the design is finalized, the design must be modified to accommodate the new requirements. This effectively means invalidating a good deal of working hours, which means increased cost,

especially if a large amount of the project's resources has already been invested in Big Design Up Front. Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. In this case, it is better to revise the design than persist in a design based on faulty predictions, and that does not account for the newly discovered problems.

To understand the Testing Process in an Agile Development Methodology, it is important to understand the Agile Development paradigm. Agile Development paradigm is not very new. Although the Agile Software Development Manifesto came into existence in February 2001, the concepts existed long before that and were expressed in different ways. Spiral Development Methodology is one such example. Understanding Agile Software Development: The Agile Software Development primarily focuses on an iterative method of development and delivery. The developers and end users communicate closely and the software is built. A working piece of software is delivered in a short span of time and based on the feedback more features and capabilities are added. The focus is on satisfying the customer by delivering working software quickly with minimum features and then improvising on it based on the feedback. The customer is thus closely involved in the Software Design and Development Process. The delivery timelines are short and the new code is built on the previous one. Despite this, high quality of the product cannot be comprised. This creates a different set of challenges for Software Testing. Although nothing is typical about any Agile Development Project and each project may have its own set of complexities, by the very nature of the paradigm bugs may be introduced in the system when a piece of code is modified/enhanced/changed by one or more Developers. Whenever a piece of code is changed it is possible that bugs have been introduced to it or previously working code is now broken. New bugs/defects can be introduced at every change or old bugs/defects may be reopened.