What is the difference between Test Condition and Test Scenario?

What is the difference between Test Condition and Test Scenario?

Ands 1:- Test condition is the condition which is the Process that you should follow to test an application.

Ex: - You Have Login Form.
Test Condition 1:- when User Name and Password are valid
Then application will move forward.
The above one is the test condition which is the basic Condition where that tests process will get pass.

Test Scenario:-Test Scenario will tell you the possible Ways of scenarios (ways) that an application can be tested.

For above Login Form you have simony ways of testing
I.E Positive testing .Negative Testing, B.V.A Like.

Explain the waterfall model in detail?

Every testing process follow the waterfall model of the
Testing process.
Test strategy and planning
Test design
Test environment setup
Test execution
Defect analysis and tracking
Final reporting

Waterfall Model:
It is a linear sequential model
It is very simple model to implement
It is the first model.
It needs very few resources to implement

In this model there is no back tracking.
For example if any error occurred an any Stage of software development, it can’t be Corrected in that build

Water fall model: - This is very simple model. It moves Like water fall from top to down of SDLC. The drawback of This model is ineffectiveness of verification and
Validation activities.

What is mean by mr?

MR means Modification request When ever the changes comes from the client then we call it As Modification request, from that MR business people will Find the impact analysis for particular MR

What are bug traceability matrix and its format?
Functional specify action name, Number, Design specification Number, Test case number, Test result, Test pass/fail, Defect Number, Defect status.

These all columns under traceability matrix format.

Waterfall Model

The waterfall model:

 

 Software Development Process:

 

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".

Water Fall Model

Ø       The classic software life cycle model.

Ø       First Process Model to be introduced and followed widely in Software Engineering to ensure success of the project.

Ø       The whole process of software development is divided into separate process phases.

Ø       All the 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".

Also Known as  The linear sequential model

 

Waterfall Model Process Flow
 

Testing actually involves two steps:

Verification

Validation

Verification

Ø       Verification is substantiating that the software has been transformed from one form into another as intended with sufficient accuracy.

Ø       Verification answers the question "Are we building the software right?".

Validation

Ø Validation is substantiating that the software functions with sufficient accuracy with respect to its requirements specification.

Ø Validation answers the question "Are we building the right software?"

Ø In order to represent the testing activity as an ongoing process, the V&V boxes appear under each product of the Waterfall Model.

Ø       One important characteristic of the Waterfall Model is the  iteration rrows that join the processes together.

 

 

Another important characteristic of the Waterfall Model is the maintenance arrows which connect the delivered software product to the various other products in the life cycle.

 

Ø       Remember that any changes made to the software product after delivery are considered maintenance.

Ø       A small change such as the correction of a programming error may only require a change in the code of the software.

Ø       Requirement Analysis & Definition

Ø       System & Software Design

Ø       Implementation & Unit Testing

Ø       Integration & System Testing

Ø       Operations & Maintenance

Ø       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.

 

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

Ø       Great at addressing subtle issues like scalability, reliability

Ø       Specifications are built into the project

Ø       Discovery happens early. Projects follow a predictable cycle. Early identification of what will be difficult or expensive about a project allows go/no-go decisions to be made before too much money is spent.

Ø       Simple and easy to use.

Ø       Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.

Ø       Phases are processed and completed one at a time.

Ø       Works well for smaller projects where requirements are very well understood.

Ø       Minimizes planning overhead since it can be done up front.

Ø       Structure minimizes wasted effort, so it works well for technically weak or inexperienced staff.

 

Disadvantages

 

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

 

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

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

 

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

Ø       Relatively high risk of process paralysis

Ø       Only the final phase produces a non-documentation deliverable.

Ø       Backing up to address mistakes is difficult

Ø       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.

Ø       The project is not partitioned in phases in flexible way. 

Ø        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 never version of the system; this increases the cost of system development.