what is Retesting and Regression Testing

Regression testing

Throughout all testing cycles, regression test cases are run. Regression testing is

selective retesting of a system or component to verify that modifications have not caused

unintended effects and that the system or component still complies with its specified

requirements.

Regression tests are a subset of the original set of test cases. These

test cases are re-run often, after any significant changes (bug fixes or enhancements) are

made to the code. The purpose of running the regression test case is to make a “spot

check” to examine whether the new code works properly and has not damaged any

previously-working functionality by propagating unintended side effects.

Retesting

Retesting is testing of system or component to verify that modifications of the system or component still complies with its specified requirements.

Re-testing is performed after any modification to verify if the new code is working correctly. In re-testing tester re-execute the testcases on same application build with diferent inputs or testdata.

What are Exit Criteria?

The testing strategy or high-level test plan document is quite often used as the exit criteria. The exit criteria would also include other details such as how well that tests needs to have been done. For example it may state that you need to have tested everything and have found no serious errors but minor errors are acceptable.

Testing is an iterative process and as it is impossible to test everything we could just keep going round the loop indefinitely.

If the exit criteria has been stated in advance then testing can stop when the exit criteria has been met. In other words we can thus say that the exit criteria are the criteria to be met in other to stop testing.

The exit criteria will therefore depend on the following: -

· The risk to the business process of the project.

· The time constraints within the project.

· The resource constraints within the project.

· The budget of the project.

What is root cause analysis?

Root cause analysis (RCA) is a class of problem solving methods aimed at identifying the root causes of problems or events. The practice of RCA is predicated on the belief that problems are best solved by attempting to correct or eliminate root causes, as opposed to merely addressing the immediately obvious symptoms. By directing corrective measures at root causes, it is hoped that the likelihood of problem recurrence will be minimized. However, it is recognized that complete prevention of recurrence by a single intervention is not always possible. Thus, RCA is often considered to be an iterative process, and is frequently viewed as a tool of continuous improvement.

V-Model

The V-model was developed to address some of the problems experienced using the traditional waterfall approach. Defects were being found too late in the life cycle, as testing was not involved until the end of the project. Testing also added lead time due to its late involvement. The V-model provides guidance that testing needs to begin as early as possible in the life cycle, which, as we've seen in Chapter 1, is one of the fundamental principles of structured testing. It also shows that testing is not only an execution based activity. There are a variety of activities that need to be performed before the end of the coding phase. These activities should be carried out in parallel with development activities, and testers need to work with developers and business analysts so they can perform these activities and tasks and produce a set of test deliverables. The work products produced by the developers and business analysts during development are the basis of testing in one or more levels. By starting test design early, defects are often found in the test basis documents. A good practice is to have testers involved even earlier, during the review of the (draft) test basis documents.

The V-model is a model that illustrates how testing activities (verification and validation) can be integrated into each phase of the life cycle. Within the V-model, validation testing takes place especially during the early stages, e.g. reviewing the user requirements, and late in the life cycle, e.g. during user acceptance testing. Although variants of the V-model exist, a common type of V-model uses four test levels.

The four test levels used, each with their own objectives, are:
• Component testing: searches for defects in and verifies the functioning of software components (e.g. modules, programs, objects, classes etc.) that are separately testable;
• Integration testing: A test interfaces between components, interactions to different parts of a system such as an operating system, file system and hard ware or interfaces between systems;
• System testing: concerned with the behavior of the whole system/product as defined by the scope of a development project or product. The main focus of system testing is verification against specified requirements;
• Acceptance testing: validation testing with respect to user needs, requirements, and business processes conducted to determine whether or not to accept the system.

In practice, a V-model may have more, fewer or different levels of development and testing, depending on the project and the software product. For example, there may be component integration testing after component testing and system integration testing after system testing. Test levels can be combined or reorganized depending on the nature of the project or the system architecture. For the integration of a commercial off-the-shelf
(COTS) software product into a system, a purchaser may perform only integration testing at the system level (e.g. integration to the infrastructure and other systems) and at a later stage acceptance testing.



Note that the types of work products mentioned in Figure 2.2 on the left side of the V-model are just an illustration. In practice they come under many different names. References for generic work products include the Capability Maturity Model Integration (CMMi) or the 'Software life cycle processes' from ISO/IEC 12207. The CMMi is a framework for process improvement for both system engineering and software engineering. It provides guidance on where to focus and how, in order to increase the level of process maturity

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

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

The model consists of six distinct stages:

1. In the requirements analysis phase

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

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

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

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

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

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

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

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

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

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

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

Advantages

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

Disadvantages

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

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

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

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

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

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

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

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

What is Verification and validation?

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

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

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

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

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