What is Waterfall model, its distinct stages, advantages and disadvantages?

The waterfall model was one of the earliest models to be designed. It has a natural timeline where tasks are executed in a sequential fashion.

The model consists of six distinct stages:

1. In the requirements analysis phase

(a) The problem is specified along with the desired service objectives (goals)
(b) The constraints are identified

2. In the specification phase the system specification is produced from the detailed definitions of (a) and (b) above. This document should clearly define the product function.

Note that in some text, the requirements analysis and specifications phases are combined and represented as a single phase.

3. In the system and software design phase, the system specifications are translated into a software representation. The software engineer at this stage is concerned with:

• Data structure
• Software architecture
• Algorithmic detail and
• Interface representations

The hardware requirements are also determined at this stage along with a picture of the overall system architecture. By the end of this stage the software engineer should be able to identify the relationship between the hardware, software and the associated interfaces. Any faults in the specification should ideally not be passed ‘down stream’

4. In the implementation and testing phase stage the designs are translated into the software domain

• Detailed documentation from the design phase can significantly reduce the coding effort.
• Testing at this stage focuses on making sure that any errors are identified and that the software meets its required specification.

5. In the integration and system testing phase all the program units are integrated and tested to ensure that the complete system meets the software requirements. After this stage the software is delivered to the customer [Deliverable – The software product is delivered to the client for acceptance testing.]

6. The maintenance phase the usually the longest stage of the software. In this phase the software is updated to:
• Meet the changing customer needs
• Adapted to accommodate changes in the external environment
• Correct errors and oversights previously undetected in the testing phases
• Enhancing the efficiency of the software

Observe that feed back loops allow for corrections to be incorporated into the model. For example a problem/update in the design phase requires a ‘revisit’ to the specifications phase. When changes are made at any phase, the relevant documentation should be updated to reflect that change.

Advantages

• Testing is inherent to every phase of the waterfall model
• It is an enforced disciplined approach
• It is documentation driven, that is, documentation is produced at every stage

Disadvantages

The waterfall model is the oldest and the most widely used paradigm.
However, many projects rarely follow its sequential flow. This is due to the inherent problems associated with its rigid format. Namely:
• It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses.
• As The client usually only has a vague idea of exactly what is required from the software product, this WM has difficulty accommodating the natural uncertainty that exists at the beginning of the project.
• The customer only sees a working version of the product after it has been coded. This may result in disaster if any undetected problems are precipitated to this stage.

What is Test Plan and how to create a Test Plan document?

A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it.

A test plan states what the items to be tested are, at what level they will be tested, what sequence they are to be tested in, how the test strategy will be applied to the testing of each item, and describes the test environment.
A test plan should ideally be organization wide, being applicable to all of organizations software developments.

The objective of each test plan is to provide a plan for verification, by testing the software, the software produced fulfils the functional or design statements of the appropriate software specification. In the case of acceptance testing and system testing, this generally means the Functional Specification.

The first consideration when preparing the Test Plan is who the intended audience is – i.e. the audience for a Unit Test Plan would be different, and thus the content would have to be adjusted accordingly.

You should begin the test plan as soon as possible. Generally it is desirable to begin the master test plan as the same time the Requirements documents and the Project Plan are being developed. Test planning can (and should) have an impact on the Project Plan. Even though plans that are written early will have to be changed during the course of the development and testing, but that is important, because it records the progress of the testing and helps planners become more proficient
Based on the above information, we can say that a test plan document can have all or few of the following contents based on the requirements:

 Title
 Identification of software including version/release numbers
 Revision history of document including authors, dates, approvals
 Table of Contents
 Purpose of document, intended audience
 Objective of testing effort
 Software product overview
 Relevant related document list, such as requirements, design documents, other test plans, etc.
 Relevant standards or legal requirements
 Traceability requirements
 Relevant naming conventions and identifier conventions
 Overall software project organization and personnel/contact-info/responsibilties
 Test organization and personnel/contact-info/responsibilities
 Assumptions and dependencies
 Project risk analysis
 Testing priorities and focus
 Scope and limitations of testing
 Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable
 Outline of data input equivalence classes, boundary value analysis, error classes
 Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems
 Test environment validity analysis - differences between the test and production systems and their impact on test validity.
 Test environment setup and configuration issues
 Software migration processes
 Software CM processes
 Test data setup requirements
 Database setup requirements
 Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
 Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
 Test automation - justification and overview
 Test tools to be used, including versions, patches, etc.
 Test script/test code maintenance processes and version control
 Problem tracking and resolution - tools and processes
 Project test metrics to be used
 Reporting requirements and testing deliverables
 Software entrance and exit criteria
 Initial sanity testing period and criteria
 Test suspension and restart criteria
 Personnel allocation
 Personnel pre-training needs
 Test site/location
 Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and coordination issues
 Relevant proprietary, classified, security, and licensing issues.
 Open issues
 Appendix - glossary, acronyms, etc.

What is Verification and validation?

Lots of tester have this question in there mind and some are confused that what is the difference between Verification and Validation.

Let me tell you that Verification and validation is the process of checking that a product, service, or system meets specifications and that it fulfills its intended purpose.

Verification is a Quality control process that is used to evaluate whether or not a product, service, or system complies with regulations, specifications, or conditions imposed at the start of a development phase. Verification can be in development, scale-up, or production. This is often an internal process.

Validation is Quality assurance process of establishing evidence that provides a high degree of assurance that a product, service, or system accomplishes its intended requirements. This often involves acceptance of fitness for purpose with end users and other product stakeholders.

It is sometimes said that validation can be expressed by the query "Are you building the right thing?" and verification by "Are you building the thing right?". "Building the right thing" refers back to the user's needs, while "building it right" checks that the specifications be correctly implemented by the system. In some contexts, it is required to have written requirements for both as well as formal procedures or protocols for determining compliance.