Testing is intended of finding the defects & to deliver the quality product.

QA is involved in the project from the beginning. This helps the teams communicate and understand the problems and concerns, also gives time to set up the testing environment and configuration. On the other hand, actual testing starts after the test plans are written, reviewed and approved based on the design documentation.

Quality software is reasonably bug free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable.

Test Plan:Test Plan is a document with information on Scope of the project, Approach, Schedule of testing activities, Resources or Manpower required, Risk Issues, Features to be tested and Features not to be tested, Test Tools and Environment Requirements.

Test Strategy:Test Strategy is a document prepared by the Quality Assurance Department with the details of testing approach to reach the Quality standards.

Test Scenario:Test Scenario is prepared based on the test cases and test scripts with the sequence of execution.

Test Case:Test case is a detailed document with the sequence of steps to test the behavior of feature/functionality/non-functionality of the application.

Test Case document consists of Test case ID, Test Case Name, Conditions (Pre and Post Conditions) or Actions, Environment, Expected Results, Actual Results, Pass/Fail.

The Test cases can be broadly classified as User Interface Test cases, Positive Test cases and Negative Test cases.

Test Script:Test Script is a program written to test the functionality of the application. It is a set of system readable instructions to automate the testing with the advantage of doing repeatable and regression testing easily.

Test Environment:It is the Hardware and Software Environment where is the testing is going to be done.

Test Procedure:Test Procedure is a document with the detailed instruction for step by step execution of one or more test cases. Test procedure is used in Test Scenario and Test Scripts.

Test Log:Test Log contains the details of test case execution and the output information.

Test Incident Report – Test Incident Report has information about the failed test comparing the actual result with expected result.

Test Summary Report – Test Summary Report has information about the testing done and quality of the software, it also analyses whether the software has met the requirements given by customer.

Traceability Matrix is a document used for tracking the requirement, Test cases and the defect. This document is prepared to make the clients satisfy that the coverage done is complete as end to end, This document consists of Requirement/Base line doc Ref No., Test case/Condition, Defects/Bug id. Using this document the person can track the Requirement based on the Defect id.

Walkthrough is quick and informal meeting for evaluation purposes

The purpose of inspection is trying to find defects and problems mostly in documents such as test plans, specifications, test cases, coding etc. It helps to find the problems and report it but not to fix it. It is one of the most cost effective methods of software quality. Many people can join the inspections but normally one moderator, one reader and one note taker are mandatory.

Test Bed is an execution environment configured for software testing. It consists of specific hardware, network topology, Operating System, configuration of the product to be under test, system software and other applications. The Test Plan for a project should be developed from the test beds to be used.

Test Data is that run through a computer program to test the software. Test data can be used to test the compliance with effective controls in the software.

Negative Testing - Testing the system using negative data is called negative testing, e.g. testing the password where it should be minimum of 8 characters so testing it using 6 characters is negative testing

The Entry Criteria is the process that must be present when a system begins, like,
SRS – Software
FRS
Use case
Test Case
Test Plan & Stable build

The Exit Criteria ensures whether testing is completed and the application is ready for release, like,
Test Summary Report
Traceability Metrics
Defect Analysis Report.

Test Harness is configuring a set of tools and test data to test an application in various conditions, which involves monitoring the output with expected output for correctness.

The benefits of Test Harness are,
1. Productivity increase due to process automation
2. Quality in the application.

SDLC

• Requirement phase
• Designing phase (HLD, DLD (Program spec))
• Coding
• Testing
• Release
• Maintenance

STLC

• System Study
• Test planning
• Writing Test case or scripts
• Review the test case
• Executing test case
• Bug tracking
• Report the defect

Poor requirements, unrealistic schedule, inadequate testing, miscommunication and additional requirement changes after development begin

Agile Testing is a testing practice done from the customer perspective, it doesn’t follow test procedures and the delivery would happen as early as possible. Agile testing is useful whenever the customer requirements are changing frequently.

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.

As the name implies, the spiral model follows an approach in which there are a number of cycles (or spirals) of all the sequential steps of the waterfall model. Once the initial cycle is completed, a thorough analysis and review of the achieved product or output is performed. If it is not as per the specified requirements or expected standards, a second cycle follows, and so on. This methodology follows an iterative approach and is generally suited for very large projects having complex and constantly changing requirements.

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:
Requirement analysis
Test case design
Test case implementation
Testing, debugging and validating the code or product
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.