TESTING LIFE CYCLE

Testing life cycle:
Testing lifecycle contains six phases
Test planning
Test development
Test execution
Result analysis
Bug tracking
Reporting
Test planning: Test planning is a document which describes how to perform testing on an application in an effective, efficient and optimized way. Test planning contains test objective, coverage of testing, test strategy, Base criteria, test scope, test deliverables, test environment, test bed, resource planning, scheduling, staffing& training, risks &contingency plan, assumptions and approval information.
Test objective: the purpose of the test plan document is clearly described in this section.
Reference documents: the list of documents that are Referred to prepare the
Test plan are listed out in this section.
Coverage of testing:
Features to be tested: The lists of all the features that are within the scope are listed in this section.
Features not tested: features that are not planned for tested based on the following criteria are listed in this section.
(1) Features out of scope
(2) Future functionalities
(3) Low risk areas
(4) The features that are skipped based on the time constraint.
Test strategy: test strategy is an organizational level term which is used for testing all the projects for an organization. For all projects the test strategy is same. Test strategy is considered for all projects. Where test plan is different for different projects.
Test strategy consists of
Levels of testing
Types of testing
Test design techniques
Configuration management
Test metrics
Terminology
Automation plan
List of automated tools
Levels of testing: The lists of all the levels of testing that are used in the organization are listed in the section. Mainly they perform unitlevel, module level, integration, system level and acceptance testing.
Types of testing: the list of all the types of testing that are followed by that company will be listed out in this section.
Test design techniques: the list of all the techniques that are used for perform testing in an effective, efficient and optimized way with the same result.
Software configuration management (SCM): software configuration management is a process in which mainly they control, coordinate, and track code, requirements, documents, problems, change requests, designs, and tools.
Test metrics: the list of all the tasks that are planned to maintain metrics in that organization are listed out here in this section. quality metrics, process improve metrics, productivity metrics etc are the different types of metrics.
Terminology: The lists of all the terms that are used in that organization along with their meaning are clearly mentioned here in this section.
Automation plan: the list of all the areas that are planned for automation are listed here in this section.
List of automated tools: the list of all the automated tools that are used in that company are listed out here in this section
Test bed: test bed is the execution environment configured for software testing, consisting of specific hardware, n/w 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 deliverables: The list of all the documents that are delivering in a testing department are list out here in this section. Test case, defect fault, test plan, status report, review report, test summary report etc are the test deliverables in the testing phase. This does not represent a definite set of test deliverables but it will help any test organization begin the process of determining an appropriate set of deliverables. Test deliverables goal is to capture the require content in a useful an consistent framework as concisely as possible
Test environment: the customer specified environment is called test environment.
Test case: A test is a document that describes the input, action or event and expected output to determine if the application is working fine (or) not.
It is used for finding the problems in requirements or design, because it completely thinking of operation of an application
Base criteria
Acceptance criteria: when to stop testing in a full fledged model is clearly described here in this section
Suspension criteria: when to suspend testing in clearly described in this section
Resource planning: A resource planning describes what the resources in company are whether h/w, s/w and human resources is sufficient for this project and who has to do what is clearly described in this section.
Scheduling: the start date and end dates are clearly described in this section.
Staffing and training: how much staff is to be recruited and what kind of training is to be provided for them and existing employees is clearly planned in this section.
Risks and contingency plans: the list of all the potential risks and the corresponding solutions are listed out here in this section.

Risks in an organization:
(1) Delaying in delivery of software
(2)Employees may leave the organization
(3)Lack of expatiation
(4)Customer imposed dead lines
(5)Unable to test all the features with in the time.
Contingencies:
(1)Proper plan assurance
(2)Employees should be maintained on bench
(3)Training should be provided
(4)What to be not tested should plan in case of customer imposed dead lines. Perform adhoc testing.
(5)Based of severity and priority the testing should be done.
Assumptions: the list of all the assumptions that are to be assured by a test engineer will be clearly mentioned here in this section.
Approval information: who has to approve what is clearly described here in this section.
.
Test development phase:
Test execution: In this phase the test engineer will do the following
He will perform the action that is described in the described column.
He will observe the actual behavior of the application
He will document the observed value under the actual column of test case document.
Result analysis: In this phase a test engineer will compare the actual value with the expected value with the if both are matched then he will document the result as pass otherwise he will document the result as fail.
Bug tracking: bug tracking is a process of identified, isolated the bug.
Defect profile template: defect profile contains defect id defect description, steps for reproducibility, submitter, date of submission, build number, version number, assigned number, severity, priority, status.
Defect id: the sequence of defect numbers are mentioned here in this section.
Steps for reproducibility: the steps that are followed by test engineer to identify the defect will be listed here in this section.
Submitter: the test engineer alias name who has submitted the defect is specified here in this section.
Date of submission: the date on which the defect is submitted is mentioned here in this section.
Severity: severity describes the seriousness of the defect. In other words how serious the defect is described in terms of severity.
Severity: is classified into four types.
Fatal ------------sev1---s1
Major --- -------sev2---s2
Minor --- -------sev3---s3
Suggestion -----sev4---s4
Fatal: If at all the problems are related to the navigational blocks or unavailability of functionality, then such type of defects is treated as fatal defects.
Major: If at all the problems are related to the functionality of application then such types of defects are treated to be major defects.
Minor: If at all the problems are related to the perception or look and feel of the application then such type of defects to be treated as minor defects.
Suggestion: If at all the problems are related to the value of the application then such types of defects are treated to be suggestions.
Priority: priority defines which bug to be fixed first.
Priority is classified into 4 types
Show topper
High S
Medium
Low
Usually fatal defects are given showtopper; major defects are given high priority, minor defects low priority and suggestions for no priority.
But in some situations highest severity defects to least priority and lowest priority may be given high priority.
Low severity and highest priority:
When ever there is a customer visits all the looks and feel, defects are given highest priority.
Highest severity and low priority: whenever some functionalities are available and it is known issue as that part of the module is been under construction even though it is a fatal issue one will give lowest priority for it.
Tester comments: If tester as any comments on the bug then he will write his comments in that field.
Developer comments: if developer want to write any comments on the bug the he will write his comments in that field.