Software Testing: Quick Learn

 

Software Testing Introduction:

 

Software Testing is the process of executing a program or system with the intent of finding errors. Or, it involves any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results.

 

Software Testing is a process of executing software in a controlled manner. When the end product is given to the client, it should work correctly according to the specifications and requirements of the software. Defect in software is the variance between the actual and expected results.

 

Software bugs will almost always exist in any software module with moderate size: not because programmers are careless or irresponsible, but because the complexity of software is generally intractable -- and humans have only limited ability to manage complexity. It is also true that for any complex systems, design defects can never be completely ruled out.

 

Software Testing can also be stated as a process used to help identify the correctness, completeness and quality of developed computer software, process of validating and verifying that a software program/application/product:

1.    meets the business and technical requirements that guided its design and development;

2.    works as expected; and

3.    can be implemented with the same characteristics.

 

 

Software Testing Models / Software Testing Methodologies

 

There are various models which have been presented in the past 20 years in the field of Software Engineering for Development and Testing. Let us discuss and explore into few of the famous models. 

These are some commonly used software testing methodologies:

§  Waterfall Model

§  Spiral Model

§  V Model

§  W Model, and 

§  Butterfly Model

§  RUP

§  Agile model

§  RAD

Waterfall Model

This is one of the first models of software development, presented by B.W.Boehm Winston W. Royce (in 1970). The Waterfall model is a step-by-step method of achieving tasks. Using this model, one can get on to the next phase of development activity only after completing the current phase. Also one can go back only to the immediate previous phase.
In Waterfall Model each phase of the development activity is followed by the Verification and Validation activities. One phase is completed with the testing activities, then the team proceeds to the next phase. At any point of time, we can move only one step to the immediate previous phase. For example, one cannot move from the Testing phase to the Design phase. 

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.

The waterfall model is probably the oldest and the best-known models as far as software development process models are concerned. The role of the waterfall model in software engineering is as important as its role in software testing. Of course, over the years, there are a number of other software process models which have been designed and implemented, but what is true is that a lot of them are based (in some way or the other) on the fundamental principle of the waterfall model.

Waterfall Model in Software Engineering
The waterfall model is so named because it employs a 'top down' approach regardless of whether it is a waterfall model in testing, or a waterfall model in SDLC.

Phases of the Waterfall Model in Software Engineering:

 

 

First and foremost, you need to completely analyze the problem definition and all the various project requirements. This phase is commonly referred to as 'Requirement Analysis'. Once you have thoroughly and exhaustively identified and understood all the project requirements, they are to be properly documented, after which you move onto the next phase, which is known as 'System Design'. This involves specifying and designing the project's hardware and software requirements, and their inter-relation. The entire software aspect of the project is broken down into different logical modules or blocks which are identified and systematically documented. 'System Implementation' is the next phase which involves nothing but writing software code and actually implementing the programming ideas and algorithms which have been designed or decided upon in the 'System Design' phase. Once the coding and implementation phase has been completed, it is now time to test the code. This is precisely what happens in the next phase which is known as 'System Testing'. The code that has been written is subjected to a series of tests and test cases to detect and determine whether there are any bugs, errors or software failures. Once all the repair work, i.e. correcting and re-writing every piece of erroneous or flawed code is completed, you then move to the next and last phase titled 'System Deployment and Maintenance'. As the name suggests, the last phase is nothing but handing over the completed project to the client or customer, and subsequently performing maintenance activities on a periodic basis.

Waterfall Model Advantages and Disadvantages

Pros

• It is the simplest software process model in terms of complexity and ease of implementation
• This model is extremely easy to understand and therefore, is implemented at various project management levels and in a number of fields (not just software development).
• It employs a systematic, orthodox method of project development and delivery.
• 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.

Cons

• Since it is not an iterative model, it has its fair share of shortcomings and drawbacks. Being a strictly sequential model, jumping back and forth between two or more phases is not possible. The next phase can be reached only after the previous one has been completed. Due to this, bugs and errors in the code cannot be discovered until and unless the testing phase is reached. This can lead to a lot of wastage of time and other precious resources.
• 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. This process model is not suitable for projects wherein the project requirements are dynamic or constantly changing.
• 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.
• 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
• 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.
• 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 newer version of the system; this increases the cost of system development.

 

Summary

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

 

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.

The V-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time.

The V-model consists of a number of phases. The Verification Phases are on the right hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the left hand side of the V.

In the V Model SDLC, both the Development activity and the testing activities start almost at the same time with the same information. The development team does design and development and test team does the Test planning, scripting and testing. It’s a parallel process for both development and testing. This model steps are quite similar to waterfall model. This is the one of the most popular model of software test life cycle.

"V" Model is one of the SDLC Methodologies.

In this methodology Development and Testing takes place at the same time with the same kind of information in their hands.

Typical "V" shows Development Phases on the Left hand side and Testing Phases on the Right hand side.

Development Team follow "Do-Procedure" to achieve the goals of the company

And Testing Team follow "check-Procedure" to verify them. 

V-Model indicates that how the testing is carried out.

Order         Phase 1                      Order    Phase 2

1              Requirement Analysis    4         System Integration   
2              Low Level Desgin            3         Unit Testing
3              High Level Design           2         Integration Testing
4              System Integration        1          User Acceptance Testing

V Model mean

 Requirement                                        Integration                     

    Prototype                                  Unit testing   

       Designing                    Integration testing

           Integration       Acceptance testing              

 

Benefits of V-Model

•          Faults are prevented and it stops fault multiplication.

•           Avoids the downward flow of defect.

•           Lower defect Resolution cost due to earlier detection.

•           Improved quality and reliability.

•           Reduction in the amount of Re-work.

•           Improved Risk Management

•           Validation and Verification at each level of stage containment

•           Allows testers to be active in the project early in the project’s lifecycle. They develop critical knowledge about the system.

 7) Diff between v-model, waterfall model, spiral model, Iterative model?

 The spiral model, also known as the spiral lifecycle model, is a systems development lifecycle (SDLC) model used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects. 
The steps in the spiral model can be generalized as follows:

1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.
5. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.
6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
7. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
8. The final system is constructed, based on the refined prototype.

The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

 

Spiral Model

The "Waterfall Model" has 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. The Spiral 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.

The spiral model or "Boehm’s Model" is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.

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.

History of Spiral model:

The spiral model was defined by Barry Boehm in his 1988 article A Spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.

 

The Spiral Model

 

The spiral model, also known as the spiral lifecycle model, is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive, and complicated projects.

 

The steps in the spiral model can be generalized as follows:

 

 

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

 

Applications

For a typical shrink-wrap application, the spiral model might mean that you have a rough-cut of user elements (without the polished / pretty graphics) as an operable application, add features in phases, and, at some point, add the final graphics. The spiral model is used most often in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military has adopted the spiral model for its Future Combat Systems program.

Advantages and Disadvantages

Advantages

1.    Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier.

2.    It is more able to cope with the (nearly inevitable) changes that software development generally entails.

3.    Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier.

Disadvantages

1. Highly customized limiting re-usability
2. Applied differently for each application
3. Risk of not meeting budget or schedule
4. Risk of not meeting budget or schedule

The W-Model

The V-model promotes the idea that the dynamic test stages (on the right hand side of the model) use the documentation identified on the left hand side as baselines for testing. The V-Model further promotes the notion of early test preparation.

Early test preparation finds faults in baselines and is an effective way of detecting faults early. This approach is fine in principle and the early test preparation approach is always effective. However, there are two problems with the V-Model as normally presented.

The V-Model with early test preparation.

Firstly, in our experience, there is rarely a perfect, one-to-one relationship between the documents on the left hand side and the test activities on the right. For example, functional specifications don’t usually provide enough information for a system test. System tests must often take account of some aspects of the business requirements as well as physical design issues for example. System testing usually draws on several sources of requirements information to be thoroughly planned.

Secondly, and more important, the V-Model has little to say about static testing at all. The V-Model treats testing as a “back-door” activity on the right hand side of the model. There is no mention of the potentially greater value and effectiveness of static tests such as reviews, inspections, static code analysis and so on. This is a major omission and the V-Model does not support the broader view of testing as a constantly prominent activity throughout the development lifecycle.

The W-Model of testing.

Paul Herzlich introduced the W-Model approach in 1993. The W-Model attempts to address shortcomings in the V-Model. Rather than focus on specific dynamic test stages, as the V-Model does, the W-Model focuses on the development products themselves. Essentially, every development activity that produces a work product is “shadowed” by a test activity. The purpose of the test activity specifically is to determine whether the objectives of a development activity have been met and the deliverable meets its requirements. In its most generic form, the W-Model presents a standard development lifecycle with every development stage mirrored by a test activity. On the left hand side, typically, the deliverables of a development activity (for example, write requirements) is accompanied by a test activity “test the requirements” and so on. If your organization has a different set of development stages, then the W-Model is easily adjusted to your situation. The important thing is this: the W-Model of testing focuses specifically on the product risks of concern at the point where testing can be most effective.

The W-Model and static test techniques.

If we focus on the static test techniques, you can see that there is a wide range of techniques available for evaluating the products of the left hand side. Inspections, reviews, walkthroughs, static analysis, requirements animation as well as early test case preparation can all be used.

The W-Model and dynamic test techniques.

If we consider the dynamic test techniques you can see that there is also a wide range of techniques available for evaluating executable software and systems. The traditional unit, integration, system and acceptance tests can make use of the functional test design and measurement techniques as well as the non-functional test techniques that are all available for use to address specific test objectives.

The W-Model removes the rather artificial constraint of having the same number of dynamic test stages as development stages. If there are five development stages concerned with the definition, design and construction of code in your project, it might be sensible to have only three stages of dynamic testing only. Component, system and acceptance testing might fit your normal way of working. The test objectives for the whole project would be distributed across three stages, not five. There may be practical reasons for doing this and the decision is based on an evaluation of product risks and how best to address them. The W-Model does not enforce a project “symmetry” that does not (or cannot) exist in reality. The W-model does not impose any rule that later dynamic tests must be based on documents created in specific stages (although earlier documentation products are nearly always used as baselines for dynamic testing). More recently, the Unified Modeling Language (UML) described in Booch, Rumbaugh and Jacobsen’s book [5] and the methodologies based on it, namely the Unified Software Process and the Rational Unified Process™ (described in [6-7]) have emerged in importance. In projects using these methods, requirements and designs might be documented in multiple models so system testing might be based on several of these models (spread over several documents).

We use the W-Model in test strategy as follows. Having identified the specific risks of concern, we specify the products that need to be tested; we then select test techniques (static reviews or dynamic test stages) to be used on those products to address the risks; we then schedule test activities as close as practicable to the development activity that generated the products to be tested.

Software Development Models - W-Model

From the view of testing, all of the models presented previously are deficient in various ways:
• the test activities first start after the implementation
• the connection between the various test stages and the basis for the test is not clear
• the tight link between test, debug and change tasks during the test phase is not clear
In the following, the W-model is presented. This is based on the general V-model and the disadvantages previously mentioned are removed. 

The test process usually receives too little attention in the models presented and usually appears as an unattractive task to be carried out after coding. In order to place testing on an equal footing, a second “V” dedicated to testing is integrated into the model. Both “V”s together give the “W” of the W Model.

 

 

Advantages of the W-Model
In the W-model the importance of the tests and the ordering of the individual activities for testing are clear. Parallel to the development process, in a tighter sense, a further process - the test process - is carried out. This is not first started after the development is complete.
The strict division between constructive tasks on the left-hand side and the more destructive tasks on the right-hand side that exists in the V-model is done away with. In the W-model it is clear that such a division between tasks is not sensible and that a closer co-operation between development and testing activities must exist. From the project outset onwards the testers and the developers are entrusted with tasks and are seen as an equal-rights partnership. During the test phase, the developer is responsible for the removal of defects and the correction of the implementation. The early collaboration and the tight co-operation between the two groups can often in practice avoid conflict meetings.
The W-model becomes closer to practice when the test expenditure is given 40% and more. The model clearly emphasizes the fact that testing is more than just construction, execution and evaluation of test cases.

 

Disadvantages of the W-Model 
Models simplify the real facts. In practice there are more relations between the different parts of a development process. However, there is a need for a simple model if all people involved in a project are to accept it. This is also a reason why the simple V-model so frequently used in practice.
The models of software development presented do not clarify the expenditure needed for resources that need to be assigned to the individual activities. Also in the W-model it appears that the different activities have an equal requirement for resources (time, personnel, etc.) In practice this is certainly not the case. In each project the most important aspects may vary and so therefore the resource allocation is unlikely to be equal across activities. For highly critical applications the test activities certainly have higher weighting or at least equal weighting with other activities.

 

 

 

Software Testing Life Cycle

 

Software testing life cycle identifies what test activities to carry out and when (what is the best time) to accomplish those test activities. Even though testing differs between organizations, there is a testing life cycle.

Software Testing Life Cycle consists of six (generic) phases:

§ Test Planning,

§ Test Analysis,

§ Test Design,

§ Construction and verification,

§ Testing Cycles,

§ Final Testing and Implementation and

§ Post Implementation.

 

Software testing has its own life cycle that intersects with every stage of the SDLC. The basic requirements in software testing life cycle is to control/deal with software testing – Manual, Automated and Performance.

Test Planning

This is the phase where Project Manager has to decide what things need to be tested, do I have the appropriate budget etc. Naturally proper planning at this stage would greatly reduce the risk of low quality software. This planning will be an ongoing process with no end point.

Activities at this stage would include preparation of high level test plan-(according to IEEE test plan template The Software Test Plan (STP) is designed to prescribe the scope, approach, resources, and schedule of all testing activities. The plan must identify the items to be tested, the features to be tested, the types of testing to be performed, the personnel responsible for testing, the resources and schedule required to complete testing, and the risks associated with the plan.). Almost all of the activities done during this stage are included in this software test plan and revolve around a test plan.

Test Analysis

Once test plan is made and decided upon, next step is to delve little more into the project and decide what types of testing should be carried out at different stages of SDLC, do we need or plan to automate, if yes then when the appropriate time to automate is, what type of specific documentation I need for testing.

Proper and regular meetings should be held between testing teams, project managers, development teams, Business Analysts to check the progress of things which will give a fair idea of the movement of the project and ensure the completeness of the test plan created in the planning phase, which will further help in enhancing the right testing strategy created earlier. We will start creating test case formats and test cases itself. In this stage we need to develop Functional validation matrix based on Business Requirements to ensure that all system requirements are covered by one or more test cases, identify which test cases to automate, begin review of documentation, i.e. Functional Design, Business Requirements, Product Specifications, Product Externals etc. We also have to define areas for Stress and Performance testing.

Test Design

Test plans and cases which were developed in the analysis phase are revised. Functional validation matrix is also revised and finalized. In this stage risk assessment criteria is developed. If you have thought of automation then you have to select which test cases to automate and begin writing scripts for them. Test data is prepared. Standards for unit testing and pass / fail criteria are defined here. Schedule for testing is revised (if necessary) & finalized and test environment is prepared.

 

 

 

Construction and verification

In this phase we have to complete all the test plans, test cases, complete the scripting of the automated test cases, Stress and Performance testing plans needs to be completed. We have to support the development team in their unit testing phase. And obviously bug reporting would be done as when the bugs are found. Integration tests are performed and errors (if any) are reported.

Testing Cycles

In this phase we have to complete testing cycles until test cases are executed without errors or a predefined condition is reached. Run test cases --> Report Bugs --> revise test cases (if needed) --> add new test cases (if needed) --> bug fixing --> retesting (test cycle 2, test cycle 3….).

Final Testing and Implementation

In this we have to execute remaining stress and performance test cases, documentation for testing is completed / updated, provide and complete different matrices for testing. Acceptance, load and recovery testing will also be conducted and the application needs to be verified under production conditions.

Post Implementation

In this phase, the testing process is evaluated and lessons learnt from that testing process are documented. Line of attack to prevent similar problems in future projects is identified. Create plans to improve the processes. The recording of new errors and enhancements is an ongoing process.

Cleaning up of test environment is done and test machines are restored to base lines in this stage.

Software Testing Life Cycle
Phase	Activities	Outcome
Planning	Create high level test plan	Test plan, Refined Specification
Analysis	Create detailed test plan, Functional Validation Matrix, test cases	Revised Test Plan, Functional validation matrix, test cases
Design	test cases are revised; select which test cases to automate	revised test cases, test data sets, sets, risk assessment sheet
Construction	scripting of test cases to automate,	test procedures/Scripts, Drivers, test results, Bugreports.
Testing cycles	complete testing cycles	Test results, Bug Reports
Final testing	execute remaining stress and performance tests, complete documentation	Test results and different metrics on test efforts
Post implementation	Evaluate testing processes	Plan for improvement of testing process

 

 

 

 

 

 

 

 

 

 

 

 

 

Explain the STLC?

STLC means it starts from the preparation of test plan, test case and ends with product release. Meanwhile we'l b involved in some other types of testing. Major tasks will b 

done in STLC are as follows,

1. Test Plan Preparation

2. Test Case Preparation

3. Execution of TC

4. Analyze the Result

5. Defect Report Preparation

6. Regression Testing

Diff. between STLC and SDLC?

STLC is software test life cycle it starts with 

1. preparing the test strategy

2. preparing the test plan

3. creating the test environment

4. writing the test cases

5. creating test scripts

6. executing the test scripts

7. analysing the results and reporting the bugs

8. doing regression testing

9. test exiting

SDLC is software or system development life cycle

phases are...

1. project initiation

2. requirement gathering and documenting

3. designing

4. coding and unit testing

5. integration testing

6. system testing

7. installation and acceptance testing

8. support or maintenance

SCM and SQA will follow throughout the cycle

the major diff. b/w sdlc and stlc ,

  in sdlc we can coding but in stlc we can not implement the 

coding phase.

 

 

 

 

 

 

How severe your Bug is

It is extremely important to understand the type & importance of every bug detected during the testing & its subsequent effect on the users of the subject software application being tested.

Such information is helpful to the developers and the management in deciding the urgency or priority of fixing the bug during the product-testing phase. 

Following Severity Levels are assigned during the Testing Phase:

Critical – is the most dangerous level, which does not permit continuance of the testing effort beyond a particular point. Critical situation can arise due to popping up of some error message or crashing of the system leading to forced full closure or semi closure of the application. Criticality of the situation can be judged by the fact that any type of workaround is not feasible. A bug can fall into "Critical" category in case of some menu option being absent or needing special security permissions to gain access to the desired function being tested.

High – is a level of major defect under which the product fails to behave according to the desired expectations or it can lead to malfunctioning of some other functions thereby causing failure to meet the customer requirements. Bugs under this category can be tackled through some sort of workaround. Examples of bugs of this type can be mistake in formulas for calculations or incorrect format of fields in the database causing failure in updating of records. Likewise there can be many instances.

Medium – defects falling under this category of medium or average severity do not have performance effect on the application. But these defects are certainly not acceptable due to non-conformance to the standards or companies vide conventions. Medium level bugs are comparatively easier to tackle since simple workarounds are possible to achieve desired objectives for performance. Examples of bugs of this type can be mismatch between some visible link compared with its corresponding text link.

Low - defects falling under low priority or minor defect category are the ones, which do not have effect on the functionality of the product. Low severity failures generally do not happen during normal usage of the application and have very less effect on the business. Such types of bugs are generally related to looks & feel of the user interface & are mainly cosmetic in nature.

Defect Severity determines the defect's effect on the application where as Defect Priority determines the defect urgency of repair.
Severity is given by Testers and Priority by Developers 

1. High Severity & Low Priority: For example an application which generates some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. If there is a fault while calculating yearly report this is a high severity fault but low priority because this fault can be fixed in the next release as a change request.

2. High Severity & High Priority: In the above example if there is a fault while calculating weekly report. This is a high severity and high priority fault because this fault will block the functionality of the application immediately within a week. It should be fixed urgently.

3. Low Severity & High Priority: If there is a spelling mistake or content issue on the homepage of a website which has daily hits of lakhs. In this case, though this fault is not affecting the website or other functionalities but considering the status and popularity of the website in the competitive market it is a high priority fault.

4. Low Severity & Low Priority: If there is a spelling mistake on the pages which has very less hits throughout the month on any website. This fault can be considered as low severity and low priority.

Examples:

High severity and low priority

When the application has critical problem and it has to be solved after a month then we can say itas high severity and low priority

Wrong order of functionalities

Affecting end user

Home Page in web application has misspelled client name and found at the time of delivering the product.

If there is an application if that application crashes after multiple use of any functionality (ex--save Button use 200 times then that application will crash)

All Functional errors come under this question

if u are able to launch an application 100 time but after that application gets crashed or any other defects arise like 'Data Lose data crash etc..' the Severity will be high always as it affects the application functionality and priority will be decided low because till 100 time application is working perfectly.

Low severity and high priority

When the application has trivial problem ie (less affected) and it has to be solved within a day then we can say it as low severity and high priority

Spelling mistakes

Crash in some any module that is too be delivered later.

If any Web site say Yahoo now if the logo of site Yahoo spells Yho ----Then Priority is high but severity is low. Because it affect the name of site so important to do quick ---Priority but it is not going to crash because of spell change so severity low.

All GUI related errors come under this question For eg.. Logo of any company

Severity:-It can be defined as impact of defect on the application that means how bad the defect is. it can be 'Minor' Major' and 'Critical'

Priority :- It can be defined as how long it will take to fix this issue. ‘Low', 'Medium' and 'High'.

Examples:-

Low Severity and High Priority:- Suppose you are testing web site of any reputed company which is going to be hosted soon and the company name itself is wrong in the application then this is cosmetic defect but its severity is low becoz its not gonna affect the application but priority is high means developer has to fix this defect as soon as possible.

High Severity and Low Priority :- Suppose you are testing a application where you find that a piece of the functionality is not working properly but its afftecting the application functionality but it can be skipped at the moment and can be resoved before the relaese so this defect comes under High Severity and Low Prioirity.

High Severity Low Priority Example: 
For an Insurance application the descripion of an accident is too short thereby causing truncation errors when printed on report. This report is not referenced for claims under $20 000.00.

High Severity because you need to describe completely on report the accident. Since it is stored correctly in the database the report can be corrected later not ASAP.

Low Priority - since it is not a show stopper. If anybody wants to look at the description of accident it can still be retrieved because the data is corectly stored in the database. It can be fixed later.

Example: A screen functionality displaying a field called "6-Month Percentage ( ) Loss" showing values of 12500 which should be 12.500 . This is a 6-month analysis figure

High priority since you need to display the accurate percentage.
Low Severity - it is a report displayed after every six months.

High priority and high severity: The application crashes whenever a person attempts to submit valid input on the registration page.

High priority and low severity: The content entered in the Terms of Use are not correct and could potentially have legal consequences.

High severity and low priority: The application crashes whenever a person enters 1500+ chars in a phone number text box that should accept no more than 15 chars.

Low severity and low priority: There is a slight misspelling on one of the FAQ pages.

Severity: Describes the bug in terms of functionality.
Priority: Describes the bug in terms of customer.

few examples:

High Severity and Low Priority -> Application doesn't allow customer expected configuration.
High Severity and High Priority -> Application doesn't allow multiple user's.

Low Severity and High Priority -> No error message to prevent wrong operation. 
Low Severity and low Priority -> Error message is having complex meaning.

Example of Severity and Priority

---

1. High Severity -Low priority
   Supposing, you try the wildest or the weirdest of operations in a software (say, to be released the next day) which a normal user would not do and supposing this renders a run -time error in the application,
   the severity would be high.The priority would be low as the operations or the steps which rendered this error by most chances will not be done by a user.
2. Low Severity -High priority
   An example would be- you find a spelling mistake in the name of the website which you are testing.
   Say, the name is supposed to be Google and its spelled there as 'Gaogle'.Though, it doesnt affect the basic functionality of the software, it needs to be corrected before the release.
   Hence, the priority is high.
3. High severity--- High Priority
   A bug which is a show stopper.i.e, a bug due to which we are unable to proceed our testing.
   An example would be a run time error during the normal operation of the software,
   which would cause the application to quit abruptly.
4. Low severity --- low priority
   Cosmetic bugs

Priority :- How quickly we need to fix the bug? Or How soon the bug should get fixed?

Severity : - How much the bug is effecting the functionality of the application?

Eg:- 
(1) High Priority and Low Severity
If a company logo is not properly displayed on their website.
(2) High Priority and High Severity
Suppose you are doing online shopping and filled payment informations, but after submitting the form, you get a message like "Order has been cancelled."
(3) Low Priority and High Severity
If we have a typical scenario in which the application get crashed, but that scenario exists rarely.
(4) Low Priority and Low Severity
There is a mistake like "You have registered success" instead of successfully, success is written.

Severity is a measure of how bad (impact).

Priority is a measure of when (time).

Example:

High severity: Affecting end user

Low priority: Typos