Software companies follows methodology which is step wise process to develop a project involving usage of programming language for

creating solutions. These steps covers the extent of examining, designing, developing, testing, documenting, implementing, and evaluating the complex subject of software engineering. Software testing is an integral part of the software development life cycle (SDLC). Effectively and efficiently testing a piece of code is equally important, if not more, than writing it. So what is software testing? Well, for those of you who are new to software testing and quality assurance, here's the answer to this question. Software testing is nothing but subjecting a piece of code to both, controlled as well as uncontrolled operating conditions, in an attempt to observe the output and examine whether it is in accordance with certain pre-specified conditions. Different sets of test cases and testing strategies are prepared, all of which aim at achieving one common goal - removing all the bugs and errors from the code and making the software error-free and capable enough of providing accurate and optimum outputs. There are different types of software testing techniques and methodologies. A software testing methodology is different from a software testing technique. We will have a look at a few software testing methodologies in the later part of this article. There are different types of software testing methodologies in the field of software testing and quality assurance. In the following article, we will have a look at various software testing methodologies that are in practice today. Software Testing Methodologies These are some commonly used software testing methodologies: Waterfall model Iterative Model V model Spiral model Prototype Model RUP Agile model RAD

Waterfall Model Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate process phases. The waterfall model adopts a 'top down' approach regardless of whether it is being used for software development or testing. The basic steps involved in this software testing methodology are: 1. 2. 3. 4. 5. Requirement analysis Test case design Test case implementation Testing, debugging and validating the code or product Deployment and maintenance

The stages of "The Waterfall Model" are: Requirement Analysis & Definition: All possible requirements of the system to be developed are captured in this phase. Requirements are set of functionalities and constraints that the enduser (who will be using the system) expects from the system. The requirements are gathered from the end-user by consultation, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be development is also studied. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model. System & Software Design: Before a starting for actual coding, it is highly important to understand what we are going to create and what it should look like? The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture. The system design specifications serve as input for the next phase of the model. Implementation & Unit Testing: On receiving system design documents, the work is divided in modules/units and actual coding is started. The system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality; this is referred to as Unit Testing. Unit testing mainly verifies if the modules/units meet their specifications. Integration & System Testing: As specified above, the system is first divided in units which are developed and tested for their functionalities. These units are integrated into a complete system during Integration phase and tested to check if all modules/units coordinate between each other and the system as a whole behaves as per the specifications. After successfully testing the software, it is delivered to the customer. Operations & Maintenance: This phase of "The Waterfall Model" is virtually never ending phase (Very long). Generally, problems with the system developed (which are not found during the development life cycle) come up after its practical use starts, so the issues related to the system are solved after deployment of the system. Not all the problems come in picture directly but they arise time to time and needs to be solved; hence this process is referred as Maintenance.

In this methodology, you move on to the next step only after you have completed the present step. There is no scope for jumping backward or forward or performing two steps simultaneously. Also, this model follows a non-iterative approach. The main benefit of this methodology is its simplistic, systematic and orthodox approach. However, it has many shortcomings since bugs and errors in the code are not discovered until and unless the testing stage is reached. This can often lead to wastage of time, money and valuable resources. Advantages The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps. Disadvantages The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.

Iterative Model An iterative lifecycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model. Consider an iterative lifecycle model which consists of repeating the following four phases in sequence:

Requirements Phase: Requirements for the software are gathered and analyzed. Iteration should eventually result in a requirements phase that produces a complete and final specification of requirements. Design Phase: Software solution to meet the requirements is designed. This may be a new design, or an extension of an earlier design. Implementation and Test phase: when the software is coded, integrated and tested.

Review Phase: Software is evaluated, the current requirements are reviewed, and changes and additions to requirements proposed. For each cycle of the model, a decision has to be made as to whether the software produced by the cycle will be discarded, or kept as a starting point for the next cycle (sometimes referred to as incremental prototyping). Eventually a point will be reached where the requirements are complete and the software can be delivered, or it becomes impossible to enhance the software as required, and a fresh start has to be made. The iterative lifecycle model can be likened to producing software by successive approximation. Drawing an analogy with mathematical methods that use successive approximation to arrive at a final solution, the benefit of such methods depends on how rapidly they converge on a solution. The key to successful use of an iterative software development lifecycle is rigorous validation of requirements, and verification (including testing) of each version of the software against those requirements within each cycle of the model. The first three phases of the example iterative model is in fact an abbreviated form of a sequential V or waterfall lifecycle model. Each cycle of the model produces software that requires testing at the unit level, for software integration, for system integration and for acceptance. As the software evolves through successive cycles, tests have to be repeated and extended to verify each version of the software. V Model The V model gets its name from the fact that the graphical representation of the different test process activities involved in this methodology resembles the letter 'V'. The basic steps involved in this methodology are more or less the same as those in the waterfall model. However, this model follows both a 'top-down' as well as a 'bottom-up' approach (you can visualize them forming the letter 'V'). The benefit of this methodology is that in this case, both the development and testing activities go hand-in-hand. For example, as the development team goes about its requirement analysis activities, the testing team simultaneously begins with its acceptance testing activities. By following this approach, time delays are minimized and optimum utilization of resources is assured.

Requirements Analysis: In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the systems functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase. System Design: System engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly. The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase. Architecture Design: This phase can also be called as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase. Module Design: This phase can also be called as low-level design. The designed system is broken up in to smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode - database tables, with all elements, including their type and size - all interface details with complete API references- all dependency issues- error message listings- complete input and outputs for a module. The unit test design is developed in this stage. Spiral Model As the name implies, the spiral model follows an approach in which there are a number of cycles (or spirals) of all the sequential steps of the waterfall model. Once the initial cycle is completed, a thorough analysis and review of the achieved product or output is performed. If it is not as per the specified requirements or expected standards, a second cycle follows, and so on. This methodology follows an iterative approach and is generally suited for very large projects having complex and constantly changing requirements.

The steps in the spiral model can be generalized as follows The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system. A preliminary design is created for the new system.

A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. The final system is constructed, based on the refined prototype. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

Advantages 1. Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier. 2. It is more able to cope with the (nearly inevitable) changes that software development generally entails. 3. Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier. Disadvantages 1. 2. 3. 4. Highly customized limiting re-usability Applied differently for each application Risk of not meeting budget or schedule Risk of not meeting budget or schedule

Prototype Model:
This model allows the client to interact and experiment with a working representation of the product. The developmental process only continues once the client is satisfied with the functioning of the prototype. Development of the prototype obviously undergoes design, coding and testing. But each of these phases is not done very formally or thoroughly. By using this prototype, the client can be able to understand the requirement for the desired system

The process of prototyping involves the following steps

Identify basic requirements and Design: Determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored. Develop Initial Prototype: The initial prototype is developed that includes only user interfaces. Review: The customers, including end-users, examine the prototype and provide feedback on additions or changes. Revise and Enhancing the Prototype: Using the feedback both the specifications and the prototype can be improved. Negotiation about what is within the scope of the contract/product may be necessary. If changes are introduced then the above two phases must be implemented.

Advantages

1. Reduced time and costs: Prototyping can improve the quality of requirements and
specifications provided to developers.

2. Improved and increased user involvement: Prototyping requires user involvement and
allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications. Disadvantages

1. Insufficient analysis: The focus on a limited prototype can distract developers from
properly analyzing and complete project.

2. User confusion of prototype and finished system: Users can begin to think that a 3.
prototype, intended to be thrown away, is actually a final system that merely needs to be finished or polished Developer attachment to prototype: Developers can also become attached to prototypes they have spent a great deal of effort producing; this can lead to problems like attempting to convert a limited prototype into a final system when it does not have an appropriate underlying architecture. Excessive development time of the prototype: A key property to prototyping is the fact that it is supposed to be done quickly. Expense of implementing prototyping: the start up costs for building a development team focused on prototyping may be high

4. 5.

 Rational Unified Process (RUP) The RUP methodology is also similar to the spiral model in the sense that the entire testing procedure is broken up into multiple cycles or processes. Each cycle consists of four phases namely; inception, elaboration, construction and transition. At the end of each cycle, the product or the output is reviewed and a further cycle (made up of the same four phases) follows if necessary. Today, you will find certain organizations and companies adopting a slightly modified version of the RUP, which goes by the name of Enterprise Unified Process (EUP). Four Project Life cycle Phases Inception Phase The primary objective is to scope the system adequately as a basis for validating initial costing and budgets. In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc.), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. Elaboration Phase The primary objective is to mitigate the key risk items identified by analysis up to the end of this phase. The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form. Construction Phase The primary objective is to build the software system. In this phase, the main focus is on the development of components and other features of the system. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes. Transition Phase The primary objective is to 'transit' the system from development into production, making it available to and understood by the end user. The activities of this phase include training the end users and maintainers and beta testing the system to validate it against the end users' expectations. The product is also checked against the quality level set in the Inception phase Advantages of using RUP

Well-documented and complete methodology RUP is complete methodology with all of its documentation easily available. Open and Public The Rational Unified Process is openly published, distributed and supported. Training readily available The on-line version of the Rational Unified Process walks users through the process in a step-by-step tutorial manner. Changing requirements proactive resolve of clients changing requirements and related risks.

Reduced integration time and effort As the development model followed is iterative in nature so we integrate the code in phases resulting in lesser time and effort spent on integration. Higher level of reuse The reuse of code is easy and faster.

Disadvantage of using RUP:

The process is too complex Unless you have a real expert, it is likely that you will succeed in adapting to this process. The process is too complex, too difficult to learn and too difficult to apply correctly. Sociological Aspects The Unified process does not capture the sociological aspects of software development and the details of how to truly develop incrementally. Disorganized Development may lead to a totally undisciplined form of software development.

Agile Model Agile methodology is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences, known as sprints. But before discussing agile methodologies further, its best to first turn to the methodology that inspired it: waterfall, or traditional sequential development. Agile development methodology attempts to provide many opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a shippable increment of work. Thus by focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology could be described as iterative and incremental. In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development requirements, design, etc. is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, theres always time to steer it in another direction. The results of this inspect-and-adapt approach to development greatly reduce both development costs and time to market. Because teams can gather requirements at the same time theyre gathering requirements, the phenomenon known as analysis paralysis cant really impede a team from making progress. And because a teams work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world. In essence, it could be said that the agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasnt even been written yet, agile empowers teams to optimize their release as its developed, to be as competitive as possible in the marketplace. In the end, a development agile methodology that preserves a products critical market relevance and ensures a teams work doesnt wind up on a shelf, never released, is an attractive option for stakeholders and developers alike. Advantages of Agile Agile methodology has an adaptive team which is able to respond to the changing requirements. The team does not have to invest time and effort and finally find that by the time they delivered the product, the requirement of the customer has changed.

Face to face communication and continuous inputs from customer representative leaves no space for guesswork. The documentation is crisp and to the point to save time. The end result is the high quality software in least possible time duration and satisfied customer.

In a nutshell this means that you can get development started fast, but with the caveat that the project scope statement is "flexible" and not fully defined. Hence this can be one of the major causes of scope creep if not managed properly. Disadvantages of Agile Methodology In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle. There is lack of emphasis on necessary designing and documentation. The project can easily get taken off track if the customer representative is not clear what final outcome that they want. Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.

Rapid Application Development (RAD)

RAD is a linear sequential software development process model that emphasis an extremely short development cycle using a component based construction approach. If the requirements are well understood and defines, and the project scope is constraint, the RAD process enables a development team to create a fully functional system with in very short time period. RAD is a concept that products can be developed faster and of higher quality through: Gathering requirements using workshops or focus groups Prototyping and early, reiterative user testing of designs The re-use of software components A rigidly paced schedule that defers design improvements to the next product version Less formality in reviews and other team communication

RAD model has the following phases: Business Modeling: The information flow among business functions is defined by answering questions like what information drives the business process, what information is generated, who generates it, where does the information go, who process it and so on. Data Modeling: The information collected from business modeling is refined into a set of data objects (entities) that are needed to support the business. The attributes (character of each entity) are identified and the relation between these data objects (entities) is defined.

10

Process Modeling: The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting or retrieving a data object. Application Generation: Automated tools are used to facilitate construction of the software; even they use the 4th GL techniques. Testing and Turn over: Many of the programming components have already been tested since RAD emphasis reuse. This reduces overall testing time. But new components must be tested and all interfaces must be fully exercised. Advantages of RAD: RAD reduces the development time and reusability of components help to speed up development. All functions are modularized so it is easy to work with. Disadvantages of RAD: For large projects RAD require highly skilled engineers in the team. Both end customer and developer should be committed to complete the system in a much abbreviated time frame. RAD is based on Object Oriented approach and if it is difficult to modularize the project the RAD may not work well.

11