It contains 6 phases.
2. TEST DEVELOPMENT.
3. TEST EXECUTION.
4. RESULT ANALYSIS.
5. BUG TRACKING.
6. REPORTING.
1) TEST PLANNING
Plan:
Plan is a strategic document, which describes how to perform a task in an effective, efficient and optimized way.
Optimization:
Optimization is a process of reducing or utilizing the input resources to their maximum and getting the maximum possible output.
Test Plan:
It is a strategic document, which describe how to perform testing on an application in an effective, efficient and optimized way. The Test Lead prepares test plan.
1.0 INTRODUCTION.
1.1 Objective.
1.2 Reference Document.
2.0 COVERAGE OF TESTING.
2.1 Features to be Tested.
2.2 Features not to be Tested.
3.0 TEST STRATEGY.
3.1 Levels of Testing.
3.2 Types of Testing.
3.3 Test Design Technique.
3.4 Configuration Management.
3.5 Test Metrics.
3.6 Terminology.
3.7 Automation Plan.
3.8 List of Automated Tools.
4.0 BASE CRITERIA..
4.1 Acceptance Criteria.
4.2 Suspension Criteria.
5.0 TEST DELIVARABLES.
6.0 TEST ENVERONMENT.
7.0 RESOURCE PLANNING.
8.0 SHEDULING.
9.0 STAFFING AND TRAINING.
10.0 RISKS AND CONTINGENCES.
11.0 ASSUMPTIONS.
12.0 APPROVAL INFORMATION.
1.0 INTRODUCTION.
1.1 Objective.
The main purpose of the document is clearly described here in this section.
1.2 Reference Document.
The list of all the documents that are referred to prepare the test plan will be listed out here in this section.
2.0 COVERAGE OF TESTING.
2.1 Features To Be Tested
The list of all the features with in the scope are mentioned here in this section
2.2 Features Not To Be Tested
The lists of all the features that are not planed for testing based on the following criteria are mentioned here in this section.
Ø Out of scope features
Ø Low risk areas
Ø Future functionalities.
Ø The features that are skipped based on the time constraints.
3.0 TEST STRATEGY
It is defined as an organization level term, which is used for testing all the projects in the organization.
TEST PLAN
It is defined as a project level term, which is describes how to test a particular project in an organization.
Note:
Test strategy is common for all the projects. But test plan various from project to project.
3.1 Levels of Testing
The list of all the levels of testing that are maintained in that company are listed out here in this section.
3.2 Types of Testing
The list of all the types of testing that are followed by that company are listed out here in this section.
3.3 Test Design Technique
The list of all the techniques that are followed by that company during the test case development are listed out here in this section.
Ex: BVA (Boundary Value Analysis)
ECP (Equable Class Partition)
3.4 Configuration Management
3.5 Test Metrics
The lists of all the tasks that are measured and maintain in terms of metrics are clearly mentioned here in this section.
3.6 Terminologies
The list of all the terms and the corresponding meanings are listed out here in this section
3.7 Automation plan
The list of all the areas that are planed for automation in that company are listed out her in this section.
3.8 List of Automated Tools
The list of all the automated tools that are used in that company are listed out here in this section.
4.0 BASE CRITERIA
4.1 Acceptance Criteria.
When to stop testing in a full pledged manner thinking then enough testing is done on the application is clearly described here in this section.
4.2 Suspension Criteria.
When to stop testing suddenly and suspended the build will be clearly mentioned here in this section.
5.0 TEST DELIVERABLE.
The list of all the documents that are to be prepared and deliver in the testing phase are listed out here in this section.
6.0 TEST ENVIRONMENT.
The customer specified environment that is about to be used for testing is clearly describes here in this section.
7.0 RESOURCE PLANNING.
Who has to do what is clearly described here in this section.
8.0 SCHEDULING.
The starting dates and the ending dates of each and ever task is clearly described here in this section.
9.0 STAFFING AND TRAINING.
How much staff is to be requited what kind of training is to be provided is clearly planned and mentioned here in this section.
10.0 RISK AND CONTINGENCES.
The list of all the potential risks corresponding solution plans are listed out here in this section.
Risks
1. Unable to deliver the software with in the dead lines.
2. Employees may leave the organization in the middle of the project development.
3. Customer may impose the dead lines.
4. Unable to test all the features with in the time.
5. Lake of expatriation.
Contingences
1. Proper plan ensurence.
2. People need to be maintained on bench.
3. What not to be tested has to be planed properly.
4. Severity priority based execution.
5. Proper training needs to be provided.
11.0 ASSUMPTIONS.
The list of all the assumptions that are to be assumed by a test engineer will be listed out here in this section.
12.0 APPRUVAL INFORMATION.
Who will approve what is clearly mentioned here in this section.
2. TEST DEVELOPMENT.
Types of Test Cases
Test cases are broadly divided into two types.
1. G.U.I Test Cases.
2. Functional test cases.
Functional test cases are further divided into two types.
1. Positive Test Cases.
2. Negative Test Cases.
Guidelines to prepare GUI Test Cases:
1. Check for the availability of all the objects.
2. Check for the alignments of the objects if at all customer has specified the requirements.
3. Check for the consistence of the all the objects.
4. Check for the Spelling and Grammar.
Apart from these guidelines anything we test with out performing any action will fall under GUI test cases.
Guidelines for developing Positive Test Cases.
1. A test engineer must have positive mind setup.
2. A test engineer should consider the positive flow of the application.
3. A test engineer should use the valid input from the point of functionality.
Guidelines for developing the Negative Test Cases:
1. A test engineer must have negative mind setup.
2. He should consider the negative flow of the application.
3. He should use at least one invalid input for a set of data.
Test Case Template:
1. Test Objective :
2. Test Scenario :
3. Test Procedure :
4. Test Data :
5. Test Cases :
1.Test Objective:
The purpose of the document is clearly described here in this section.
2.Test Scenarios:
The list of all the situations that are to be tested, that are listed out here in this section.
3.Test Procedure:
Test procedure is a functional level term, which describe how to test the functionality. So in this section one will describe the plan for testing the functionality.
4.Test Data:
The data that is required for testing is made available here in this section.
5.Test Cases:
The list of all the detailed test cases is- listed out here in this section.
Note:
Some companies even maintain all the above five fields individually for each and every scenario. But some companies maintain commonly for all the scenarios.
3. TEST EXECUTION.
During the test execution phase the test engineer will do the following.
1. He will perform the action that is described in the description column.
2. He will observe the actual behavior of the application.
3. He will document the observed value under the actual value column.
4. RESULT ANALYSIS.
In this phase the test engineer will compare the expected value with actual value and mention the result as pass if both are match other wise mentioned the result as fail.
5. BUG TRACKING.
Bug tracking is a process in which the defects are identifying, isolated and managed.
Defect Profile Document
Defect ID:
The sequences of defect numbers are listed out here in this section.
Steps of Reproducibility:
The list of all the steps that are followed by a test engineer to identity the defect are listed out here in this section.
Submitter:
The test engineer name who submits the defect will be mentioned here in this section.
Date of Submission:
The date on which the defects submitted is mentioned here in this section.
Version Number:
The corresponding version number is mentioned here in this section.
Build Number:
Corresponding build number is mentioned here is this section.
Assigned to:
The project lead or development lead will mentioned the corresponding developers name for name the defect is assigned.
Severity:
How serious the defect is, is described in terms of severity. It is classified in to 4 types.
1. FATAL Sev1 S1 1
2. MAJOR Sev2 S2 2
3. MINOR Sev3 S3 3
4. SUGGESION Sev4 S4 4
FATAL:
It is all the problems are related to navigational blocks or unavailability of functionality then such types of problems are treated to be FATAL defect.
Note: It is also called as show stopper defects.
MAJOR:
It at all the problems are related to the working of the features then such types of problems are treated to be MAJOR defects.
MINOR:
It at all the problems are related to the look and feel of the application then such types of problems are treated to be MINOR defects.
SUGGITIONS:
If at all the problems are related to the value of the application then such types of problems are treated to be suggestions.
Priority:
The sequence in which the defects have to be rectified is described in terms of priority. It is classified in to 4 types.
1. CRITICAL
2. HIGH
3. MEDIUM
4. LOW
Usually the FATAL defects are given CRITICAL priority, MAJOR defects are given HIGH priority, MINOR defects are given MEDIUM priority and SUGGITION defects are given LOW priority sent depending upon the situation the priority may be changed by the project lead or development lead.
Ex: -
Low Severity High Priority Case:
In the case of customer visit all the look and feel defects, which are usually less savior, are given highest priority.
High Severity Low Priority Case:
If at all some part of the application is not available because it is under development still the test engineer will treat team as FATAL defect, but the development lead will give less priority for those defects.
No comments:
Post a Comment