Software Testing Tutorial

Software testing is an integral part of Software Development Life Cycle. Testing software or any

product in day-to-day business applications or in our daily routine work becomes necessary as

going around with these, will mess up things. This session helps you travel through the journey

of software testing in the form of software testing tutorial.

Software Development Life Cycle (SDLC) is a procedural process, in the development of a

software product. The process is carried in a set of steps, which explains the whole idea about

how to go through each product.

The classification of Software Development Life Cycle process is as follows

Planning

1. Analysis

2. Design

3. Software Development

4. Implementation

5. Software Testing

6. Deployment

7. Maintenance

Software Testing is an important factor in a product's life cycle, as the product will have greater

life, only when it works correctly and efficiently according to the customer's requirements.

Introduction to Software Testing

Before moving further towards introduction to software testing, we need to know a few

concepts that will simplify the definition of software testing.

Error: Error or mistake is a human action that produces wrong or incorrect result.

Defect (Bug, Fault): A flaw in the system or a product that can cause the component to

fail or misfunction.

Failure: It is the variance between the actual and expected result.

Risk: Risk is a factor that could result in negativity or a chance of loss or damage.

Thus Software testing is the process of finding defects/bugs in the system, that occurs due to an

error in the application, which could lead to failure of the resultant product and increase in

probability of high risk. In short, software testing have different goals and objectives, which

often include:

1. finding defects;

2. gaining confidence in and providing information about the level of quality;

3. preventing defects.

Scope of Software Testing

The primary function of software testing is to detect bugs in order to correct and uncover it.

The scope of software testing includes execution of that code in various environment and also

to examine the aspects of code - does the software do what it is supposed to do and function

according to the specifications? As we move further we come across some questions such as

"When to start testing?" and "When to stop testing?" It is recommended to start testing from

the initial stages of the software development. This not only helps in rectifying tremendous

errors before the last stage, but also reduces the rework of finding the bugs in the initial stages

every now and then. It also saves the cost of the defect required to find it. Software testing is

an ongoing process, which is potentially endless but has to be stopped somewhere, due to the

lack of time and budget. It is required to achieve maximum profit with good quality product,

within the limitations of time and money. The tester has to follow some procedural way

through which he can judge if he covered all the points required for testing or missed out any.

To help testers to carry out these day-to-day activities, a baseline has to be set, which is done in

the form of checklists.

Software Testing Key Concepts

Defects and Failures: As we discussed earlier, defects are not caused only due to the

coding errors, but most commonly due to the requirement gaps in the non-functional

requirement, such as usability, testability, scalability, maintainability, performance and

security. A failure is caused due to the deviation between an actual and an expected

result. But not all defects result to failures. A defect can turn into a failure due to the

change in the environment and or the change in the configuration of the system

requirements.

Input Combination and Preconditions: Testing all combination of inputs and initial state

(preconditions), is not feasible. This means finding large number of infrequent defects is

difficult.

Static and Dynamic Analysis: Static testing does not require execution of the code for

finding defects, whereas in dynamic testing, software code is executed to demonstrate

the results of running tests.

Verification and Validation: Software testing is done considering these two factors.

1. Verification: This verifies whether the product is done according to the

specification?

2. Validation: This checks whether the product meets the customer requirement?

Software Quality Assurance: Software testing is an important part of the software

quality assurance. Quality assurance is an activity, which proves the suitability of the

product by taking care of the quality of a product and ensuring that the customer

requirements are met.

Software Testing Types:

Software test type is a group of test activities that are aimed at testing a component or system

focused on a specific test objective; a non-functional requirement such as usability, testability

or reliability. Various types of software testing are used with the common objective of finding

defects in that particular component.

Software testing is classified according to two basic types of software testing: Manual Scripted

Testing and Automated Testing.

Manual Scripted Testing:

Black Box Testing

White Box Testing

Gray Box Testing

The levels of software testing life cycle includes :

Unit Testing

Integration Testing

System Testing

Acceptance Testing

1. Alpha Testing

2. Beta Testing

Other types of software testing are:

Functional Testing

Performance Testing

1. Load Testing

2. Stress Testing

Smoke Testing

Sanity Testing

Regression Testing

Recovery Testing

Usability Testing

Compatibility Testing

Configuaration Testing

Exploratory Testing

Automated Testing: Manual testing is a time consuming process. Automation testing involves

automating a manual process. Test automation is a process of writing a computer program in

the form of scripts to do a testing which would otherwise need to be done manually. Some of

the popular automation tools are Winrunner, Quick Test Professional (QTP), LoadRunner,

SilkTest, Rational Robot, etc. Automation tools category also includes maintenance tool such as

TestDirector and many other.

Software Testing Methodologies

The software testing methodologies or process includes various models that built the process of

working for a particular product. These models are as follows:

Waterfall Model

V Model

Spiral Model

Rational Unified Process(RUP)

Agile Model

Rapid Application Development(RAD)

Software Testing Artifacts

Software testing process can produce various artifacts such as:

Test Plan: A test specification is called a test plan. A test plan is documented so that it

can be used to verify and ensure that a product or system meets its design specification.

Traceability matrix: This is a table that correlates or design documents to test

documents. This verifies that the test results are correct and is also used to change tests

when the source documents are changed.

Test Case: Test cases and software testing strategies are used to check the functionality

of individual component that is integrated to give the resultant product. These test

cases are developed with the objective of judging the application for its capabilities or

features.

Test Data: When multiple sets of values or data are used to test the same functionality

of a particular feature in the test case, the test values and changeable environmental

components are collected in separate files and stored as test data.

Test Scripts: The test script is the combination of a test case, test procedure and test

data.

Test Suite: Test suite is a collection of test cases.

Software Testing Process

Software testing process is carried out in the following sequence, in order to find faults in the

software system:

1. Create Test Plan

2. Design Test Case

3. Write Test Case

4. Review Test Case

5. Execute Test Case

6. Examine Test Results

7. Perform Post-mortem Reviews

8. Budget after Experience

Here is a sample Test Case for you:

# Software Test Case for Login Page:

Purpose : The user should be able to go to the Home page.

Pre-requisite :

1. S/w should be compatible with the Operating system.

2. Login page should appear.

3. User Id and Password textboxes should be available with appropriate labels.

4. Submit and Cancel buttons with appropriate captions should be available.

Test Data : Required list of variables and their values should be available.eg: User Id:

{Valid UserId, Invalid UserId, empty}, Password:{Valid, Invalid, empty}.

Sr.No

Test

Case

Id

Test Case Name Steps/Action Expected Results

1. TC1.Checking User Interface

requirements.

User views the page to check

whether it includes UserId and

Password textboxes with

appropriate labels. Also expects

that Submit and Cancel buttons

are available with appropriate

captions

Screen dispalys user

interface requirements

according to the user.

2. TC2. Textbox for UserId

should:

i)allow only alpha-

numeric characters{a-z,

A-Z}

ii)not allow special

i)User types numbers into the

textbox.

i)Error message is

displayed for numeric

data.

ii)User types alphanumeric data

in the textbox.

ii)Text is accepted

when user enters

characters

like{'$','#','!','~','*',...}

iii)not allow numeric

alpha-numeric data

into the textbox.

3. TC3.

Checking functionality of

the Password textbox:

i)Textbox for Password

should accept more than

six characters.

ii)Data should be

displayed in encrypted

format.

i)User enters only two

characters in the password

textbox.

i)Error message is

displayed when user

enters less than six

characters in the

password textbox.

ii)User enters more than six

characters in the password

textbox.

System accepts data

when user enters more

than six characters into

the password textbox.

ii)User checks whether his data

is displayed in the encrypted

format.

System accepts data in

the encrypted format

else displays an error

message.

4. TC4.Checking functionality of

'SUBMIT' button.

i)User checks whether 'SUBMIT'

button is enabled or disabled.

i)System displays

'SUBMIT' button as

enabled

ii)User clicks on the 'SUBMIT'

button and expects to view the

'Home' page of the application.

ii)System is redirected

to the 'Home' page of

the application as soon

as he clicks on the

'SUBMIT' button.

5. TC5.Checking functionality of

'CANCEL' button.

i)User checks whether 'CANCEL'

button is enabled or disabled.

i)System displays

'CANCEL' button as

enabled.

ii)User checks whether the

textboxes for UserId and

Password are reset to blank by

clicking on the 'CANCEL' button.

ii)System clears the

data available in the

UserId and Password

textbox when user

clicks on the 'CANCEL'

button.

Fault Finding Techniques in Software Testing

Finding of a defect or fault in the earlier parts of the software not only saves time and money,

but is also efficient in terms of security and profitability. As we move forward towards the

different levels of the software, it becomes difficult and tedious to go back for finding the

problems in the initial conditions of the components. The cost of finding the defect also

increases. Thus it is recommended to start testing from the initial stages of the life cycle.

There are various techniques involved alongwith the types of software testing. There is a

procedure that is to be followed for finding a bug in the application. This procedure is combined

into the life cycle of the bug in the form of contents of a bug, depending upon the severity and

priority of that bug. This life cycle is named as the bug life cycles, which helps the tester in

answering the question - how to log a bug?

Measuring Software Testing

There arises a need of measuring the software, both, when the software is under development

and after the system is ready for use. Though it is difficult to measure such an abstract

constraint, it is essential to do so. The elements that are not able to be measured, needs to be

controlled. There are some important uses of measuring the software:

Software metrics helps in avoiding pitfalls such as

1. cost overruns,

2. in identifying where the problem has raised,

3. clarifying goals.

It answers questions such as:

1. What is the estimation of each process activity?,

2. How is the quality of the code that has been developed?,

3. How can the under developed code be improved?, etc.

It helps in judging the quality of the software, cost and effort estimation, collection of

data, productivity and performance evaluation.

Some of the common software metrics are:

Code Coverage

Cyclomatic complexity

Cohesion

Coupling

Function Point Analysis

Execution time

Source lines of code

Bug per lines of code

In short, measurement of a software is for understanding, controlling and improvement of the

software system. Software is subject to changes, with respect to, changing environmental

conditions, varying user requirements, as well as configuration and compatibility issues. This

gives rise to the development of newer and updated versions of software. But, there should be

some source of getting back to the older versions easily and working on them efficiently.

Testers play a vital role in this. Here is where change management comes into picture.

What is DDLC or Document Life Cycle?

DDLC means Document Development Life Cycle. In software industry there are main two types

of cycles SDLC and DDLC. Technical Writers are connected with Document Development Life

Cycle. Following is brief explanation of DDLC.

1. Understanding the Requirements

Understanding requirements is the first phase of the document development life

cycle. In this phase the technical writer is supposed to understand all the

requirements of the project. As per the project or document type technical

writer starts to gather the material that is useful for the project. The necessary

information is gathered and analyzed in this phase. In the beginning of the

project technical writer tries to understand what are the requirements of the

project and gathers material to build the project.

This process involves lot of efforts. Subject matter expert who is the genesis of

the knowledge provides information regarding the project. Technical writer

meets software developers and learns the features of the new product.

Technical writer resolves all the queries and problems regarding the project with

the help of SME and software developers. The help received from SME and

software developers is not sufficient to work on the project. Technical writer

searches the related information on online libraries and from the company

resource. Previous completed projects also help in building the new project if it

has some connections with the new one.

This phase can be called study of functional domain. Technical writer needs to

discuss the issues with knowledgeable people for the appropriate information

and guidance. Meeting with important people connected with the project proves

beneficial. This phase involves using and experimenting the product in various

ways that gives an idea about the new product. At the end of this phase

technical writer must have resolved all the problems and queries in terms of

understanding the documentation. Technical writer must study the software

from the technical point of view so that will be able to explain well in the

document for audience.

2.Audience Analysis

Technical writer writes documents or user manuals for the audience or users.

Audience is inseparable part of the documentation. Technical writer must know

the type of audience group that is going to use the product. There are varieties

of audience available Worldwide. Across the world all the audience are not at

the same level or similar in their usage and understanding of the product.

Audience varies as per the product. All the audience does not use all the

products. There are many types of audience but mainly categorized in two -

General Audience (Novice Audience) and Experienced Audience (Special

Audience).

These categories are based on the education and knowledge of user about the

product. Novice user is the person who is completely blank about the product

information. Novice user purchases the product on their knowledge that gained

from the society and tries to use it. Experienced users are completely contrary to

the novice audience. Special users have either complete or little bit knowledge of

product. Mostly educated people come under the category of special audience.

There are two sources to know your audience- Internal Source and External

Source. Internal source means to get knowledge about the audience from

software developers for whom they are making the product. You can also ask to

SME about an audience. Believe what the software developers and SME are

telling but don't rely on them. Try to find out the information about your

audience from external sources means vising actual audience who are going to

use the product.

3.Outlining the Document

This phase helps you to create the outline of the document. Outlining the

document is the overall plan of the document. It is the skeletal framework of

your document. It shows overall structure of the document. Outline of the

document do not contain the elements in explained way but in brief. In this

phase you just put all the elements serially to expand them so that you won't

miss any one of the elements from document. Outlining the document is the

well defined plan that can be discussed explicitly. Outline of the document is

similar to the skeleton without flesh. Outline gives an idea about the placement

of the elements in the Ad. The skeletal information comprises of Preface or

introduction, Table of Contents, Chapter information/sequence, index,

bibliography etc. Technical writer only needs to explain all the elements once the

plan is ready. Outline of the document gives the clear view of the complete

document at a glance.

4.Preparing Prototype

A style guide or style manual is a set of standards for design and writing of

documents, either for general use or for a specific publication or organization.

Preparing prototype comprises of several important stages such as template

consideration, developing Style Guides etc.

Template Consideration- Template is the physical appearance of the document.

While deciding template you need to decide all the specifications and standards

regarding the template of the Ad. Page size, page margins, fonts, headings, list

types, alignments, gutter space, etc are to be supposed while contemplating the

template. Once the template is ready develop the contents in main sections and

prepare a detailed design.

Style Guides- Style guides are particularly important in technical writing projects.

A style guide or style manual is a set of standards for design and writing of

documents, either for general use or for a specific publication or organization.

Where technical writing is undertaken in a large team or project, it is important

that the finished documentation is devoid of any one individual's discernible

personal style. A style guide is just one of the tools that can be used to help

achieve this along with 5the use of specific standards. Style guide is the guide of

rules and regulations that are followed by every person working on the project.

Microsoft style Guide for Technical Publication is the best industry standard style

guide that is used in most of the companies.

5.Developing Actual Help System

In this phase the actual development of help system starts. Technical writer

explains all the contents that are collected and planned in outlining phase. This

phase gives birth to the document. The duration of this phase is greater than the

other phases. Once the template is defined all the contents are explained

explicitly in the document. Detailed table of contents is created with page

numbers in this stage. Cross references are created and maintained. Glossary

and index is created after completion of the document. In this stage technical

writer needs to perform all the actions that are supposed to build complete

document.

6.Review

Review means to check the Document for any errors and some other

corrections. There re three types of reviews- Peer Review, Technical review and

Functional Review.

Peer review- Peer review (also known as refereeing) is the process of subjecting

an author's work, research or ideas to the scrutiny of others who are experts in

the same field. Peer review requires a community of experts in a given field, who

are qualified and able to perform impartial review. Impartial review, especially of

work in less narrowly defined or inter-disciplinary fields, may be difficult to

accomplish; and the significance (good or bad) of an idea may never be widely

appreciated among its contemporaries. Peer review has been criticized as

ineffective, slow, and misunderstood This process encourages authors to meet

the accepted standards of their discipline and prevents the dissemination of

irrelevant findings, unwarranted claims, unacceptable interpretations, and

personal views. Publications that have not undergone peer review are likely to

be regarded with suspicion by scholars and professionals.

Technical Review- The purpose of a technical review is to arrive at a technically

superior version of the work product reviewed, whether by correction of defects

or by recommendation or introduction of alternative approaches. A technical

review is a form of peer review in which "a team of qualified personnel ...

examines the suitability of the documents for its intended use and identifies

discrepancies from specifications and standards. Technical reviews may also

provide recommendations of alternatives and examination of various

alternatives"

7.Packaging

Packaging means making the product ready to deliver to the client. There are

two types of Packaging- Book design and binding, Integrating help in Application.

If the help manual is in book format which is supposed to go along with the

product, goes for printing to produce copies. Online help is integrated with the

help of software developers in the respective application. Online help is always

delivered with the help of CD or the devices that can be used to carried out the

data. There are different types of delivering the help to the clients depending on

the product.

2. SDLC

The SDLC process was designed to ensure end-state solutions meet user requirements in

support of business strategic goals and objectives. In addition, the SDLC also provides a detailed

guide to help Program Managers with ALL aspects of IT system development, regardless of the

system size and scope. The SDLC contains a comprehensive checklist of the rules and

regulations governing IT systems, and is one way to ensure system developers comply with all

applicable Government regulations, because the consequences of not doing so are high and

wide ranging. This is especially true in the post 9/11 environment where larger amounts of

information are considered sensitive in nature, and are shared among commercial,

international, Federal, state, and local partners.

The seven-step process contains a procedural checklist and the systematic progression required

to evolve an IT system from conception to disposition. The following descriptions briefly explain

each of the seven phases of the SDLC:

1. Conceptual Planning. This phase is the first step of any system's life cycle. It is during this

phase that a need to acquire or significantly enhance a system is identified, its feasibility and

costs are assessed, and the risks and various project-planning approaches are defined. Roles

and responsibilities for the Asset Manager, Sponsor's Representative, System Development

Agent (SDA), System Support Agent (SSA), and other parties in SDLC policy are designated

during this stage and updated throughout the system's life cycle.

2. Planning and Requirements Definition. This phase begins after the project has been defined

and appropriate resources have been committed. The first portion of this phase involves

collecting, defining and validating functional, support and training requirements. The second

part is developing initial life cycle management plans, including project planning, project

management, Configuration Management (CM), support, operations, and training

management.

3. Design. During this phase, functional, support and training requirements are translated into

preliminary and detailed designs. Decisions are made to address how the system will meet

functional requirements. A preliminary (general) system design, emphasizing the functional

features of the system, is produced as a high-level guide. Then a final (detailed) system design is

produced that expands the design by specifying all the technical detail needed to develop the

system.

4. Development and Testing. During this phase, systems are developed or acquired based on

detailed design specifications. The system is validated through a sequence of unit, integration,

performance, system, and acceptance testing. The objective is to ensure that the system

functions as expected and that sponsor's requirements are satisfied. All system components,

communications, applications, procedures, and associated documentation are

eveloped/acquired, tested, and integrated. This phase requires strong user participation in

order to verify thorough testing of all requirements and to meet all business needs.

5. Implementation. During this phase, the new or enhanced system is installed in the

production environment, users are trained, data is converted (as needed), the system is turned

over to the sponsor, and business processes are evaluated. This phase includes efforts required

to implement, resolve system problems identified during the implementation process, and plan

for sustainment.

6. Operations and Maintenance. The system becomes operational during this phase. The

emphasis during this phase is to ensure that sponsor needs continue to be met and that the

system continues to perform according to specifications. Routine hardware and software

maintenance and upgrades are performed to ensure effective system operations. User training

continues during this phase, as needed, to acquaint new users to the system or to introduce

new features to current users. Additional user support is provided, as an ongoing activity, to

help resolve reported problems.

7. Disposition. This phase represents the end of the system's life cycle. It provides for the

systematic termination of a system to ensure that vital information is preserved for potential

future access and/or reactivation. The system, when placed in the Disposition Phase, has been

declared surplus and/or obsolete and has been scheduled for shutdown. The emphasis of this

phase is to ensure that the system (e.g., equipment, parts, software, data, procedures, and

documentation) is packaged and disposed of in accordance with appropriate regulations and

requirements.

Each column in the graphic represents an individual phase. The documents in each phase are

created and maintained throughout the rest of the development cycles until the final

disposition of the project. Although this indicates the process is linear, it is not. It is iterative

and once a project is deployed, the management of the project may return to requirements

gathering to start all over again.

Avison and Fitzgerald in their book Information Systems Development: Methodologies,

Techniques and Tools describe the Systems Development Life Cycle:

This methodology has the following steps:

Feasibility study

System investigation

Systems analysis

Systems design

Implementation

Review and maintenance

These stages together are frequently referred to simply as [...] the 'waterfall

model'. (see WaterfallModel)

They go on to say:

The term 'life-cycle' indicates the iterative nature of the process...

This methodology, they say, was described completely in 1971 by Daniels and Yeates (Basic

Training in Systems Analysis. 2nd ed., Pitman, London).

It has some interesting features that make it, to my mind, less abstract than the pure (and

perhaps mythical) WaterfallModel. Each phase is considered in the context of the current

system. The second stage is essential grounding for this. Here the systems analyst tries

to see the problems and not just hear them. She tries to become the customer.

The next stage, 'Systems analysis', may go beyond what the customer knows. It explores the

history of the system. It asks how and why is has developed this way. Should the procedures of

today be automated, or should the system take a new direction?

There is a conspicuous lack of references to programming in this model. The idea, I think, is that

certain problems are best fixed at the systems level. You don't always have to dive for the

keyboard. Some other areas that the SDLC thinks important: Legal and social feasibility, the

purchase and installation of hardware and software as an implementation consideration and

the consideration of future scalability. All things I'm happy to see at least mentioned.

What is Software Development Life Cycle?

The Software Development Life Cycle is a step-by-step process involved in the development of a

software product. It is also denoted as Software Development process in certain parts of the

world. The whole process is generally classified into a set of steps and a specific operation will

be carried out in each of the steps.

Classification

The basic classification of the whole process is as follows

Planning

Analysis

Design

Development

Implementation

Testing

Deployment

Maintenance

Each of the steps of the process has its own importance and plays a significant part in the

product development. The description of each of the steps can give a better understanding.

Planning

This is the first and foremost stage in the development and one of the most important stages.

The basic motive is to plan the total project and to estimate the merits and demerits of the

project. The Planning phase includes the definition of the intended system, development of the

project plan, and Parallel management of the plan throughout the proceedings of the

development.

A good and matured plan can create a very good initiative and can positively affect the

complete project.

Analysis

The main aim of the analysis phase is to perform statistics and requirements gathering. Based

on the analysis of the project and due to the influence of the results of the planning phase, the

requirements for the project are decided and gathered.

Once the requirements for the project are gathered, they are prioritized and made ready for

further use. The decisions taken in the analysis phase are out and out due to the requirements

analysis. Proceedings after the current phase are defined.

Design

Once the analysis is over, the design phase begins. The aim is to create the architecture of the

total system. This is one of the important stages of the process and serves to be a benchmark

stage since the errors performed until this stage and during this stage can be cleared here.

Most of the developers have the habit of developing a prototype of the entire software and

represent the software as a miniature model. The flaws, both technical and design, can be

found and removed and the entire process can be redesigned.

Development and Implementation

The development and implementation phase is the most important phase since it is the phase

where the main part of the project is done. The basic works include the design of the basic

technical architecture and the maintenance of the database records and programs related to

the development process.

One of the main scenarios is the implementation of the prototype model into a full-fledged

working environment, which is the final product or software.

Testing

The testing phase is one of the final stages of the development process and this is the phase

where the final adjustments are made before presenting the completely developed software to

the end-user.

In general, the testers encounter the problem of removing the logical errors and bugs. The test

conditions which are decided in the analysis phase are applied to the system and if the output

obtained is equal to the intended output, it means that the software is ready to be provided to

the user.

Maintenance

The toughest job is encountered in the maintenance phase which normally accounts for the

highest amount of money. The maintenance team is decided such that they monitor on the

change in organization of the software and report to the developers, in case a need arises.

The information desk is also provided with in this phase. This serves to maintain the

relationship between the user and the creator.

A software development process is a structure imposed on the development of a software

product. Similar terms include software life cycle and software process. There are

several models for such processes, each describing approaches to a variety of tasks or

activities that take place during the process. Some people consider a lifecycle model a more

general term and a software development process a more specific term. For example, there are

many specific software development processes that 'fit' the spiral lifecycle model.

Contents

[hide]

1 Overview

2 Software development activities

o 2.1 Planning

o 2.2 Implementation, testing and documenting

o 2.3 Deployment and maintenance

3 Software Development Models

o 3.1 Waterfall Model

o 3.2 Spiral Model

o 3.3 Iterative and Incremental Development

o 3.4 Agile Development

4 Process Improvement Models

5 Formal methods

6 See also

7 References

8 External links

[edit]Overview

The large and growing body of software development organizations implement process

methodologies. Many of them are in the defense industry, which in the U.S. requires a rating

based on 'process models' to obtain contracts.

The international standard for describing the method of selecting, implementing and

monitoring the life cycle for software is ISO 12207.

A decades-long goal has been to find repeatable, predictable processes that improve

productivity and quality. Some try to systematize or formalize the seemingly unruly task of

writing software. Others apply project management techniques to writing software. Without

project management, software projects can easily be delivered late or over budget. With large

numbers of software projects not meeting their expectations in terms of functionality, cost, or

delivery schedule, effective project management appears to be lacking.

Organizations may create a Software Engineering Process Group (SEPG), which is the focal point

for process improvement. Composed of line practitioners who have varied skills, the group is at

the center of the collaborative effort of everyone in the organization who is involved with

software engineering process improvement.

[edit]Software development activities

The activities of the software development process represented in the waterfall model. There

are several other models to represent this process.

Planning

The important task in creating a software product is extracting

the requirements or requirements analysis. Customers typically have an abstract idea of what

they want as an end result, but not what software should do. Incomplete, ambiguous, or even

contradictory requirements are recognized by skilled and experienced software engineers at

this point. Frequently demonstrating live code may help reduce the risk that the requirements

are incorrect.

Once the general requirements are gathered from the client, an analysis of the scope of the

development should be determined and clearly stated. This is often called a scope document.

Certain functionality may be out of scope of the project as a function of cost or as a result of

unclear requirements at the start of development. If the development is done externally, this

document can be considered a legal document so that if there are ever disputes, any ambiguity

of what was promised to the client can be clarified.

Implementation, testing and documenting

Implementation is the part of the process where software engineers actually program the code

for the project.

Software testing is an integral and important part of the software development process. This

part of the process ensures that defects are recognized as early as possible.

Documenting the internal design of software for the purpose of future maintenance and

enhancement is done throughout development. This may also include the writing of an API, be

it external or internal. It is very important to document everything in the project.

Deployment and maintenance

Deployment starts after the code is appropriately tested, is approved for release and sold or

otherwise distributed into a production environment.

Software Training and Support is important and a lot of developers fail to realize that. It would

not matter how much time and planning a development team puts into creating software if

nobody in an organization ends up using it. People are often resistant to change and avoid

venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to

have training classes for new clients of your software.

Maintaining and enhancing software to cope with newly discovered problems or new

requirements can take far more time than the initial development of the software. It may be

necessary to add code that does not fit the original design to correct an unforeseen problem or

it may be that a customer is requesting more functionality and code can be added to

accommodate their requests. If the labor cost of the maintenance phase exceeds 25% of the

prior-phases' labor cost, then it is likely that the overall quality of at least one prior phase is

poor.[citation needed] In that case, management should consider the option of rebuilding the system

(or portions) before maintenance cost is out of control.

Bug Tracking System tools are often deployed at this stage of the process to allow development

teams to interface with customer/field teams testing the software to identify any real or

perceived issues. These software tools, both open source and commercially licensed, provide a

customizable process to acquire, review, acknowledge, and respond to reported issues.

(software maintenance)

Waterfall Model Diagram

Since the time it was first published by Winston W. Royce in 1970, the waterfall model has been

used widely in the field of software development. Here, in this article, we will take a look at the

waterfall model diagram and try to understand how software development takes place, while

following this model...

Because of its various advantages, the waterfall model diagram has been in use in the field of

software development for ages. No doubt there are certain disadvantages in this system too.

However, we can understand the advantages and disadvantages of the system better in

getting the waterfall model explained by taking a brief look at the waterfall diagram.

Waterfall Model Diagram

Waterfall Model Diagram - Explained

Let us now take a look at the different phases of the waterfall model diagram. One important

aspect that is worth mentioning before we start off with the waterfall model life cycle is that

the waterfall model is designed such that, until the preceding phase is complete, you cannot

move over to the next phase of development.

Requirement

Unless you know what you want to design, you cannot proceed with the project. Not only big

projects, but even a small code of adding two integer numbers also needs to be written with

the output in mind. Here, in this stage, the requirements which the software is going to satisfy

is specified. All requirements are presented to the team of programmers. If this phase is

completed successfully, it ensures a smooth working of the remaining waterfall model phases,

as the programmer is not burdened to make changes at later stages because of changing

requirements.

Analysis

As per the requirements, the software and hardware for the proper completion of the project is

analyzed in this phase. Right from the point of which computer language should be used for the

designing of the software, to the database system that can be used for the smooth functioning

of the software is decided at this stage.

Design

The algorithm or flowchart of the program or the software code to be written in the next stage

is created now. It is a very important stage, which relies on the previous two stages for its

proper implementation and the proper execution of the same ensures a smooth working of the

next stage. If during the design phase it can be made out that there are some more

requirements for designing the code, it is added up to the list in the analysis phase and the

design phase is carried out according to the new set of resources.

Coding

Based on the algorithm or flowchart designed, the actual coding of the software is carried out.

This is the stage where the entire idea of the software of program to be designed is

materialized. A proper execution of the previous stages ensures a smooth implementation of

this stage.

Testing

With the coding complete, the testing department now comes into scene. It checks out if there

are any flaws in the designed software and if the software has been designed as per the

specifications. A proper execution of this stage ensures that the client for which the software

has been designed, will be satisfied with the work. If there are any flaws, the problem is

reverted back to the design phase. In the design phase, the changes are implemented and then

its succeeding stages, coding and testing are again carried out. Read more on software testing.

Acceptance

This is the last stage of the software development, using the waterfall model. A proper

execution of all the preceding stages ensures a software as per the requirements and most

importantly, it ensures a satisfied client. However, at this stage you may need to provide the

client with some support regarding the software you have developed. If the client demands

some further enhancements to be made to the existing software, then the process again needs

to be started, right from the first phase, i.e., requirements.

Read more on

Waterfall - Software Development Model

Waterfall Model - Advantages and Disadvantages

The waterfall model in software engineering continues to remain one of the most commonly

used methodologies. No doubt, new systems have been used, but the widespread use of

waterfall model is still the reason why it is studied in various software management subjects.

With the waterfall model diagram in hand, you will not have much difficulty in understanding

the process of software development using this method. This is not only one of the simple

software process models for application development, but it is also known for its ease of

implementation in the field of software development.

Software development, like any other business process, has certain targeted goals which must

be achieved in a fixed frame of time. There are various strategies for achieving these software

development goals. Two of the most popular software development models are the 'Waterfall

Model' and the 'Agile Model'. This article makes a waterfall model vs agile model comparison,

that will serve to point out the differences in the two different methods of software

development.

Waterfall Model Vs Agile Model: History

Before we get into comparing waterfall model vs agile model, let us have a look at the

developmental history of these two models. Waterfall model in software engineering got

formally introduced as an idea, through a paper published by Winston Royce in 1970. However,

ironically, he himself had introduced it as a flawed method of software development,

vulnerable due to its many shortcomings. Every methodology has takers and waterfall model

has been successfully implemented by many software companies. The waterfall model

philosophy was inherited from the hardware manufacture strategies and construction

strategies that were in practice during the 1970s. That is why it has a very structured approach

to software development. Waterfall model explained later will clarify what I am trying to say

here.

On the other hand, the agile model of software development evolved in the 1990s when

developers decided to break away from traditional structured, segmented, bureaucratic

approaches to software development and move towards more flexible development styles. The

'Agile' or 'Light Weight' methods as they were called, were formally defined in a research paper

by Edmonds in 1974. Some of the most prominent and popular agile methods of software

development, that subsequently evolved are 'Scrum' in 1995, 'Crystal Clear', 'Extreme

Programming' in 1996, 'Adaptive Software Development', 'Dynamic Systems Development

Method' in 1995 and 'Feature Driven Development'. In 2001, a group of pioneers in agile

software development came together and declared the 'Agile Manifesto', which is a set of

canonical rules of sorts for, agile software development methods.

Waterfall Model Vs Agile Model: Conceptual Difference

After the short interlude of history, let us start the actual waterfall model vs agile model

comparison, by starting with the major conceptual differences in the two approaches. Then we

will compare the difference in software development life cycle, involved in both approaches.

Let us discuss the waterfall model advantages and disadvantages after delving into the main

concept. Waterfall model of software development, as the name itself signifies, is a sequential

process of software development. Like in a waterfall, the water progressively falls from one

altitude to the lower, in a similar way, the production cycle progresses sequentially, from one

stage to the other (illustrated by a waterfall model diagram in textbooks). The waterfall model

phases of software development are as follows: requirement specification, conception, analysis,

design, coding, testing & debugging, installation and finally maintenance. In this sequentially

structured approach, the development team goes ahead to the next stage of development only

after the first is fully accomplished. Software development companies adopting this model

spend considerable amount of time in each stage of development, till all doubts are cleared and

all requirements are met. The belief that drives this kind of software development model is that

considerable time spent in initial design effort corrects bugs in advance. Once the design stage

is over, it is implemented exactly in the coding stage, with no changes later. Often the analysis,

design and coding teams are separated and work on small parts in the whole developmental

process. Emphasis is placed on documentation of every stage of software development.

Now let us have a look at the agile software development method. Compared to the 'set-in-

stone' approach of waterfall development models, the agile models, as the title suggest,

focuses on 'agility' and 'adaptability' in development. Instead of one time consuming and rigid

development schedule, agile models involve multiple iterative development schedules that

seek to improve the output with every iteration. Each iteration goes through the all the steps of

design, coding and testing. The design is not set in stone and is kept open to last minute

changes due to iterative implementation. The team structure is cross functional, closely knit

and self-organizing. The design idea is never totally frozen or set in stone but is allowed to

evolve as new ideas come in with each release. Less importance is given to documentation than

speed of delivering a working program.

Waterfall Model Vs Agile Model: Efficiency

In the ongoing comparison of waterfall model vs agile model, let us see how these two

ideologies compare with respect to development efficiency. Efficiency is decided by the quality

of ultimate software product, the number of bugs and the development time consumed.

Through my own research into the working of both these models, I found the agile models to

be more efficient than the waterfall model, due to its adaptability to the real world. The 'One

Phase' and 'Rigid' development cycle makes it difficult to make last minute changes in

requirements or design. While the agile methods, due to their iterative and adaptable nature,

can incorporate changes and release a product in lesser time. Of course, agile models are not

perfect either, but they are certainly more widely applicable than the waterfall model.

Waterfall Model Vs Agile Model: Suitability

The water fall model is suited for development of programs that are already stable. That is,

their design does not need a major makeover. In situations where the designers of a software

can accurately predict the flaws that may arise can be developed through a waterfall model.

Despite all its flaws, a waterfall model design is easier to manage and the development costs

can be ascertained before hand.

Agile models are applicable in every area of software development. It depends a lot more on

the team effort of above average programmers, than relying on a few expert programmers. It is

best suited for web based applications where its iterative nature helps in incorporating and

correcting the various bugs that arise over time.

So, this was a waterfall model vs agile model comparison, that tried to compare the basic

differences between the two. What is ideally needed is a model which combines the

accountability and predictability of a waterfall model with the agility and adaptability of the

agile model. That is, an effective balance between the two ideologies can create a more

efficient software development model.

Waterfall Model Life Cycle

One of the oldest model used in software development is the waterfall software development

life cycle model. The origin of this model is in the manufacturing and construction industry.

Since formal software development methods did not exist at that time, this hardware oriented

model was adapted for software development as well. Scroll down to know more about

waterfall model life cycle.

Enlarge Image

Software Development Model - Waterfall Model Life Cycle

The waterfall model in software engineering was originally designed in 1970 by Winston W.

Royce. However, the model was not named as ‘waterfall’ model. In this model there is

sequential progression from one phase to another. To elaborate this further, after the first

phase is completed, it is considered as a stepping stone to the next phase. The phases in

the waterfall - software development model are requirement analysis and project planning,

system design and specification, coding and verification, system integration and testing and not

to forget deployment and maintenance phase. Here is the the waterfall model explained.

Requirement Analysis and Project Planning

In this first stage of waterfall model diagram, there is a meeting with the customer, to

understand the requirements. The first stage, this is said to be the most crucial stage, as any

miscommunication and misinterpretation at this stage may give rise to the software, that is

been developed. When the requirements are been noted, it is important to make sure the

requirements are detailed and accurate and there is no place for any ambiguity. Understanding

the requirements and expectations of the customer properly will ensure, that the end product

meets the specification.

System Design

The requirements, that are gathered in the previous phase are broken down into logical units,

so that the software process becomes easy for implementation. This is the stage, when the

software requirements along with the hardware requirements for every unit are identified.

Then the designs are made accordingly. The interrelation between the various units of the

software are identified and the connections are made, using algorithms and diagrams. To sum it

up, this is the phase, where the fundamental work for actual programming and implementation

is done.

System Implementation

In this phase the actual development of the software takes place. This phase is also known as

coding and verification phase. Based on the algorithms written in the previous phase, software

program is written. For every module, software code is written and tested, to check if the

correct output is received.

System Integration and Testing

Now all the modules are integrated, after which the software is tested for correct output. All

the bugs, that are made, due to integration are removed. Then software testing is carried out

again. They are normally a series of tests, which are run to check the performance of the

software, and also to find if any new bugs were introduced into the system, after the previous

bugs were fixed. If any more errors do exist, the bugs are fixed only to be retested.

The waterfall model in testing is followed, to make the software bug free, as far as possible.

System Deployment and Maintenance

This makes for the final phase of the waterfall model, where the software is deployed at the

clients side, after it has undergone thorough testing. After the deployment of the software,

routine maintenance work is carried out. Once the software has been deployed, in case the

customer asks for any changes or enhancements, then the entire process is restarted. You may

want to read on waterfall model vs agile.

There are various waterfall model advantages and disadvantages. The biggest advantage of this

model is that, the phases are completed one at a time. However, the biggest disadvantage is

that it is laborious, when any changes are to be made to the system. To sum up waterfall model

life cycle in short, this model requires, that one moves from one phase to another, only after

the preceding phase is completed satisfactorily. At the same time, it should not be forgotten,

that various waterfall models may include slight or major variations in the process.

Waterfall Model Phases

Waterfall model is one of the most preferred and widely implemented software design

principles. The ease of implementation and the systematic approach at various phases in

waterfall model make it the most sought after model among software professionals. Read on to

know more on waterfall model phases.

What is the Waterfall Model

Waterfall model in software engineering is basically a development approach which follows a

'top down' mechanism. The development process goes through several phases to meet the

customer's specifications and requirements. One distinguishing feature of waterfall model that

sets it apart from other software development models is that, in this method there is no

simultaneous execution of two phases. The second phase begins only when the preceding

phase has been completely implemented. This approach is very simple to implement and there

is transparency at every stage. Review meetings are conducted at the end of every stage to

verify whether the development process is on track and meets the customer requirements.

Systematic documentation is done at every phase of waterfall model. More on waterfall model

vs agile.

Waterfall Model Phases

Given below are the various phases of waterfall model. Although, the phase name may differ

for every software organization, the basic implementation steps remain the same. Also

refer waterfall model diagram.

Requirement Analysis and Software Definition

This is the first phase of waterfall model which includes a meeting with the customer to

understand his requirements. This is the most crucial phase as any misinterpretation at this

stage may give rise to validation issues later. The software definition must be detailed and

accurate with no ambiguities. It is very important to understand the customer requirements

and expectations so that the end product meets his specifications.

System Design

The customer requirements are broken down into logical modules for the ease of

implementation. Hardware and software requirements for every module are identified and

designed accordingly. Also the inter relation between the various logical modules is established

at this stage. Algorithms and diagrams defining the scope and objective of each logical model

are developed. In short, this phase lays a fundamental for actual programming and

implementation.

System Implementation

This is the software process in which actual coding takes place. A software program is written

based upon the algorithm designed in the system design phase. A piece of code is written for

every module and checked for the output.

System Testing

The programmatically implemented software module is tested for the correct output. Bugs,

errors are removed at this stage. In the process ofsoftware testing, a series of tests and test

cases are performed to check the module for bugs, faults and other errors. Erroneous codes are

rewritten and tested again until desired output is achieved. More on waterfall model in testing.

System Deployment and Maintenance

This is the final phase of the waterfall model, in which the completed software product is

handed over to the client after alpha, beta testing. After the software has been deployed on the

client site, it is the duty of the software development team to undertake routine maintenance

activities by visiting the client site. If the customer suggests changes or enhancements the

software process has to be followed all over again right from the first phase i.e requirement

analysis. This is the biggest shortcoming of the waterfall model.

Thus, waterfall model is easy to implement and more often than not produces desired results.

The inter-dependence of waterfall model phases may lead to developmental issues, if a

systematic approach is not followed at each step. However, in spite of these shortcomings,

waterfall model is adopted all across the world.

Waterfall Model Advantages and Disadvantages

Anyone working in the field of software development will of course be aware of the famous

waterfall model. It is nothing but the life cycle through which a project goes. Here, in this

article, we will try to be aware of the waterfall model advantages and disadvantages...

The original waterfall model, published by Winston W. Royce in 1970, was in fact not identified

by the very name with which we know it today. Royce, in fact, presented the model as a flawed

and non-working model. But because of the various advantages that this approach towards

software designing and implementation presented, it soon became very popular in the world of

software development. However, before going into the waterfall model advantages and

disadvantages, here is the waterfall model explained briefly. Read more on waterfall - software

development model.

Waterfall Model - Software Development Model

The most important aspect of the waterfall model is that none of the stages can be started off

with before the preceding stage is complete. The software life cycle has to follow the sequence.

The original waterfall model designed by Royce consisted of the following seven stages:

Specification of Requirements

Design

Construction

Integration

Testing and Debugging

Installation

Maintenance

However, various modifications were brought over to this waterfall model as and when

required. Here, in this article, we will try to understand a simple waterfall model, broken into

six stages. There is a seventh stage which is same as that of the first stage, requirements, but it

follows the last stage and is referred to as updated maintenance. Let us try to understand each

of these stages one by one.

Stage 1: Requirement Phase

Whether you design a small program to add two numbers or you are into developing a software

system for the automation of an entire airline company, this is the first stage which can never

be overridden. Unless you know what you are going to design, you cannot approach the

problem. Here, the specifications of the output or the final product is studied and marked. If

the software that is going to be designed should not contain certain features, for reasons like

security, then it is also mentioned in this stage.

Stage 2: Specification Phase

With all the requirements and constraints in hand, a final view of how the product should

exactly be, is decided. The exact way in which the software should function is mentioned in this

stage.

Stage 3: Design Phase

Well, here the actual work begins. Every type of resource which will be required for the smooth

designing of the software is mentioned here in this phase. What type of database will be

required, what type of data should be supported, etc. are some of the important aspects that

are decided in this phase. The algorithm of the process in which the software needs to be

designed is made in this phase. This algorithm forms the backbone for the actual coding part in

the next phase.

Stage 4: Implementation and Testing Phase

Now starts the coding part. Here, the software is designed as per the algorithm. Hence it

becomes very important that the algorithm should be properly designed. The software

designed as per the algorithm needs to go through constant software testing and error

correction processes to find out if there are any flaw or errors. The output of this stage should

be a well designed software which is at par with the algorithm designed.

Stage 5: Integration and Testing Phase

Here the various codes designed by different programmers are integrated together and is

tested if the software works as per the specifications provided. The setup of the final software

which needs to be installed at the clients system is also designed and tested so that the client

does not face any problem during the installation of the software. The product is then handed

over to the client.

Stage 6: Maintenance Phase

The work of software development does not end with the handing of the software to the client.

The software designers may have to constantly provide support to the client to resolve any of

the issues which may arise. There may be some flaws which get detected during the actual

implementation of the project. During the maintenance phase, support and debugging is

provided for all such problems.

Stage 7: New Requirements Phase

Changing times may require that the product requirements be changed. The client company

may be expanding into other fields and it may want new features to be added over to the

existing software. Hence, it is very important that the updated requirements be taken from the

client. This requires the entire product life cycle to start all over again.

Now, I hope that the small explanation given above must have helped you in understanding the

waterfall model. With this knowledge in hand, let us try to understand the advantages and

disadvantages of waterfall model. Read more on waterfall model in software engineering.

Waterfall Model Advantages and Disadvantages

Let us now try to answer the basic question, what are the advantages and disadvantages of

waterfall model?

Advantages of Waterfall Model

The waterfall model is the oldest and most widely used model in the field of software

development. There are certain advantages of the waterfall model, which causes it to be the

most widely used model as yet. Some of them can be listed as under.

Needless to mention, it is a linear model and of course, linear models are the most

simple to be implemented.

The amount of resources required to implement this model is very minimal.

One great advantage of the waterfall model is that documentation is produced at every

stage of the waterfall model development. This makes the understanding of the product

designing procedure simpler.

After every major stage of software coding, testing is done to check the correct running

of the code.

Disadvantages of Waterfall Model

The question that must be bothering you now is that with so many advantages at hand, what

could be the possible disadvantages of the waterfall model. Well, there are some disadvantages

of this widely accepted model too. Let us look at a few of them.

Ironically, the biggest disadvantage of the waterfall model is one of its greatest

advantage. You cannot go back, if the design phase has gone wrong, things can get very

complicated in the implementation phase.

Many a times, it happens that the client is not very clear of what he exactly wants from

the software. Any changes that he mentions in between may cause a lot of confusion.

Small changes or errors that arise in the completed software may cause a lot of

problem.

The greatest disadvantage of the waterfall model is that until the final stage of the

development cycle is complete, a working model of the software does not lie in the

hands of the client. Thus, he is hardly in a position to mention if what has been designed

is exactly what he had asked for

The waterfall model, as already mentioned, is of course the most widely used model. There are

various versions of the same, which allow some waterfall model phases to overlap or feedback

to be taken after each phase, which make designing the software a lot more simpler. So this, in

short, was all about waterfall model advantages and disadvantages. In spite of the

disadvantages, the many advantages of this model ensure that it remains one of the most

popular models used in the field of software development.

Waterfall model

The waterfall model is a sequential software development process, in which progress is seen as

flowing steadily downwards (like a waterfall) through the phases of Conception,

Initiation, Analysis, Design, Construction, Testing andMaintenance.

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

Software development process

Activities and steps

Requirements · Specification

Architecture · Design

Implementation · Testing

Deployment · Maintenance

Methodologies

Agile · Cleanroom ·

Iterative · RAD · RUP · Spiral

Waterfall · Lean

V-Model · TDD

Supporting disciplines

Configuration management

Documentation

Quality assurance (SQA)

Project management

User experience design

Tools

Compiler · Debugger · Profiler

GUI designer

Integrated development environment

v • d • e

The waterfall development model has its origins 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.

The first formal description of the waterfall model is often cited to be an article published in

1970 byWinston W. Royce,[1] although Royce did not use the term "waterfall" in this article.

Royce was presenting this model as an example of a flawed, non-working model (Royce 1970).

This is in fact the way the term has generally been used in writing about software development

—as a way to criticize a commonly used software practice.[2]

Contents

[hide]

1 Model

2 Supporting arguments

3 Criticism

4 Modified models

5 See also

6 References

7 Further reading

8 External links

[edit]Model

In Royce's original waterfall model, the following phases are followed in order:

1. Requirements specification

2. Design

3. Construction (AKA implementation or coding)

4. Integration

5. Testing and debugging (AKA Validation)

6. Installation

7. Maintenance

To follow the waterfall model, one proceeds from one phase to the next in a sequential

manner. For example, one first completes requirements specification, which after sign-off are

considered "set in stone." When the requirements are fully completed, one proceeds to design.

The software in question is designed and a blueprint is drawn for implementers (coders) to

follow — this design should be a plan for implementing the requirements given. When the

design is fully completed, an implementation of that design is made by coders. Towards the

later stages of this implementation phase, separate software components produced are

combined to introduce new functionality and reduced risk through the removal of errors.

Thus the waterfall model maintains that one should move to a phase only when its preceding

phase is completed and perfected. However, there are various modified waterfall

models (including Royce's final model) that may include slight or major variations upon this

process.

[edit]Supporting arguments

Time spent early in the software production cycle can lead to greater economy at later stages. It

has been shown that a bug found in the early stages (such as requirements specification or

design) is cheaper in terms of money, effort and time, to fix than the same bug found later on in

the process. ([McConnell 1996], p. 72, estimates that "a requirements defect that is left

undetected until construction or maintenance will cost 50 to 200 times as much to fix as it

would have cost to fix at requirements time.") To take an extreme example, if a program design

turns out to be impossible to implement, it is easier to fix the design at the design stage than to

realize months later, when program components are being integrated, that all the work done so

far has to be scrapped because of a broken design.

This is the central idea behind Big Design Up Front (BDUF) and the waterfall model - time spent

early on making sure that requirements and design are absolutely correct will save you much

time and effort later. Thus, the thinking of those who follow the waterfall process goes, one

should make sure that each phase is 100% complete and absolutely correct before proceeding

to the next phase of program creation. Program requirements should be set in stone before

design is started (otherwise work put into a design based on incorrect requirements is wasted);

the program's design should be perfect before people begin work on implementing the design

(otherwise they are implementing the wrong design and their work is wasted), etc.

A further argument for the waterfall model is that it places emphasis on documentation (such

as requirements documents and design documents) as well as source code. In less designed and

documented methodologies, should team members leave, much knowledge is lost and may be

difficult for a project to recover from. Should a fully working design document be present (as is

the intent of Big Design Up Front and the waterfall model) new team members or even entirely

new teams should be able to familiarize themselves by reading the documents.

As well as the above, some prefer the waterfall model for its simple approach and argue that it

is more disciplined. Rather than what the waterfall adherent sees as chaos, the waterfall model

provides a structured approach; the model itself progresses linearly through discrete, easily

understandable and explainable phases and thus is easy to understand; it also provides easily

markable milestones in the development process. It is perhaps for this reason that the waterfall

model is used as a beginning example of a development model in many software engineering

texts and courses.

It is argued that the waterfall model and Big Design up Front in general can be suited to

software projects which are stable (especially those projects with unchanging requirements,

such as with shrink wrap software) and where it is possible and likely that designers will be able

to fully predict problem areas of the system and produce a correct design before

implementation is started. The waterfall model also requires that implementers follow the well

made, complete design accurately, ensuring that the integration of the system proceeds

smoothly.

[edit]Criticism

The waterfall model is argued by many to be a bad idea in practice. This is mainly because of

their belief that it is impossible for any non-trivial project to get one phase of a software

product's lifecycle perfected, before moving on to the next phases and learning from them.

For example, clients may not be aware of 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. If this is

the case, it is better to revise the design than to persist in using a design that was made based

on faulty predictions and that does not account for the newly discovered problem areas.

Even without such changing of the specification during implementation, there is the option

either to start a new project from scratch, "on a green field", or to continue some already

existing, "a brown field" (from construction again). The waterfall methodology can be used for

continuous enhancement, even for existing software, originally from another team. As well as in

the case when the system analyst fails to capture the customer requirements correctly, the

resulting impacts on the following phases (mainly the coding) still can be tamed by this

methodology, in practice: A challenging job for a QA team.

Steve McConnell in Code Complete (a book which criticizes the widespread use of the waterfall

model) refers to design as a "wicked problem" — a problem whose requirements and

limitations cannot be entirely known before completion. The implication of this is that it is

impossible to perfect one phase of software development, thus it is impossible if using the

waterfall model to move on to the next phase.

David Parnas, in "A Rational Design Process: How and Why to Fake It", writes:[3]

“Many of the [system's] details only become known to us as we progress in the [system's]

implementation. Some of the things that we learn invalidate our design and we must

backtrack.”

Expanding the concept above, the project stakeholders (non-IT personnel) may not be fully

aware of the capabilities of the technology being implemented. This can lead to their

expectations, and requirements, being defined by what they "think is possible". Which may not

take advantage of the full potential of what the new technology can deliver, or simply be trying

to replicate the existing application or process with the new technology. This can result in

substantial changes to the implementation requirements once the stakeholders become more

aware of the functionality available from the new technology. An example is where an

organisation is migrating from a paper based process to an electronic process. While the key

deliverables of the paper process should be maintained, the benefits of real-time data input

validation, traceability, and automated decision point routing may not be anticipated at the

early planning stages of the project.

The idea behind the waterfall model may be "measure twice; cut once", and those opposed to

the waterfall model argue that this idea tends to fall apart when the problem being measured is

constantly changing due to requirement modifications and new realizations about the problem

itself. A potential solution is for an experienced developer to spend time up front

on refactoring to consolidate the software, and to prepare it for a possible update, no matter if

such is planned already. Another approach is to use a design

targeting modularity with interfaces, to increase the flexibility of the software with respect to

the design.

Modified models

In response to the perceived problems with the pure waterfall model, many modified waterfall

models have been introduced. These models may address some or all of the criticisms of the

pure waterfall model.[citation needed] Many different models are covered by Steve McConnell in the

"lifecycle planning" chapter of his book Rapid Development: Taming Wild Software Schedules.

While all software development models will bear some similarity to the waterfall model, as all

software development models will incorporate at least some phases similar to those used

within the waterfall model, this section will deal with those closest to the waterfall model. For

models which apply further differences to the waterfall model, or for radically different models

seek general information on the software development process.

The Waterfall Model Explained

There are various software development approaches defined and designed which are

used/employed during development process of software, these approaches are also referred as

"Software Development Process Models". Each process model follows a particular life cycle in

order to ensure success in process of software development.

One such approach/process used in Software Development is "The 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 phases in Waterfall model are:

Requirement Specifications phase, Software Design, Implementation and Testing &

Maintenance. All these phases are cascaded to each other so that second phase is started as

and when defined set of goals are achieved for first phase and it is signed off, so the name

"Waterfall Model". All the methods and processes undertaken in Waterfall Model are more

visible.

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 end-

user (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.

There are some disadvantages of the Waterfall Model.

1) As it is very important to gather all possible requirements during the Requirement Gathering

and Analysis phase in order to properly design the system, not all requirements are received at

once, the requirements from customer goes on getting added to the list even after the end of

"Requirement Gathering and Analysis" phase, this affects the system development process and

its success in negative aspects.

2) The problems with one phase are never solved completely during that phase and in fact

many problems regarding a particular phase arise after the phase is signed off, this results in

badly structured system as not all the problems (related to a phase) are solved during the same

phase.

3) The project is not partitioned in phases in flexible way.

4) As the requirements of the customer goes on getting added to the list, not all the

requirements are fulfilled, this results in development of almost unusable system. These

requirements are then met in newer version of the system; this increases the cost of system

development.

The Waterfall Model: IT Project Management Solutions

The waterfall model is an information technology system development type model initially

published in 1970 by Winston W. Royce. Prior to this time, there had been a number of

significant malfunctions of IT system type projects; this is due to a lack of proper parameters,

procedural approaches and procedural controls of IT project management tasks.

The purpose of this model is to introduce modus operandi into the system design process; as a

skeleton for system development it advances consecutively through a succession of phases,

preliminarily with system feasibility analysis and concluding up to system release and

maintenance.

The name "waterfall" portrays system progress flows from the top to the bottom, like water

falling down steps in a waterfall panorama, one phase at a time towards the bottom in a

cascading effect.

In the present day, the waterfall model is considered classical and conservative system type

model; however, it is indispensable for a fundamental understanding of system development in

IT project systems management.

In the waterfall model, system design is broken down into a number of linear and sequential

stages, in which system evolution is seen as flowing progressively downwards, through the

phases. The waterfall model has distinct goals for each phase of development. In this

development method it is not allowed to journey onto the succeeding phase until the operation

of the preceding phase has been accomplished.

The output from each phase formed the input to the next phase; therefore, each phase had to

be accomplished in turn to maintain the linkage between the inputs and outputs.

A detail waterfall model can be represented as in the following system development life

cycle:

Phase I [SYSTEM FEASIBILITY / Justification]

{-----------------------||----------------------------}

Phase II [SYSTEM PLAN / Justification]

{-----------------------||----------------------------}

Phase III [OUTLINE DESIGN / Confirmation]

{-----------------------||----------------------------}

Phase IV [DETAIL DESIGN / Confirmation]

{-----------------------||----------------------------}

Phase V [CODING/ Unit Test]

{-----------------------||----------------------------}

Phase VI [INTEGRATION / Product Confirmation]

{-----------------------||----------------------------}

Phase VII [IMPLEMENTATION / System Test]

{-----------------------||----------------------------}

Phase VIII [OPERATION AND MAINTENANCE / Re Justification]

Here, a system flows through eight different sequential phases, and each phase is segmented

into two divisions: the first division covers the task to be carried out in that phase, and second

part is the justification or confirmation procedure on that specific work. Within this model, the

terms confirmation and justification have specific meanings:

Justification means validation or inspecting whether the result is fit for the operational mission,

that is, checking whether the correct product is being build or not. Is the product correct?

Confirmation means verification or inspecting the link between a result and the specification

for the result. In other words, a check that the result is being constructed in the correct

manner. Is the system structure correct?

The process of building the systems product flows phase to phase with very little interaction in-

between two stages, apart from transfer of outputs and inputs between them. The phase

progression sequences enforce discipline as every phase has a specific start and end spot, and

progress can be categorically acknowledged.

Within more modern system design projects, the water model is in use to mean any

chronological representation that is divided into successive phases and which pursue the

common structure of the original model. Here, the naming of the phases is not vital, and

suitable names can be used for the particular project being undertaken.

The waterfall model retains that system and should move to the next phase only when it's

previous phase is completed and perfected. Thus in the waterfall model each phase in a system

development life cycle is seen as part of an irreversible succession of events. One phase cannot

commence until the previous step has ended. Once a step has been started, there is no reverse

back to a prior step.

For instance, "detail design" cannot start until "outline design" has been finished, and program

"coding" cannot begin until "detail design" has been completed.

Phases of development in the waterfall model are thus discrete, and there is no leaping back

and forth or overlap between different phases.

Appreciations and Criticism of the waterfall model:

Appreciations:

The waterfall model provides a clear and easy to follow sequence of activities; it is simple and

can be understood without many complications. Furthermore, particular issues on quality

management are addressed through the Justification and Confirmation section that is being

followed in each phase of the model, and in addition to this, this model will facilitate project

management and control by the need to complete each stage before moving to the succeeding

phase.

Criticism:

The waterfall model lacks prescribed technique of implementing management control over a

project; planning, controlling, and risk management are not enveloped within the model itself.

Moreover, forecasting the estimated time and cost are complicated for each stage. The life

cycle can take long as the original requirements may no longer be valid, with little possibility for

prototyping.

The waterfall model of system development works best when any reworking of products is kept

to a minimum and the products remain unchanged. It still remains useful for steady and non-

volatile types of projects, and if properly implemented, generates significant cost and

timesaving. If the system is likely to go through significant changes and if the system

requirements are unpredictable then different approaches are recommended, one such

alternate approach is popularly know as the spiral model.

Spiral Model - A New Approach Towards Software Development

n last article we discussed about "Waterfall Model", which is one of the oldest and most simple

model designed and followed during software development process. But "Waterfall Model" has

its own disadvantages such as there is no fair division of phases in the life cycle, not all the

errors/problems related to a phase are resolved during the same phase, instead all those

problems related to one phase are carried out in the next phase and are needed to be resolved

in the next phase, this takes much of time of the next phase to solve them. The risk factor is the

most important part, which affects the success rate of the software developed by following

"The Waterfall Model".

In order to overcome the cons of "The Waterfall Model", it was necessary to develop a new

Software Development Model, which could help in ensuring the success of software project.

One such model was developed which incorporated the common methodologies followed in

"The Waterfall Model", but it also eliminated almost every possible/known risk factors from it.

This model is referred as "The Spiral Model" or "Boehm’s Model".

There are four phases in the "Spiral Model" which are: Planning, Evaluation, Risk Analysis and

Engineering. These four phases are iteratively followed one after other in order to eliminate all

the problems, which were faced in "The Waterfall Model". Iterating the phases helps in

understating the problems associated with a phase and dealing with those problems when the

same phase is repeated next time, planning and developing strategies to be followed while

iterating through the phases. The phases in "Spiral Model" are:

Plan: In this phase, the objectives, alternatives and constraints of the project are determined

and are documented. The objectives and other specifications are fixed in order to decide which

strategies/approaches to follow during the project life cycle.

Risk Analysis: This phase is the most important part of "Spiral Model". In this phase all possible

(and available) alternatives, which can help in developing a cost effective project are analyzed

and strategies are decided to use them. This phase has been added specially in order to identify

and resolve all the possible risks in the project development. If risks indicate any kind of

uncertainty in requirements, prototyping may be used to proceed with the available data and

find out possible solution in order to deal with the potential changes in the requirements.

Engineering: In this phase, the actual development of the project is carried out. The output of

this phase is passed through all the phases iteratively in order to obtain improvements in the

same.

Customer Evaluation: In this phase, developed product is passed on to the customer in order to

receive customer’s comments and suggestions which can help in identifying and resolving

potential problems/errors in the software developed. This phase is very much similar to

TESTING phase.

The process progresses in spiral sense to indicate iterative path followed, progressively more

complete software is built as we go on iterating through all four phases. The first iteration in

this model is considered to be most important, as in the first iteration almost all possible risk

factors, constraints, requirements are identified and in the next iterations all known strategies

are used to bring up a complete software system. The radical dimensions indicate evolution of

the product towards a complete system.

However, as every system has its own pros and cons, "The Spiral Model" does have its pros and

cons too. As this model is developed to overcome the disadvantages of the "Waterfall Model",

to follow "Spiral Model", highly skilled people in the area of planning, risk analysis and

mitigation, development, customer relation etc. are required. This along with the fact that the

process needs to be iterated more than once demands more time and is somehow expensive

task.

The Spiral Model: IT Project Management Solutions

The Spiral Model is the neo approach in IT project system development and was originally

devised by Barry W. Boehm through his article published in 1985 "A Spiral Model of Software

Development and Enhancement".

This model of development unites the features of the prototyping model with an iterative

approach of system development; combining elements of design and prototyping-in-stages.

This model is an effort to combine the advantages of top-down and bottom-up concepts highly

preferential for large, exclusive, volatile, and complex projects.

The term "spiral" is used to describe the process that is followed in this model, as the

development of the system takes place, the mechanisms go back several times over to earlier

sequences, over and over again, circulating like a spiral.

The spiral model represents the evolutionary approach of IT project system development and

carries the same activities over a number of cycles in order to elucidate system requirements

and its solutions.

Similar to the waterfall model, the spiral model has sequential cycles/stages, with each stage

having to be completed before moving on to next.

The prime difference between the waterfall model and the spiral model is that the project

system development cycle moves towards eventual completion in both the models but in the

spiral model the cycles go back several times over to earlier stages in a repetitive sequence.

Progress Cycles, IT Project Management Solutions

The progress cycle of this model is divided into four quadrants, and each quadrant with a

different purpose;

Determining Objectives (I)------------Evaluating Alternatives (II)

*************************************************************

Planning Next Phase (III)------------Planning Next Phase (IV)

First Quadrant: the top left quadrant determines and identifies the project objectives,

alternatives, and constrains of the project. Similar to the system conception stage in the

Waterfall Model, here objectives are determined with identifying possible obstacles and

weighting alternative approaches.

Second Quadrant: the top right quadrant determines the different alternatives of the project

risk analysis, and evaluates their task with each alternative eventually resolving them. Probable

alternatives are inspected and associated risks are recognized. Resolutions of the project risks

are evaluated, and prototyping is used wherever necessary.

Third Quadrant: the bottom right quadrant develops the system and this quadrant corresponds

to the waterfall model with detailed requirements determined for the project.

Fourth Quadrant: the bottom left quadrant plans the next phase development process,

providing opportunity to analyze the results and feedback.

In each phase, it begins with a system design and terminates with the client reviewing the

progress through prototyping.

The major advantage of the spiral model over the waterfall model is the advance approach on

setting project objectives, project risk management and project planning into the overall

development cycle. Additionally, another significant advantage is, the user can be given some

of the functionality before the entire system is completed.

The spiral model addresses complexity of predetermined system performance by providing an

iterative approach to system development, repeating the same activities in order to clarify the

problem and provide an accurate classification of the requirement within the bounds of

multiple constraints.

Software Testing Methodologies

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

techniques and methodologies that are in practice today.

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.

Software Testing Methods

There are different types of testing methods or techniques as part of the software testing

process. I have enlisted a few of them below.

White box testing

Black box testing

Gray box testing

Unit testing

Integration testing

Regression testing

Usability testing

Performance testing

Scalability testing

Software stress testing

Recovery testing

Security testing

Conformance testing

Smoke testing

Compatibility testing

System testing

Alpha testing

Beta testing

The above software testing methods can be implemented in two ways - manually or by

automation. Manual software testing is done by human software testers who manually i.e.

physically check, test and report errors or bugs in the product or piece of code. In case of

automated software testing, the same process is performed by a computer by means of an

automated testing software such as WinRunner, LoadRunner, Test Director, etc.

Software Testing Methodologies

These are some commonly used software testing methodologies:

Waterfall model

V model

Spiral model

RUP

Agile model

RAD

Let us have a look at each one of these methodologies one by one.

Waterfall Model

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. Requirement analysis

2. Test case design

3. Test case implementation

4. Testing, debugging and validating the code or product

5. Deployment and 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.

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.

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.

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).

Agile Model

This methodology follows neither a purely sequential approach nor does it follow a purely

iterative approach. It is a selective mix of both of these approaches in addition to quite a few

new developmental methods. Fast and incremental development is one of the key principles of

this methodology. The focus is on obtaining quick, practical and visible outputs and results,

rather than merely following theoretical processes. Continuous customer interaction and

participation is an integral part of the entire development process.

Rapid Application Development (RAD)

The name says it all. In this case, the methodology adopts a rapid development approach by

using the principle of component-based construction. After understanding the various

requirements, a rapid prototype is prepared and is then compared with the expected set of

output conditions and standards. Necessary changes and modifications are made after joint

discussions with the customer or the development team (in the context of software testing).

Though this approach does have its share of advantages, it can be unsuitable if the project is

large, complex and happens to be of an extremely dynamic nature, wherein the requirements

are constantly changing. Here are some more advantages of rapid application development.

This was a short overview of some commonly used software testing methodologies. With the

applications of information technology growing with every passing day, the importance of

proper software testing has grown multifold.

Software Testing - White Box Testing Strategy

An introduction to White Box Testing Strategy and various types of testing that comes under

white box testing strategy.

What is a White Box Testing Strategy?

White box testing strategy deals with the internal logic and structure of the code. White box

testing is also called as glass, structural, open box or clear box testing. The tests written based

on the white box testing strategy incorporate coverage of the code written, branches, paths,

statements and internal logic of the code etc.

In order to implement white box testing, the tester has to deal with the code and hence is

needed to possess knowledge of coding and logic i.e. internal working of the code. White box

test also needs the tester to look into the code and find out which unit/statement/chunk of the

code is malfunctioning.

Advantages of White box testing are:

i) As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out

which type of input/data can help in testing the application effectively.

ii) The other advantage of white box testing is that it helps in optimizing the code

iii) It helps in removing the extra lines of code, which can bring in hidden defects.

Disadvantages of white box testing are:

i) As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to

carry out this type of testing, which increases the cost.

ii) And it is nearly impossible to look into every bit of code to find out hidden errors, which may

create problems, resulting in failure of the application.

Types of testing under White/Glass Box Testing Strategy:

Unit Testing:

The developer carries out unit testing in order to check if the particular module or unit of code

is working fine. The Unit Testing comes at the very basic level as it is carried out as and when

the unit of the code is developed or a particular functionality is built.

Static and dynamic Analysis:

Static analysis involves going through the code in order to find out any possible defect in the

code. Dynamic analysis involves executing the code and analyzing the output.

Statement Coverage:

In this type of testing the code is executed in such a manner that every statement of the

application is executed at least once. It helps in assuring that all the statements execute

without any side effect.

Branch Coverage:

No software application can be written in a continuous mode of coding, at some point we need

to branch out the code in order to perform a particular functionality. Branch coverage testing

helps in validating of all the branches in the code and making sure that no branching leads to

abnormal behavior of the application.

Security Testing:

Security Testing is carried out in order to find out how well the system can protect itself from

unauthorized access, hacking – cracking, any code damage etc. which deals with the code of

application. This type of testing needs sophisticated testing techniques.

Mutation Testing:

A kind of testing in which, the application is tested for the code that was modified after fixing a

particular bug/defect. It also helps in finding out which code and which strategy of coding can

help in developing the functionality effectively.

Besides all the testing types given above, there are some more types which fall under both

Black box and White box testing strategies such as: Functional testing (which deals with the

code in order to check its functional performance), Incremental integration testing (which deals

with the testing of newly added code in the application), Performance and Load testing (which

helps in finding out how the particular code manages resources and give performance etc.) etc.

What is a Black Box Testing Strategy?

Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need

any knowledge of internal design or code etc. As the name "black box" suggests, no knowledge

of internal logic or code structure is required. The types of testing under this strategy are totally

based/focused on the testing for requirements and functionality of the work product/software

application. Black box testing is sometimes also called as "Opaque Testing",

"Functional/Behavioral Testing" and "Closed Box Testing".

The base of the Black box testing strategy lies in the selection of appropriate data as per

functionality and testing it against the functional specifications in order to check for normal and

abnormal behavior of the system. Now a days, it is becoming common to route the Testing

work to a third party as the developer of the system knows too much of the internal logic and

coding of the system, which makes it unfit to test the application by the developer.

In order to implement Black Box Testing Strategy, the tester is needed to be thorough with the

requirement specifications of the system and as a user, should know, how the system should

behave in response to the particular action.

Various testing types that fall under the Black Box Testing strategy are: functional testing, stress

testing, recovery testing, volume testing, User Acceptance Testing (also known as UAT), system

testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc

testing, alpha testing, beta testing etc.

These testing types are again divided in two groups: a) Testing in which user plays a role of

tester and b) User is not required.

Testing method where user is not required:

Functional Testing:

In this type of testing, the software is tested for the functional requirements. The tests are

written in order to check if the application behaves as expected.

Stress Testing:

The application is tested against heavy load such as complex numerical values, large number of

inputs, large number of queries etc. which checks for the stress/load the applications can

withstand.

Load Testing:

The application is tested against heavy loads or inputs such as testing of web sites in order to

find out at what point the web-site/application fails or at what point its performance degrades.

Ad-hoc Testing:

This type of testing is done without any formal Test Plan or Test Case creation. Ad-hoc testing

helps in deciding the scope and duration of the various other testing and it also helps testers in

learning the application prior starting with any other testing.

Exploratory Testing:

This testing is similar to the ad-hoc testing and is done in order to learn/explore the application.

Usability Testing:

This testing is also called as ‘Testing for User-Friendliness’. This testing is done if User Interface

of the application stands an important consideration and needs to be specific for the specific

type of user.

Smoke Testing:

This type of testing is also called sanity testing and is done in order to check if the application is

ready for further major testing and is working properly without failing up to least expected

level.

Recovery Testing:

Recovery testing is basically done in order to check how fast and better the application can

recover against any type of crash or hardware failure etc. Type or extent of recovery is specified

in the requirement specifications.

Volume Testing:

Volume testing is done against the efficiency of the application. Huge amount of data is

processed through the application (which is being tested) in order to check the extreme

limitations of the system.

Testing where user plays a role/user is required:

User Acceptance Testing:

In this type of testing, the software is handed over to the user in order to find out if the

software meets the user expectations and works as it is expected to.

Alpha Testing:

In this type of testing, the users are invited at the development center where they use the

application and the developers note every particular input or action carried out by the user. Any

type of abnormal behavior of the system is noted and rectified by the developers.

Beta Testing:

In this type of testing, the software is distributed as a beta version to the users and users test

the application at their sites. As the users explore the software, in case if any exception/defect

occurs that is reported to the developers.

software Testing - An Introduction To Usability Testing

Success of any newly designed and developed software strongly and mainly depends on what

extent the software meets the requirements stated by user and how the intended/end user

finds the software to operate?

Usability Testing:

As the term suggest, usability means how better something can be used over the purpose it has

been created for. Usability testing means a way to measure how people (intended/end user)

find it (easy, moderate or hard) to interact with and use the system keeping its purpose in

mind. It is a standard statement that "Usability testing measures the usability of the system".

Why Do We Need Usability Testing?

Usability testing is carried out in order to find out if there is any change needs to be carried out

in the developed system (may it be design or any specific procedural or programmatic change)

in order to make it more and more user friendly so that the intended/end user who is

ultimately going to buy and use it receives the system which he can understand and use it with

utmost ease.

Any changes suggested by the tester at the time of usability testing, are the most crucial points

that can change the stand of the system in intended/end user’s view. Developer/designer of

the system need to incorporate the feedbacks (here feedback can be a very simple change in

look and feel or any complex change in the logic and functionality of the system) of usability

testing into the design and developed code of the system (the word system may be a single

object or an entire package consisting more than one objects) in order to make system more

and more presentable to the intended/end user.

Developer often try to make the system as good looking as possible and also tries to fit the

required functionality, in this endeavor he may have forgotten some error prone conditions

which are uncovered only when the end user is using the system in real time.

Usability testing helps developer in studying the practical situations where the system will be

used in real time. Developer also gets to know the areas that are error prone and the area of

improvement.

In simple words, usability testing is an in-house dummy-release of the system before the actual

release to the end users, where developer can find and fix all possible loop holes.

How Usability Test Is Carried Out?

Usability test, as mentioned above is an in-house dummy release before the actual release of

the system to the intended/end user. Hence, a setup is required in which developer and testers

try to replicate situations as realistic as possible to project the real time usage of the system.

The testers try to use the system in exactly the same manner that any end user can/will do.

Please note that, in this type of testing also, all the standard instruction of testing are followed

to make it sure that the testing is done in all the directions such as functional testing, system

integration testing, unit testing etc.

The outcome/feedback is noted down based on observations of how the user is using the

system and what are all the possible ways that also may come into picture, and also based on

the behavior of the system and how easy/hard it is for the user to operate/use the system. User

is also asked for his/her feedback based on what he/she thinks should be changed to improve

the user interaction between the system and the end user.

Usability testing measures various aspects such as:

How much time the tester/user and system took to complete basic flow?

How much time people take to understand the system (per object) and how many mistakes

they make while performing any process/flow of operation?

How fast the user becomes familiar with the system and how fast he/she can recall the

system’s functions?

And the most important: how people feel when they are using the system?

Over the time period, many people have formulated various measures and models for

performing usability testing. Any of the models can be used to perform the test.

Advantages of Usability Testing

Usability test can be modified to cover many other types of testing such as functional

testing, system integration testing, unit testing, smoke testing etc. (with keeping the

main objective of usability testing in mind) in order to make it sure that testing is done

in all the possible directions.

Usability testing can be very economical if planned properly, yet highly effective and

beneficial.

If proper resources (experienced and creative testers) are used, usability test can help in

fixing all the problems that user may face even before the system is finally released to

the user. This may result in better performance and a standard system.

Usability testing can help in uncovering potential bugs and potholes in the system which

generally are not visible to developers and even escape the other type of testing.

Usability testing is a very wide area of testing and it needs fairly high level of understanding of

this field along with creative mind. People involved in the usability testing are required to

possess skills like patience, ability to listen to the suggestions, openness to welcome any idea,

and the most important of them all is that they should have good observation skills to spot and

fix the problems on fly.

Software Testing - Stress Testing

Stress testing is a process for establishing limits of adverse environments in which the

system/software/website under test will crash. Know more about stress testing...

Stress testing has different meaning for different industries where it is used. For a financial

industry/sector, stress testing means a process of testing financial instruments to find out their

robustness and level of accuracy they can maintain under extreme conditions such as sudden or

continuous market crash at a certain level, sudden or extreme change in various parameters,

for example interest rates, repo and reverse repo used in the financial sector, sudden rise or

decline in the price of materials that can affect financial projections etc. For the manufacturing

industry, stress testing may include different parameters and operating process for testing of

different systems. For medical industry, stress testing means a process that can help

understand a patient’s condition, etc.

Stress Testing in IT Industry

Stress testing in IT industry (hardware as well as software sectors) means testing of

software/hardware for its effectiveness in giving consistent or satisfactory performance under

extreme and unfavorable conditions such as heavy network traffic, heavy processes load, under

or over clocking of underlying hardware, working under maximum requests for resource

utilization of the peripheral or in the system etc.

In other words, stress testing helps find out the level of robustness and consistent or

satisfactory performance even when the limits for normal operation for the system

(software/hardware) is crossed.

Most important use of stress testing is found in testing of software and hardware that are

supposed to be operating in critical or real time situation. Such as a website will always be

online and the server hosting the website must be able to handle the traffic in all possible ways

(even if the traffic increases manifold), a mission critical software or hardware that works in real

time scenario etc. Stress testing in connection with websites or certain software is considered

to be an effective process of determining the limit, at which the

system/software/hardware/website shows robustness, is always available to perform its task,

effectively manages the load than the normal scenario and even shows effective error

management under extreme conditions.

Need for Stress Testing

Stress testing is considered to be important because of following reasons:

1. Almost 90% of the software/systems are developed with an assumption that they will be

operating under normal scenario. And even if it is considered that the limit of normal

operating conditions will be crossed, it is not considerably as high as it really could be.

2. The cost or effect of a very important (critical) software/system/website failure under

extreme conditions in real time can be huge (or may be catastrophic for the organization

or entity owning the software/system).

3. It is always better to be prepared for extreme conditions rather than letting the

system/software/website crash, when the limit of normal operation is crossed.

4. Testing carried out by the developer of the system/software/website may not be

sufficient to help unveil conditions which will lead to crash of the system/software when

it is actually submitted to the operating environment.

5. It's not always possible to unveil possible problems or bugs in a system/software, unless

it is subjected to such type of testing.

To help overcome problems like denial of service attacks, in case of web servers for a web

site, security breach related problems due tospamming, hacking and viruses etc., problems

arising out of conditions where software/system/website need to handle requests for resource

allocation for requesting processes at the time when all the required resources are already

allocated to some other process that needs some more resources to complete its work (which

is called as deadlock situation), memory leak, race condition etc.

This type of testing is mostly done with the help of various stress testing softwares available in

market. These tools are configured to automate a process of increasing stress (i.e. creation and

increasing degree of adverse environment) on a system/software/website and capturing values

of various parameters that help confirm the robustness, availability and performance of the

system/software/website being tested. Few of the actions involved in stress testing are

bombarding a website with huge number of requests, running of many resource hungry

applications in a computer, making numerous attempts to access ports of a computer in order

to hack it and use it for various purposes such as spamming, spreading virus etc.

Intensity of the adverse conditions is increased slowly while measuring all the parameters till

the point where the system/software/website crashes. The collected data (observation and

parameter values) are used for further improvement of the system/software/website.

Software Testing - Brief Introduction To Security Testing

Security testing is an important process in order to ensure that the systems/applications that

your organization is using meet security policies and are free from any type of loopholes that

can cause your organization a big loss.

Non-Destructive Testing

Full Range of Leading NDT Equipment View Our Catalog Online Today! www.mac-ndt.com

Security Testing of any developed system (or a system under development) is all about finding

out all the potential loopholes and weaknesses of the system, which might result into loss/theft

of highly sensitive information or destruction of the system by an intruder/outsider. Security

Testing helps in finding out all the possible vulnerabilities of the system and help developers in

fixing those problems.

Need of Security Testing

Security test helps in finding out loopholes that can cause loss of important information

and allow any intruder enter into the systems.

Security Testing helps in improving the current system and also helps in ensuring that

the system will work for longer time (or it will work without hassles for the estimated

time).

Security Testing doesn’t only include conformance of resistance of the systems your

organization uses, it also ensures that people in your organization understand and obey

security policies. Hence adding up to the organization-wide security.

If involved right from the first phase of system development life cycle, security testing

can help in eliminating the flaws into design and implementation of the system and in

turn help the organization in blocking the potential security loopholes in the earlier

stage. This is beneficial to the organization almost in all aspects (financially, security and

even efforts point of view).

Who need Security Testing?

Now a day, almost all organizations across the world are equipped with hundreds of computers

connected to each other through intranets and various types of LANs inside the organization

itself and through Internet with the outer world and are also equipped with data storage &

handling devices. The information that is stored in these storage devices and the applications

that run on the computers are highly important to the organization from the business, security

and survival point of view.

Any organization small or big in size, need to secure the information it possesses and the

applications it uses in order to protect its customer’s information safe and suppress any

possible loss of its business.

Security testing ensures that the systems and applications used by the organizations are secure

and not vulnerable to any type of attack.

What are the different types of Security Testing?

Following are the main types of security testing:

Security Auditing: Security Auditing includes direct inspection of the application

developed and Operating Systems & any system on which it is being developed. This

also involves code walk-through.

Security Scanning: It is all about scanning and verification of the system and

applications. During security scanning, auditors inspect and try to find out the

weaknesses in the OS, applications and network(s).

Vulnerability Scanning: Vulnerability scanning involves scanning of the application for

all known vulnerabilities. This scanning is generally done through various vulnerability

scanning software.

Risk Assessment: Risk assessment is a method of analyzing and deciding the risk that

depends upon the type of loss and the possibility/probability of loss occurrence. Risk

assessment is carried out in the form of various interviews, discussions and analysis of

the same. It helps in finding out and preparing possible backup-plan for any type of

potential risk, hence contributing towards the security conformance.

Posture Assessment & Security Testing: This is a combination of Security Scanning, Risk

Assessment and Ethical Hacking in order to reach a conclusive point and help your

organization know its stand in context with Security.

Penetration Testing: In this type of testing, a tester tries to forcibly access and enter the

application under test. In the penetration testing, a tester may try to enter into the

application/system with the help of some other application or with the help of

combinations of loopholes that the application has kept open unknowingly. Penetration

test is highly important as it is the most effective way to practically find out potential

loopholes in the application.

Ethical Hacking: It’s a forced intrusion of an external element into the system &

applications that are under Security Testing. Ethical hacking involves number of

penetration tests over the wide network on the system under test.

(Please Note: The above given list of security types is based on the Open Source Security

Testing Methodology Manual of Pete Herzog and the Institute for Security and Open

Methodologies - ISECOM)

The best way to ensure security is to involve the security related assessments, audits and

various types of testing right from the first phase of system development. The level and form of

processes used in security testing of any system varies depending upon the phase, condition

and type of system under testing.

Software Testing - Compatibility Testing

Compatibility testing is a non-functional software testing that helps evaluate a

system/application's performance in connection with the operating environment. Read on to

know more about compatibility testing.

CEC Performance Test

PV Module Testing Lab Accredited For Design Qualification. Call Now! www.TuvPtl.com

Compatibility testing is one of the several types of software testing performed on a system that

is built based on certain criteria and which has to perform specific functionality in an already

existing setup/environment. Compatibility of a system/application being developed with, for

example, other systems/applications, OS, Network, decide many things such as use of the

system/application in that environment, demand of the system/application etc. Many a times,

users prefer not to opt for an application/system just because it is not compatible with any

other system/application, network, hardware or OS they are already using. This leads to a

situation where the development efforts taken by developers prove to be in vain.

What is Compatibility Testing

Compatibility testing is a type of testing used to ensure compatibility of the

system/application/website built with various other objects such as other web browsers,

hardware platforms, users (in case if its very specific type of requirement, such as a user who

speaks and can read only a particular language), operating systems etc. This type of testing

helps find out how well a system performs in a particular environment that includes hardware,

network, operating system and other software etc.

Compatibility testing can be automated using automation tools or can be performed manually

and is a part of non-functional software testing.

Developers generally lookout for the evaluation of following elements in a computing

environment (environment in which the newly developed system/application is tested and

which has similar configuration as the actual environment in which the system/application is

supposed to fit and start working).

Hardware: Evaluation of the performance of system/application/website on a certain hardware

platform. For example: If an all-platform compatible game is developed and is being tested for

hardware compatibility, the developer may choose to test it for various combinations of

chipsets (such as Intel, Macintosh GForce), motherboards etc.

Browser: Evaluation of the performance of system/website/application on a certain type of

browser. For example: A website is tested for compatibility with browsers like Internet Explorer,

Firefox etc. (usually browser compatibility testing is also looked at as a user experience testing,

as it is related to user’s experience of the application/website, while using it on different

browsers).

Network: Evaluation of the performance of system/application/website on network with

varying parameters such as bandwidth, variance in capacity and operating speed of underlying

hardware etc., which is set up to replicate the actual operating environment.

Peripherals: Evaluation of the performance of system/application in connection with various

systems/peripheral devices connected directly or via network. For example: printers, fax

machines, telephone lines etc.

Compatibility between versions: Evaluation of the performance of system/application in

connection with its own predecessor/successor versions (backward and forward compatibility).

For example: Windows 98 was developed with backward compatibility for Windows 95 etc.

Softwares: Evaluation of the performance of system/application in connection with other

softwares. For example: Software compatibility with operating tools for network, web servers,

messaging tools etc.

Operating System: Evaluation of the performance of system/application in connection with the

underlying operating system on which it will be used.

Databases: Many applications/systems operate on databases. Database compatibility testing is

used to evaluate an application/system’s performance in connection to the database it will

interact with.

How helpful is it?

Compatibility testing can help developers understand the criteria that their system/application

needs to attain and fulfill, in order to get accepted by intended users who are already using

some OS, network, software and hardware etc. It also helps the users to find out which system

will better fit in the existing setup they are using.

The most important use of the compatibility testing is as already mentioned above: to ensure

its performance in a computing environment in which it is supposed to operate. This helps in

figuring out necessary changes/modifications/additions required to make the

system/application compatible with the computing environment.

1. What is testing?

Software Testing can be defined as: Testing is an activity that helps in finding out

bugs/defects/errors in a software system under development, in order to provide a bug free

and reliable system/solution to the customer.

In other words, you can consider an example as: suppose you are a good cook and are

expecting some guests at dinner. You start making dinner; you make few very very very

delicious dishes (off-course, those which you already know how to make). And finally, when you

are about to finish making the dishes, you ask someone (or you yourself) to check if everything

is fine and there is no extra salt/chili/anything, which if is not in balance, can ruin your evening

(This is what called 'TESTING').

This procedure you follow in order to make it sure that you do not serve your guests something

that is not tasty! Otherwise your collar will go down and you will regret over your failure!

2. Why we go for testing?

Well, while making food, its ok to have something extra, people might understand and eat the

things you made and may well appreciate your work. But this isn't the case with Software

Project Development. If you fail to deliver a reliable, good and problem free software solution,

you fail in your project and probably you may loose your client. This can get even worse!

So in order to make it sure, that you provide your client a proper software solution, you go for

TESTING. You check out if there is any problem, any error in the system, which can make

software unusable by the client. You make software testers test the system and help in finding

out the bugs in the system to fix them on time. You find out the problems and fix them and

again try to find out all the potential problems.

3. Why there is need of testing?

OR

Why there is a need of 'independent/separate testing'?

This is a right question because, prior to the concept of TESTING software as a ‘Testing Project’,

the testing process existed, but the developer(s) did that at the time of development.

But you must know the fact that, if you make something, you hardly feel that there can be

something wrong with what you have developed. It's a common trait of human nature, we feel

that there is no problem in our designed system as we have developed it and it is perfectly

functional and fully working. So the hidden bugs or errors or problems of the system remain

hidden and they raise their head when the system goes into production.

On the other hand, its a fact that, when one person starts checking something which is made by

some other person, there are 99% chances that checker/observer will find some problem with

the system (even if the problem is with some spelling that by mistake has been written in wrong

way.). Really weird, isn't it? But that’s a truth!

Even though its wrong in terms of human behavior, this thing has been used for the benefit of

software projects (or you may say, any type of project). When you develop something, you give

it to get checked (TEST) and to find out any problem, which never aroused while development

of the system. Because, after all, if you could minimize the problems with the system you

developed, it’s beneficial for yourself. Your client will be happy if your system works without

any problem and will generate more revenues for you.

BINGO, it's really great, isn't it? That's why we need testing!

4. What is the role of "a tester"?

A tester is a person who tries to find out all possible errors/bugs in the system with the help of

various inputs to it. A tester plays an important part in finding out the problems with system

and helps in improving its quality.

If you could find all the bugs and fix them all, your system becomes more and more reliable.

A tester has to understand the limits, which can make the system break and work abruptly. The

more number of VALID BUGS tester finds out, the better tester he/she is!

What is Rational Unified Process (RUP)

Rational Unified Process (RUP) is a comprehensive software engineering process. It features a

disciplined approach towards industry-tested practices for designing softwares and systems

within a development organization. Continue reading, if you want to know what is rational

unified process (RUP)?

Test Strategy & Process

Learn Tacticle & Strategic Approach Regardless of Methodology @ STP2010 www.stpcon.com

The concept of Rational Unified Process (RUP) came from the Rational Software Corporation, a

division of IBM (International Business Machines Corporation). It keeps a check on

effective project management and high-quality production of software. The basic methodology

followed in RUP is based on a comprehensive web-enabled program development and object-

oriented approach.The 'Rational Unified Process' adopts the 'Unified Modeling Language' and

provides the best practiced guidelines, templates and illustrations of all aspects for program

development. Here is a simple breakdown of all the aspects related to this concept, so as to

give you a brief understanding as to what is rational unified process (RUP)?

There are primarily four phases or stages of development that is concluded with a release in

RUP. Here is a quick review of all the four stages or cycles.

Inception Phase

In the inception phase, the goal is to develop the parent idea into a product vision by defining

its scope and the business case. The business case includes business context, factors influencing

success, risk assessment and financial forecast. This is to get an understanding of the business

drivers and to justify the launch of the project. This phase is to identify the work flows required

by the project.

Elaboration Phase

Here the architectural foundation, project plan and high-risk factors of the project are

determined, after analyzing the problem domain. For establishing these objectives, an in-and-

out knowledge of the system is a must. In other words, the performance requirements, scope

and functionality of the system, influence the deciding factor in the architectural concept of the

project. Architectural and planning decisions are governed by the most critical use-cases. So, a

perfect understanding of the use-cases and an articulated vision is what this phase of

elaboration looks forward to achieve. This is an important phase. Since, after this phase the

project is carried on to a level where any changes might cause disastrous outcome for the

entire operation.

Construction Phase

As the name suggests, the phase involves construction of the software system or project. Here,

development of the remaining components and application features is performed. Thereafter,

they are integrated into the product which is moved from an architectural baseline to a

completed system. In short, the source code and the application design is created for the

software for its transition to the user community. The construction phase is the first external

release of the software, wherein, adequate quality with optimization of resources is achieved

rapidly.

Transition Phase

Transition phase marks the transition of the project from development to production. This

stage is to ensure that the user requirements have been satisfied and met by the product. The

initiative is done by testing the product before its release as a beta version. This beta version is

enhanced by bug fixing, site preparation, manual completion, defect identification and

improving performance and usability. Other objectives are also taken up. They include

Training users and maintainers for successful operation of the system

Purchasing hardware

Converting data from old to new systems

Arranging for activities for successful launch of the product

Holding sessions of learning lessons for improving future process and tool environment.

Rational Unified Process mentions six best practices, which have to be kept in mind when

designing any software. These practices help prevent flaws in the project development and

create more scope for efficient productivity. These six practices are as follows.

1. An iterative (executing the same set of instructions a given number of times or until a

specified result is obtained) approach towards thesoftware development.

2. Managing user requirements.

3. Use and test individual components before being integrated into a larger system.

Use 'Unified Modeling Language' tool to get a visual model of the components, users

and their interaction relating to the project.Constant testing of the software quality is

considered one of the best practices in any software development.

4. For a successful iterative development, monitoring, tracking and controlling changes

made to a system is essential for a team to work together as a single unit.

The concept of rational unified process has endless explanation and description. Each and every

important and essential considerations in a software development has been defined to its root.

RUP results in a reduced IT costs, improved IT business, higher quality, higher service level and

sharper adaptability, and most importantly, higher ROI (return on investments), and many

other benefits. The above is just a theoretical brief explanation to the question as to what is

RUP? However, a clearer and elaborated idea can be achieved once the process is put into

practical use.

how to Prototype an Idea or Invention

Expert guide to prototyping a new idea or invention, including advice on patenting and

designing a new idea.

Each idea is different and the best approach to prototyping depends on the specifics of the

idea. However there are some basic principles that can help. The first question to ask is: "What

is the prototype for?"

Presentation to interested parties

When presenting your idea to an investor or company representative it might not actually be

necessary to have a prototype. It is often possible to convey the idea or invention to an

interested party using a graphic presentation. The idea should be designed, ideally using

computer aided design, and then images of the product laid out on presentation boards. It is

probably best to get a professional product designer to complete the design work and show

how the product looks and what it does. Try to find a design company that specializes in

product design for inventors. One UK based company is Innovate Design.

If funds are tight it is better to spend the money on a professional presentation rather than a

prototype. The presentation will be more cost effective than the prototype and will be quicker

to produce. The work done during the design stage can help reduce the cost of the prototyping

stage if it becomes necessary at a later date.

When a prototype is necessary

Concept prototypes are sometimes necessary to either prove that an idea works or instantly

convey an idea that is hard to describe on paper. If people need to interact with the idea to be

persuaded of its benefits then a prototype can make all the difference.

Often people are more prepared to back an idea if they can see that a lot of the development

work has already been done and a prototype demonstrates this. An inventor could typically

expect to charge more for an idea if it has been prototyped so it is worth considering if the

funds are available.

How much will a prototype cost?

Prototypes costs vary hugely depending on the size and complexity of the idea. Typically for a

small hand held product with a unique shape it could be in the region of two to three thousand

pounds.

Why are prototypes so expensive?

Often the idea has to be designed first to establish the layout of internal components and the

shape of the casing among other considerations. Then a virtual model has to be built using

computer aided design and then finally a prototype can be built using rapid prototyping. All of

this takes time and therefore it is expensive.

What is rapid prototyping?

Rapid prototyping is a technology that takes a 3D computer model and builds a 3D plastic part.

There are three basic techniques for rapid prototyping: Stereolithography, Selective Laser

Sintering and Fusion Deposition Modelling. For all these processes the model needs to be

professionally designed using computer aided design.

Are there cheaper ways of building a prototype?

Some ideas can be prototyped simply from existing products or by using ordinary materials and

these will be cheaper than prototypes that are built using rapid prototyping. Another cheaper

way is to build a prototype that proves the principle of the idea without necessarily looking like

the final product. This is called a ‘proof of principle’ prototype. Alternatively an aesthetic model

could be built that shows what the product will look like but does not prove whether it will

work.

What are the different types of prototype?

There are three main categories of prototype:

1. Proof of principle: A prototype that simply proves that a particularly new system or

mechanism works. Often it is just part of the overall idea and it does not need to look like the

final product.

Software Verification & Validation Model - An Introduction

A perfect software product is built when every step is taken with full consideration that ‘A right

product is developed in a right manner’. ‘Software Verification & Validation’ is one such model,

which helps the system designers and test engineers to confirm that a right product is build

right way throughout the development process and improve the quality of the software

product.

‘Verification & Validation Model’ makes it sure that, certain rules are followed at the time of

development of a software product and also makes it sure that the product that is developed

fulfills the required specifications. This reduces the risk associated with any software project up

to certain level by helping in detection and correction of errors and mistakes, which are

unknowingly done during the development process.

What is Verification?

The standard definition of Verification goes like this: "Are we building the product RIGHT?" i.e.

Verification is a process that makes it sure that the software product is developed the right

way. The software should confirm to its predefined specifications, as the product development

goes through different stages, an analysis is done to ensure that all required specifications are

met.

Methods and techniques used in the Verification and Validation shall be designed carefully, the

planning of which starts right from the beginning of the development process. The Verification

part of ‘Verification and Validation Model’ comes before Validation, which incorporates

Software inspections, reviews, audits, walkthroughs, buddy checks etc. in each phase of

verification (every phase of Verification is a phase of the Testing Life Cycle)

During the Verification, the work product (the ready part of the Software being developed and

various documentations) is reviewed/examined personally by one ore more persons in order to

find and point out the defects in it. This process helps in prevention of potential bugs, which

may cause in failure of the project.

Few terms involved in Verification:

Inspection:

Inspection involves a team of about 3-6 people, led by a leader, which formally reviews the

documents and work product during various phases of the product development life cycle. The

work product and related documents are presented in front of the inspection team, the

member of which carry different interpretations of the presentation. The bugs that are

detected during the inspection are communicated to the next level in order to take care of

them.

Walkthroughs:

Walkthrough can be considered same as inspection without formal preparation (of any

presentation or documentations). During the walkthrough meeting, the presenter/author

introduces the material to all the participants in order to make them familiar with it. Even when

the walkthroughs can help in finding potential bugs, they are used for knowledge sharing or

communication purpose.

Buddy Checks:

This is the simplest type of review activity used to find out bugs in a work product during the

verification. In buddy check, one person goes through the documents prepared by another

person in order to find out if that person has made mistake(s) i.e. to find out bugs which the

author couldn’t find previously.

The activities involved in Verification process are: Requirement Specification verification,

Functional design verification, internal/system design verification and code verification (these

phases can also subdivided further). Each activity makes it sure that the product is developed

right way and every requirement, every specification, design code etc. is verified!

What is Validation?

Validation is a process of finding out if the product being built is right?

i.e. whatever the software product is being developed, it should do what the user expects it to

do. The software product should functionally do what it is supposed to, it should satisfy all the

functional requirements set by the user. Validation is done during or at the end of the

development process in order to determine whether the product satisfies specified

requirements.

Validation and Verification processes go hand in hand, but visibly Validation process starts after

Verification process ends (after coding of the product ends). Each Verification activity (such as

Requirement Specification Verification, Functional design Verification etc.) has its

corresponding Validation activity (such as Functional Validation/Testing, Code

Validation/Testing, System/Integration Validation etc.).

All types of testing methods are basically carried out during the Validation process. Test plan,

test suits and test cases are developed, which are used during the various phases of Validation

process. The phases involved in Validation process are: Code Validation/Testing, Integration

Validation/Integration Testing, Functional Validation/Functional Testing, and System/User

Acceptance Testing/Validation.

Terms used in Validation process:

Code Validation/Testing:

Developers as well as testers do the code validation. Unit Code Validation or Unit Testing is a

type of testing, which the developers conduct in order to find out any bug in the code

unit/module developed by them. Code testing other than Unit Testing can be done by testers or

developers.

Integration Validation/Testing:

Integration testing is carried out in order to find out if different (two or more) units/modules

co-ordinate properly. This test helps in finding out if there is any defect in the interface

between different modules.

Functional Validation/Testing:

This type of testing is carried out in order to find if the system meets the functional

requirements. In this type of testing, the system is validated for its functional behavior.

Functional testing does not deal with internal coding of the project, in stead, it checks if the

system behaves as per the expectations.

User Acceptance Testing or System Validation:

In this type of testing, the developed product is handed over to the user/paid testers in order to

test it in real time scenario. The product is validated to find out if it works according to the

system specifications and satisfies all the user requirements. As the user/paid testers use the

software, it may happen that bugs that are yet undiscovered, come up, which are

communicated to the developers to be fixed. This helps in improvement of the final product.

Software Testing - Acceptance Testing

Acceptance testing is associated not only with software field but also to any other field (such as

manufacturing, engineering, even non-technical) that involves a customer and a system

developed for the customer and developers of the system.

Acceptance testing (also known as user acceptance testing) is a type of testing carried out in

order to verify if the product is developed as per the standards and specified criteria and meets

all the requirements specified by customer. This type of testing is generally carried out by a

user/customer where the product is developed externally by another party.

Acceptance testing falls under black box testing methodology where the user is not very much

interested in internal working/coding of the system, but evaluates the overall functioning of the

system and compares it with the requirements specified by them. User acceptance testing is

considered to be one of the most important testing by user before the system is finally

delivered or handed over to the end user.

Acceptance testing is also known as validation testing, final testing, QA testing, factory

acceptance testing and application testing etc. And in software engineering, acceptance testing

may be carried out at two different levels; one at the system provider level and another at the

end user level (hence called user acceptance testing, field acceptance testing or end-user

testing).

Acceptance testing in software engineering generally involves execution of number test cases

which constitute to a particular functionality based on the requirements specified by the user.

During acceptance testing, the system has to pass through or operate in a computing

environment that imitates the actual operating environment existing with user. The user may

choose to perform the testing in an iterative manner or in the form of a set of varying

parameters (for example: missile guidance software can be tested under varying payload,

different weather conditions etc.).

The outcome of the acceptance testing can be termed as success or failure based on the critical

operating conditions the system passes through successfully/unsuccessfully and the user’s final

evaluation of the system.

The test cases and test criterion in acceptance testing are generally created by end user and

cannot be achieved without business scenario criteria input by user. This type of testing and

test case creation involves most experienced people from both sides (developers and users) like

business analysts, specialized testers, developers, end users etc.

Process involved in Acceptance Testing

1. Test cases are created with the help of business analysts, business customers (end

users), developers, test specialists etc.

2. Test cases suites are run against the input data provided by the user and for the number

of iterations that the customer sets as base/minimum required test runs.

3. The outputs of the test cases run are evaluated against the criterion/requirements

specified by user.

4. Depending upon the outcome if it is as desired by the user or consistent over the

number of test suites run or non conclusive, user may call it successful/unsuccessful or

suggest some more test case runs.

5. Based on the outcome of the test runs, the system may get rejected or accepted by the

user with or without any specific condition.

Acceptance testing is done in order to demonstrate the ability of system/product to perform as

per the expectations of the user and induce confidence in the newly developed

system/product. A sign-off on contract stating the system as satisfactory is possible only after

successful acceptance testing.

Types of Acceptance Testing

User Acceptance Testing: User acceptance testing in software engineering is considered to be

an essential step before the system is finally accepted by the end user. In general terms, user

acceptance testing is a process of testing the system before it is finally accepted by user.

Alpha Testing & Beta Testing: Alpha testing is a type of acceptance testing carried out at

developer’s site by users (internal staff). In this type of testing, the user goes on testing the

system and the outcome is noted and observed by the developer simultaneously.

Beta testing is a type of testing done at user’s site. The users provide their feedback to the

developer for the outcome of testing. This type of testing is also known as field testing.

Feedback from users is used to improve the system/product before it is released to other

users/customers.

Operational Acceptance Testing: This type of testing is also known as operational

readiness/preparedness testing. It is a process of ensuring all the required components

(processes and procedures) of the system are in place in order to allow user/tester to use it.

Contact and Regulation Acceptance Testing: In contract and regulation acceptance testing, the

system is tested against the specified criteria as mentioned in the contract document and also

tested to check if it meets/obeys all the government and local authority regulations and laws

and also all the basic standards.

Software Testing - Brief Introduction To Exploratory Testing

Exploratory Software Testing, even though disliked by many, has found its place in the Software

Testing world. Exploratory testing is the only type of testing that can help in uncovering bugs

that stand more chance of being ignored by other testing strategies...

What is an Exploratory Testing?

Bach’s Definition: ‘Any testing to the extent that the tester actively controls the design of the

tests as those tests are performed and uses information gained while testing to design new and

better tests.’

Which simply can be put as: A type of testing where we explore software, write and execute the

test scripts simultaneously.

Exploratory testing is a type of testing where tester does not have specifically planned test

cases, but he/she does the testing more with a point-of-view to explore the software features

and tries to break it in order to find out unknown bugs.

A tester who does exploratory testing, does it only with an idea to more and more understand

the software and appreciate its features. During this process, he/she also tries to think of all

possible scenarios where the software may fail and a bug can be revealed.

Why do we need exploratory testing?

At times, exploratory testing helps in revealing many unknown and un-detected bugs,

which is very hard to find out through normal testing.

As exploratory testing covers almost all the normal type of testing, it helps in improving

our productivity in terms of covering the scenarios in scripted testing and those which

are not scripted as well.

Exploratory Testing is a learn and work type of testing activity where a tester can at least

learn more and understand the software if at all he/she was not able to reveal any

potential bug.

Exploratory testing, even though disliked by many, helps testers in learning new

methods, test strategies, and also think out of the box and attain more and more

creativity.

Who Does Exploratory Testing?

Any software tester knowingly or unknowingly does it!

While testing, if a tester comes across a bug, as a general practice, tester registers that bug with

the programmer. Along with registering the bug, tester also tries to make it sure that he/she

has understood the scenario and functionality properly and can reproduce the bug condition.

Once programmer fixes the bug, tester runs a test case with the same scenario replication in

which the bug had occurred previously. If tester finds that the bug is fixed, he/she again tries to

find out if the fix can handle any such same type of scenario with different inputs.

For an example, lets consider that a tester finds a bug related to an input text field on a form,

where the field is supposed to accept any digit other than the digits from 1 to 100, which it fails

to and accepts the number 100. Tester logs this bug to the programmer and now is waiting for

the fix. Once programmer fixes the bug, it sends it across to the tester so as to get it tested.

Tester now will try to test the bug with same input value (100: as he/she had found that this

condition causes application to fail) in the field. If application rejects the number (100) entered

by the tester, he/she can safely close the defect.

Now, along with the above given test input value, which had revealed the bug, tester tries to

check if there is any other value from this set (0 to 100), which can cause the application to fail.

He/she may try to enter values from 0 to 100, or may be some characters or a combination of

character and numbers in any order. All these test cases are thought by the tester as a variation

of the type of value he/she had entered previously and represent only one test scenario. This

testing is called exploratory testing, as the tester tried to explore and find out the possibility of

revealing a bug by using any possible way.

What qualities I need to posses to be able to perform an Exploratory Testing?

As I mentioned above, any software tester can perform exploratory testing.

The only limit to the extent to which you can perform exploratory testing is your imagination

and creativity, more you can think of ways to explore, understand the software, more test cases

you will be able write and execute simultaneously.

Advantages of Exploratory Testing

Exploratory testing can uncover bugs, which are normally ignored (or hard to find) by

other testing strategies.

It helps testers in learning new strategies, expand the horizon of their imagination that

helps them in understanding & executing more and more test cases and finally improve

their productivity.

Exploratory testing helps tester in confirming that he/she understands the application

and its functionality properly and has no confusion about the working of even a smallest

part of it, hence covering the most important part of requirement understanding.

As in case of exploratory testing, we write and execute the test cases simultaneously. It

helps in collecting result oriented test scripts and shading of load of unnecessary test

cases which do not yield and result.

Exploratory testing covers almost all type of testing, hence tester can be sure of

covering various scenarios once exploratory testing is performed at the highest level (i.e.

if the exploratory testing performed can ensure that all the possible scenarios and test

cases are covered).

Custom Software Development

Custom software development is very known term to those companies who wants a software

solution which suits to their requirements. It is not always necessary that ready made software

satisfy the functional requirement of any organization. For such cases Custom software

development is required.

As the name suggest, custom software development, also called custom software engineering,

is one that is tailor made to the special requirements of the customer. Obviously customer

software development would rise above the pre-developed, template or boxed solutions. It

would be unique in conception, design and development achieved on one time basis.

Custom software is, therefore, developed for specific functions and is quite different from the

existing or the off-the-shelf software. It is not addressed to mass market.

Examples of custom software development include accounting software, customized software

for budget or project managing, software for commercial products such as e-commerce

websites, business data bases, software for special needs of the companies, business entities,

organizations, smaller companies, charities and individuals, industries and government.

It is quite evident from the above explanation that custom software can be developed only on a

small scale. Custom software development is a complex process and is usually founded on pre-

built building blocks which are rearranged, re-organized or re-engineered to suit the individual

needs of the clients.

If you wish to have software built to your individual needs, you will have to first explain your

needs, the viability and affordability of the software. This would entail formation of a detailed

proposal for the development of the design of the software and building a system for its

operation.

You will need to draw a contract with the custom software development company about the

time frame of delivery, cost and functionality. It is important that the product is delivered

functionally complete and ready for testing and deployment by the end user.

According to Blueberry Consultants, there are certain other important questions that need to

be addressed before signing the contract and some of them are:

Who will own the copyright of the product - the producer or its owner or the payer?

How will the system be built? Would it be built on the top of any other platform or

system?

Will the system use or depend upon the third party systems or libraries. And will it entail

copyright violations?

Who will control the source code?

Who will collect the requirements from the customer?

Will the system provide for firewall configuration?

What is the expertise and experience of the software developing company?

What is the strength of their expert staff?

What programming languages will be used?

Will they incorporate any logging system in the software to report and prevent bugs?

Interview Questions for Software Testing

Software Testing Interview Questions on Product Testing

What will be the test cases for product testing? Give an example of test plan template.

What are the advantages of working as a tester for a product based company as

opposed to a service based company?

Do you know how a product based testing differs from a project based testing? Can you

give a suitable example?

Do you know what is exactly meant by Test Plan? Name its contents? Can you give a

sample Test Plan for a Login Screen?

How do you differentiate between testing a product and testing any web-based

application?

What is the difference between Web based testing and Client server testing?

How to perform SOAP Testing manually?

Explain the significance of Waterfall model in developing a product.

Software Testing Interview Questions on Quality Assurance

How do you ensure the quality of the product?

What do you do when there isn't enough time for thorough testing?

What are the normal practices of the QA specialists with perspective of a software?

Can you tell the difference between high level design and low level design?

Can you tell us how Quality Assurance differs from Quality Control?

You must have heard the term Risk. Can you explain the term in a few words? What are

the major components of the risk?

When do you say your project testing is completed? Name the factors.

What do you mean by a walk through and inspection?

What is the procedure for testing search buttons of a web application both manually

and using Qtp8.2?

Explain Release Acceptance Testing. Explain Forced Error Testing. Explain Data Integrity

Testing. Explain System Integration Testing.

How does compatibility testing differ while testing in Internet explorer and testing in

Firefox?

Software Testing Interview Questions on Testing Scenarios

How do you know that all the scenarios for testing are covered?

Can you explain the Testing Scenario? Also explain scenario based testing? Give an

example to support your answer.

Consider a yahoo application. What are the test cases you can write?

Differentiate between test scenario and test case?

Is it necessary to create new Software requirement document, test planning report, if it

is a 'Migrating Project'?

Explain the difference between smoke testing and sanity testing?

What are all the scenarios to be considered while preparing test reports?

What is an 'end to end' scenario?

Other than requirement traceability matrix, what are the other factors that we need to

check in order to exit a testing process ?

What is the procedure for finding out the length of the edit box through WinRunner?

Software Testing Interview Questions on Automated Testing

What automated testing tools are you familiar with?

Describe some problems that you encountered while working with an automated

testing tool.

What is the procedure for planning test automation?

What is your opinion on the question that can a test automation improve test

effectiveness?

Can you explain data driven automation?

Name the main attributes of test automation?

Do you think automation can replace manual testing?

How is a tool for test automation chosen?

How do you evaluate the tool for test automation?

What are the main benefits of test automation according to you?

Where can test automation go wrong?

Can you describe testing activities?

What testing activities you need to automate?

Describe common issues of test automation.

What types of scripting techniques for test automation are you aware of?

Name the principles of good testing scripts for automation?

What tools can you use for support of testing during the software development life

cycle?

Can you tell us it the activities of a test case design be automated?

What are the drawbacks of automated software testing?

What skills are needed to be a good software test automator?

Software Testing Interview Questions on Bug Tracking

Can you have a defect with high severity and low priority and vice-versa i.e high priority

and low severity? Justify your answer.

Can you explain the difference between a Bug and a Defect? Explain the phases of bug

life cycle

What are the different types of Bugs we normally see in any of the projects? Also

include their severity.

What is the difference between Bug Resolution Meeting and Bug Review Committee?

Who all participate in Bug Resolution Meeting and Bug Review Committee?

Can you name some recent major computer system failures caused by software bugs?

What do you mean by 'Reproducing a bug'? What do you do, if the bug was not

reproducible?

How can you tell if a bug is reproducible or not?

On what basis do we give priority and severity for a bug. Provide an example for high

priority and low severity and high severity and low priority?

Explain Defect Life Cycle in Manual Testing?

How do you give a BUG Title & BUG Description for ODD Division?

Have you ever heard of a build interval period?

Software testing is a vast field and there is really no dearth of software testing interview

questions. You can explore the Internet for more software testing interview questions and of

course, the solutions. Hope this article helps you to get the job of your dreams. Good Luck!

Software Testing - Test Cases

What are test cases in software testing, how they are designed and why they are so important

to the entire testing scenario, read through to know more..

What is a Test Case?

A test case is a set of conditions or variables and inputs that are developed for a particular goal

or objective to be achieved on a certain application to judge its capabilities or features.

It might take more than one test case to determine the true functionality of the application

being tested. Every requirement or objective to be achieved needs at least one test case. Some

software development methodologies like Rational Unified Process (RUP) recommend creating

at least two test cases for each requirement or objective; one for performing testing through

positive perspective and the other through negative perspective.

Test Case Structure

A formal written test case comprises of three parts -

1. Information

Information consists of general information about the test case. Information

incorporates Identifier, test case creator, test case version, name of the test case,

purpose or brief description and test case dependencies.

2. Activity

Activity consists of the actual test case activities. Activity contains information about the

test case environment, activities to be done at test case initialization, activities to be

done after test case is performed, step by step actions to be done while testing and the

input data that is to be supplied for testing.

3. Results

Results are outcomes of a performed test case. Results data consist of information

about expected results and the actual results.

Designing Test Cases

Test cases should be designed and written by someone who understands the function or

technology being tested. A test case should include the following information -

Purpose of the test

Software requirements and Hardware requirements (if any)

Specific setup or configuration requirements

Description on how to perform the test(s)

Expected results or success criteria for the test

Designing test cases can be time consuming in a testing schedule, but they are worth giving

time because they can really avoid unnecessary retesting or debugging or at least lower it.

Organizations can take the test cases approach in their own context and according to their own

perspectives. Some follow a general step way approach while others may opt for a more

detailed and complex approach. It is very important for you to decide between the two

extremes and judge on what would work the best for you. Designing proper test cases is very

vital for your software testing plans as a lot of bugs, ambiguities, inconsistencies and slip ups

can be recovered in time as also it helps in saving your time on continuous debugging and re-

testing test cases.

The main purpose behind any Software Development process is to provide the client (Final/End

User of the software product) with a complete solution (software product), which will help him

in managing his business/work in cost effective and efficient way. A software product

developed is considered successful if it satisfies all the requirements stated by the end user.

Any software development process is incomplete if the most important phase of Testing of the

developed product is excluded. Software testing is a process carried out in order to find out and

fix previously undetected bugs/errors in the software product. It helps in improving the quality

of the software product and make it secure for client to use.

What is a bug/error?

A bug or error in software product is any exception that can hinder the functionality of either

the whole software or part of it.

How do I find out a BUG/ERROR?

Basically, test cases/scripts are run in order to find out any unexpected behavior of the

software product under test. If any such unexpected behavior or exception occurs, it is called as

a bug.

What is a Test Case?

A test case is a noted/documented set of steps/activities that are carried out or executed on

the software in order to confirm its functionality/behavior to certain set of inputs.

What do I do if I find a bug/error?

In normal terms, if a bug or error is detected in a system, it needs to be communicated to the

developer in order to get it fixed.

Right from the first time any bug is detected till the point when the bug is fixed and closed, it is

assigned various statuses which are New, Open, Postpone, Pending Retest, Retest, Pending

Reject, Reject, Deferred, and Closed.

(Please note that there are various ways to communicate the bug to the developer and track

the bug status)

Statuses associated with a bug:

New:

When a bug is found/revealed for the first time, the software tester communicates it to his/her

team leader (Test Leader) in order to confirm if that is a valid bug. After getting confirmation

from the Test Lead, the software tester logs the bug and the status of ‘New’ is assigned to the

bug.

Assigned:

After the bug is reported as ‘New’, it comes to the Development Team. The development team

verifies if the bug is valid. If the bug is valid, development leader assigns it to a developer to fix

it and a status of ‘Assigned’ is assigned to it.

Open:

Once the developer starts working on the bug, he/she changes the status of the bug to ‘Open’

to indicate that he/she is working on it to find a solution.

Fixed:

Once the developer makes necessary changes in the code and verifies the code, he/she marks

the bug as ‘Fixed’ and passes it over to the Development Lead in order to pass it to the Testing

team.

Pending Retest:

After the bug is fixed, it is passed back to the testing team to get retested and the status of

‘Pending Retest’ is assigned to it.

Retest:

The testing team leader changes the status of the bug, which is previously marked with

‘Pending Retest’ to ‘Retest’ and assigns it to a tester for retesting.

Closed:

After the bug is assigned a status of ‘Retest’, it is again tested. If the problem is solved, the

tester closes it and marks it with ‘Closed’ status.

Reopen:

If after retesting the software for the bug opened, if the system behaves in the same way or

same bug arises once again, then the tester reopens the bug and again sends it back to the

developer marking its status as ‘Reopen’.

Pending Reject:

If the developers think that a particular behavior of the system, which the tester reports as a

bug has to be same and the bug is invalid, in that case, the bug is rejected and marked as

‘Pending Reject’.

Rejected:

If the Testing Leader finds that the system is working according to the specifications or the bug

is invalid as per the explanation from the development, he/she rejects the bug and marks its

status as ‘Rejected’.

Postponed:

Sometimes, testing of a particular bug has to be postponed for an indefinite period. This

situation may occur because of many reasons, such as unavailability of Test data, unavailability

of particular functionality etc. That time, the bug is marked with ‘Postponed’ status.

Deferred:

In some cases a particular bug stands no importance and is needed to be/can be avoided, that

time it is marked with ‘Deferred’ status.

Software Testing Life Cycle

The software testing life cycle identifies various testing activities and also explains which testing

activity needs to be carried out when. Different phases of the life cycle of software testing have

been explained in this article. So, read on.

Introduction to Software Testing Life Cycle

Every organization has to undertakes testing of each of its products. However, the way it is

conducted differs from one organization to another. This refers to the life cycle of the testing

process. It is advisable to carry out the testing process from the initial phases, with regard to

theSoftware Development Life Cycle or SDLC to avoid any complications.

Software Testing Life Cycle Phases

Software testing has its own life cycle that meets every stage of the SDLC. The software testing

life cycle diagram can help one visualize the various software testing life cycle phases. They are

1. Requirement Stage

2. Test Planning

3. Test Analysis

4. Test Design

5. Test Verification and Construction

6. Test Execution

7. Result Analysis

8. Bug Tracking

9. Reporting and Rework

10. Final Testing and Implementation

11. Post Implementation

Requirement Stage

This is the initial stage of the life cycle process in which the developers take part in analyzing

the requirements for designing a product. Testers can also involve themselves as they can think

from the users' point of view which the developers may not. Thus a panel of developers, testers

and users can be formed. Formal meetings of the panel can be held in order to document the

requirements discussed which can be further used as software requirements specifications or

SRS.

Test Planning

Test planning is predetermining a plan well in advance to reduce further risks. Without a good

plan, no work can lead to success be it software-related or routine work. A test plan document

plays an important role in achieving a process-oriented approach. Once the requirements of the

project are confirmed, a test plan is documented. The test plan structure is as follows:

1. Introduction: This describes the objective of the test plan.

2. Test Items The items that are referred to prepare this document will be listed here such

as SRS, project plan.

3. Features to be tested: This describes the coverage area of the test plan, ie. the list of

features that are to be tested that are based on the implicit and explicit requirements

from the customer.

4. Features not to be tested: The incorporated or comprised features that can be skipped

from the testing phase are listed here. Features that are out of scope of testing, like

incomplete modules or those on low severity eg. GUI features that don't hamper the

further process can be included in the list.

5. Approach: This is the test strategy that should be appropriate to the level of the plan. It

should be in acceptance with the higher and lower levels of the plan.

6. Item pass/fail criteria: Related to the show stopper issue. The criterion which is used has

to explain which test item has passed or failed.

7. Suspension criteria and resumption requirements: The suspension criterion specifies the

criterion that is to be used to suspend all or a portion of the testing activities, whereas

resumption criterion specifies when testing can resume with the suspended portion.

8. Test deliverable: This includes a list of documents, reports, charts that are required to be

presented to the stakeholders on a regular basis during testing and when testing is

completed.

9. Testing tasks: This stage is needed to avoid confusion whether the defects should be

reported for future function. This also helps users and testers to avoid incomplete

functions and prevent waste of resources.

10. Environmental needs: The special requirements of that test plan depending on the

environment in which that application has to be designed are listed here.

11. Responsibilities: This phase assigns responsibilities to the person who can be held

responsible in case of a risk.

12. Staffing and training needs: Training on the application/system and training on the

testing tools to be used needs to be given to the staff members who are responsible for

the application.

13. Risks and contingencies:This emphasizes on the probable risks and various events that

can occur and what can be done in such situation.

14. Approval: This decides who can approve the process as complete and allow the project

to proceed to the next level that depends on the level of the plan.

Test Analysis

Once the test plan documentation is done, the next stage is to analyze what types of software

testing should be carried out at the various stages of SDLC.

Test Design

Test design is done based on the requirements of the project documented in the SRS. This

phase decides whether manual or automated testing is to be done. In automation testing,

different paths for testing are to be identified first and writing of scripts has to be done if

required. There originates a need for an end to end checklist that covers all the features of the

project.

Test Verification and Construction

In this phase test plans, the test design and automated script tests are completed. Stress and

performance testing plans are also completed at this stage. When the development team is

done with a unit of code, the testing team is required to help them in testing that unit and

reporting of the bug if found. Integration testing and bug reporting is done in this phase of the

software testing life cycle.

Test Execution

Planning and execution of various test cases is done in this phase. Once the unit testing is

completed, the functionality of the tests is done in this phase. At first, top level testing is done

to find out top level failures and bugs are reported immediately to the development team to

get the required workaround. Test reports have to be documented properly and the bugs have

to be reported to the development team.

Result Analysis

Once the bug is fixed by the development team, i.e after the successful execution of the test

case, the testing team has to retest it to compare the expected values with the actual values,

and declare the result as pass/fail.

Bug Tracking

This is one of the important stages as the Defect Profile Document (DPD) has to be updated for

letting the developers know about the defect. Defect Profile Document contains the following

1. Defect Id: Unique identification of the Defect.

2. Test Case Id: Test case identification for that defect.

3. Description: Detailed description of the bug.

4. Summary: This field contains some keyword information about the bug, which can help

in minimizing the number of records to be searched.

5. Defect Submitted By: Name of the tester who detected/reported the bug.

6. Date of Submission: Date at which the bug was detected and reported.

7. Build No.: Number of test runs required.

8. Version No.: The version information of the software application in which the bug was

detected and fixed.

9. Assigned To: Name of the developer who is supposed to fix the bug.

10. Severity: Degree of severity of the defect.

11. Priority: Priority of fixing the bug.

12. Status: This field displays current status of the bug.

The contents of a bug well explain all the above mentioned things.

Reporting and Rework

Testing is an iterative process. The bug once reported and as the development team fixes the

bug, it has to undergo the testing process again to assure that the bug found is resolved.

Regression testing has to be done. Once the Quality Analyst assures that the product is ready,

the software is released for production. Before release, the software has to undergo one more

round of top level testing. Thus testing is an ongoing process.

Final Testing and Implementation

This phase focuses on the remaining levels of testing, such as acceptance, load, stress,

performance and recovery testing. The application needs to be verified under specified

conditions with respect to the SRS. Various documents are updated and different matrices for

testing are completed at this stage of the software testing life cycle.

Post Implementation

Once the tests are evaluated, the recording of errors that occurred during various levels of the

software testing life cycle, is done. Creating plans for improvement and enhancement is an

ongoing process. This helps to prevent similar problems from occuring in the future projects. In

short, planning for improvement of the testing process for future applications is done in this

phase.