Testing Types

Black-box Testing: 
A test technique that focuses on testing the functionality of the
program component or application against its specifications without knowledge of how the
system constructed.

Boundary value analysis: 
A data selection technique in which test data is chosen from the
"boundaries" of the input or output domain classes, data structures and procedure
parameters. Choices often include the actual minimum and maximum boundary values, the
maximum value plus or minus one and the minimum value plus or minus one.

Branch Testing:  
A test method that requires that each possible branch on each decision be
executed on at least once.

Brainstorming:
A group process for generating creative and diverse ideas.

Bug: 
A catchall term for all software defects or errors.

Certification testing: 
Acceptance of software by an authorized agent after the software
has been validated by the agent or after its validity has been demonstrated to the agent.

Checkpoint(or verification point): 
Expected behaviour of the application which must be
validated with the actual behaviour after certain action has been performed on the
application.

Client:  
The customer that pays for the product received and receives the benefit from the
use of the product.

Condition Coverage: 
A white-box testing technique that measures the number of or
percentage of decision outcomes covered by the test cases designed.100% condition
coverage would indicate that every possible outcome of each decision had been executed at
least once during testing.

Configuration Management Tools
Tools that are used to keep track of changes made to systems and all related artifacts.
These are also known as version control tools.

Configuration testing: 
Testing of an application on all supported hardware and software
platforms.This may include various combinations of hardware types, configuration settings
and software versions.

Completeness: 
A product is said to be complete if it has met all requirements.

Consistency: 
Adherence to a given set of rules.

Correctness: 
The extent to which software is free from design and coding defects. It is
also the extent to which software meets the specified requirements and user objectives.

Cost of Quality: 
Money spent above and beyond expected production costs to ensure that
the product the customer receives is a quality product. The cost of quality includes
prevention, appraisal, and correction or repair costs.


Conversion Testing: 
Validates the effectiveness of data conversion processes, including
field-field mapping and data translation.

Debugging: 
The process of analysing and correcting syntactic, logic and other errors
identified during testing.

Decision Coverage: 
A white-box testing technique that measures the number of - or
percentage - of decision directions executed by the test case designed. 100% Decision
coverage would indicate that all decision directions had been executed at least once during
testing. Alternatively each logical path through the program can be tested.

Decision Table
A tool for documenting the unique combinations of conditions and associated results in
order to derive unique test cases for validation testing.

Defect Tracking Tools
Tools for documenting defects as they are found during testing and for
tracking their status through to resolution.

Desk Check: 
A verification technique conducted by the author of the artifcat to verify the
completeness of their own work. This technique does not involve anyone else.

Dynamic Analysis: 
Analysis performed by executing the program code.Dynamic analysis
executes or simulates a development phase product and it detects errors by analyzing the
response of the product to sets of input data.

Entrance Criteria: 
Required conditions and standards for work product quality that must be
present or met for entry into the next stage of the software development process.

Equivalence Partitioning: 
A test technique that utilizes a subset of data that is
representative of a larger class. This is done in place of undertaking exhaustive testing of
each value of the larger class of data.

Error or defect: 
1.A discrepancy between a computed, observed or measured value or
condition and the true, specified or theortically correct value or conditon 2.Human action
that results in software containing a fault (e.g., omission or misinterpretation of user
requirements in a software specification, incorrect translation or omission of a requirement
in the design specification)

Error Guessing: 
Test data selection techniques for picking values that seem likely to cause
defects. This technique is based upon the theory that test cases and test data can be
developed based on intuition and experience of the tester.

Exhaustive Testing: 
Executing the program through all possible combination of values for
program variables.

Exit criteria: 
Standards for work product quality which block the promotion of incomplete
or defective work products to subsequent stages of the software development process.

Customer: 
The individual or organization, internal or external to the producing organization
that receives the product.

Cyclomatic complexity: 
The number of decision statements plus one.

Debugging: 
The process of analysing and correcting syntactic, logic and other errors
identified during testing.

Decision Coverage: 
A white-box testing technique that measures the number of - or
percentage - of decision directions executed by the test case designed. 100% Decision
coverage would indicate that all decision directions had been executed at least once during
testing. Alternatively each logical path through the program can be tested.

Decision Table
A tool for documenting the unique combinations of conditions and associated results in
order to derive unique test cases for validation testing.

Defect Tracking Tools
Tools for documenting defects as they are found during testing and for
tracking their status through to resolution.

Desk Check: 
A verification technique conducted by the author of the artifcat to verify the
completeness of their own work. This technique does not involve anyone else.

Dynamic Analysis: 
Analysis performed by executing the program code.Dynamic analysis
executes or simulates a development phase product and it detects errors by analyzing the
response of the product to sets of input data.

Entrance Criteria: 
Required conditions and standards for work product quality that must be
present or met for entry into the next stage of the software development process.

Equivalence Partitioning: 
 A test technique that utilizes a subset of data that is
representative of a larger class. This is done in place of undertaking exhaustive testing of
each value of the larger class of data.

Error or defect: 
1.A discrepancy between a computed, observed or measured value or
condition and the true, specified or theoretically correct value or condition 2.Human action
that results in software containing a fault (e.g., omission or misinterpretation of user
requirements in a software specification, incorrect translation or omission of a requirement
in the design specification)

Error Guessing: 
Test data selection techniques for picking values that seem likely to cause
defects. This technique is based upon the theory that test cases and test data can be
developed based on intuition and experience of the tester.

Exhaustive Testing: 
Executing the program through all possible combination of values for
program variables.

Exit criteria: 
Standards for work product quality which block the promotion of incomplete
or defective work products to subsequent stages of the software development process.

spiral model

The spiral model

The spiral model, combines the iterative nature of
prototyping with the controlled and systematic aspects of the waterfall model,
therein providing the potential for rapid development of incremental versions of
the software. In this model the software is developed in a series of incremental
releases with the early stages being either paper models or prototypes.
iterations become increasingly more complete versions of the product.
, the model is divided into a number of task regions.
Depending on the model it may have 3-6 task regions (/framework
activities) our case will consider a ‘6-task region’ model.

These regions are:

1. The customer communication task – to establish effective communication
between developer and customer.
2. The planning task – to define resources, time lines and other project
related information..
3. The risk analysis task – to assess both technical and management risks.
4. The engineering task – to build one or more representations of the
application.
5. The construction and release task – to construct, test, install and provide
user support (e.g., documentation and training).
6. The customer evaluation task – to obtain customer feedback based on the
evaluation of the software representation created during the engineering
stage and implemented during the install stage.
The evolutionary process begins at the centre position and moves in a clockwise
direction. Each traversal of the spiral typically results in a deliverable. For
example, the first and second spiral traversals may result in the production of a
product specification and a prototype, respectively. Subsequent traversals may
then produce more sophisticated versions of the software.
An important distinction between the spiral model and other software models is
the explicit consideration of risk. There are no fixed phases such as specification
or design phases in the model and it encompasses other process models. For
example, prototyping may be used in one spiral to resolve requirement
uncertainties and hence reduce risks. This may then be followed by a
conventional waterfall development.

• Note that each passage through the planning stage results in an adjustment

to the project plan (e.g. cost and schedule are adjusted based on the
feedback from the customer, project manager may adjust the number of
iterations required to complete the software….)

• Each of the regions is populated by a set of work tasks called a task set that

are adapted to characteristics of the project to be undertaken. For small
projects the number of tasks and their formality is low. Conversely, for large
projects the reverse is true.

Advantages 

• The spiral model is a realistic approach to the development of large-scale
software products because the software evolves as the process progresses.
In addition, the developer and the client better understand and react to risks
at each evolutionary level.
• The model uses prototyping as a risk reduction mechanism and allows for
the development of prototypes at any stage of the evolutionary
development.
• It maintains a systematic stepwise approach, like the classic life cycle
model, but incorporates it into an iterative framework that more reflect the
real world.
• If employed correctly, this model should reduce risks before they become
problematic, as consideration of technical risks are considered at all stages.

Disadvantages:

• Demands considerable risk-assessment expertise
• It has not been employed as much proven models (e.g. the WF model) and

hence may prove difficult to ‘sell’ to the client (esp. where a contract is
involved) that this model is controllable and efficient. [More study needs to
be done in this regard

Proto Type and V-Model

Prototype Model:

•      This is most popular model in IT industry 
•      This model is suitable when the client is not clear about the requirements
•       It is defined as rapidly developed model

Advantages:

• Requirements are defined and extracted from the customer
• Clients environments are conform
• Use of winnings the customer
• To win the customer confidence and to freeze customer requirements

Disadvantages:

• client may stick to this prototype and limit this functionality to it
• it was being built on the cost of the company
• it is not a full model use and throw model
• v model: v stands for verification and validation
• this model defines mapping between software development stages and testing  stages this model is derived from fish model   

 The V- Shaped model

• excellent choice for systems requiring high reliability hospital patient control applications
• all requirements are known up front
• when it can be modified to handle changing requirements beyond analysis 
• solution and technology are known
  v shaped weaknesses
• does not easily handle concurrent events
• does not handle iterations or phases
• does not easily handle dynamic changes in requiments
• Dos not contain risk anaysis activities        

v - shaped Strengths

• Emphasize planning for verfication and validation of the product in early stages of product development
• Each deliverable must be testable
• Project management can track progress by milestones
• Easy to use

Refinement From of V-Model

• V-Model is expensive process for small scale and medium scale organization, Due to this reason, small scale and medium scale Organization are maintaing separate V stands for Verification and Validation,
• Verification done by the developer and QAE
• Test Engineer does Validation

Advantages
the outcome is a qualitive output because each and every Phase well Planned reviewed and Evaluated

Disadvantages
It is very costly model 
Lot of time is consumed due to planning

Software Development Models

Water Fall model

After completing one Phase then next phase is implemented . Water fall model can  

waterfall model strength 

• Easy to understand and easy to use
• work well when quality is more important than cost or schedule
• milestones are well understand

Drawbacks:

• All requirement must be Known upfront
• can give false impression of progress
• Technology must understand

The waterfall model

The waterfall model derives its name due to the cascading effect from one phase
to the other as is illustrated in Figure1.1. In this model each phase well defined
starting and ending point, with identifiable deliveries to the next phase.
Note that this model is sometimes referred to as the linear sequential model or
the software life cycle.

The model consist of six distinct stages, namely:

1. In the requirements analysis phase
(a) The problem is specified along with the desired service objectives
(goals)
(b) The constraints are identified

2. In the specification phase the system specification is produced from the
detailed definitions of (a) and (b) above. This document should clearly
define the product function.
Note that in some text, the requirements analysis and specifications
phases are combined and represented as a single phase.

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

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

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

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

• Detailed documentation from the design phase can significantly reduce the coding effort
• Testing at this stage focuses on making sure that any errors are

identified and that the software meets its required specification.

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

6. The maintenance phase the usually the longest stage of the software. In this
phase the software is updated to:
Meet the changing customer needs

• Adapted to accommodate changes in the external environment
• Correct errors and oversights previously undetected in the testing phases
• Enhancing the efficiency of the software

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

• It is an enforced disciplined approach
• It is documentation driven, that is, documentation is produced at every stage

Disadvantages

The waterfall model is the oldest and the most widely used paradigm.
However, many projects rarely follow its sequential flow. This is due to the
inherent problems associated with its rigid format. Namely:

1)  It only incorporates iteration indirectly, thus changes may cause
considerable confusion as the project progresses.

2)  As The client usually only has a vague idea of exactly what is required
from the software product, this WM has difficulty accommodating the
natural uncertainty that exists at the beginning of the project.

3)  The customer only sees a working version of the product after it has been
coded. This may result in disaster if any undetected problems are
precipitated to this stage.