STLC Process is one of the guideline for testing the particular application.
The STLC is including in the system testing process. In the system testing the test engineers have to test the developed software by following this STLC phases Test Initiation
6.1. Test Initiation Phase:
In this phase the project manager category people will be involved. They will receive the reviewed BRS & SRS documents & prepares a testing document.
a. Test Strategy Document:
This is a company level document which is prepared by the project manager category people, this document defines the testing approach.
The first stage is the formulation of a test strategy. A test strategy is a statement of the overall approach to testing, identifying what levels of testing are to be applied and the methods, techniques and tools to be used. A test strategy should ideally be organization wide, being applicable to all of an organizations software developments.
Developing a test strategy which efficiently meets the needs of an organization is critical to the success of software development within the organization. The application of a test strategy to a software development project should be detailed in the projects software quality plan.
IEEE for Test Strategy Document:
i. Scope And Objective:
Scope means the purpose or need for testing the developed project (i.e). What is the need of testing? (Or) why we require testing for developed project.
The process or need of testing in this project is to validate the developed software with respect to customer specification. (i.e.) to make the developed software to meet the customer expectations.
The objective of testing in this project is to find the defects as many as possible while testing the developed software.
ii. Budget (or) Business issues:
This component defines how much amount of the budget is allocated for testing in this project.
iii. Roles and responsibilities:
The names of jobs of test engineer in a testing team and their responsibilities. The name of the jobs is the various levels of test engineer in a testing team such as senior test engineer & junior test engineer.
iv. Communication & status reports:
Communication defines the way of communication between roles in a testing team & the way of communication of testing team with others who worked in this project.
Status reporting means reporting the daily statuses to the test lead by the test engineers.
v. Test Automation & Tools:
It defines the need of automation testing in this project and if automation testing is required then whether that particular automation tool is available in our organization or not for this project.
vi. Change & Configuration Management:
Change means changes or modifications done to the test deliverables.
Configuration management means maintaining all the test deliverables , modifications done to test deliverable have to be maintained in the database of organization for future reference.
Change & Configuration management means the project manager gives the information regarding the changes in the test deliverables & Maintaining these test deliverables for future reference.
vii. Risk & Assumptions:
The list of analyzed risks & solutions to overcome these risks by the testing team while testing the developed software in future. The risks & solutions for the risks are prepared by the project manager by analyzing the risks.
viii. Training plan:
The required no of training sessions that the testing team requires to understand the requirements developed in the project properly and perfectly. s
6.2. Test Plan Phase:
A test plan states what the item 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.
Test Plan Document will be divided into
Ø Master Test Plan.
Ø Detailed Test Plan.
6.2.1. Master Test Plan:
Master Test Plan is the high level view of the testing approach,
a. Testing Team Formation:
Test Manager concentrates on below factor to form Testing Team for corresponding project.
Test Manager will check for Availability of test engineers (Selection will be made in 3:1 ratio)
b. Identifying Tactical Risks:
During Test Plan writing author concentrate on identifying risks w.r.t team formation
Lack of knowledge of Testers in the domain.
Lack of Budget.
Lack of Resources.
Delays in Delivery.
Lack of Test Data.
Lack of Development Process Rigor.
Lack of communication (In between testing team and development team)
After completion of Team Formation and Risk Finding, Author(Test manager or Test Lead) start writing Test Plan document
Here are the steps of writing the test plan.
6.2.2. Detailed test plan:
This is a summary of the ANSI/IEEE Standard 829-1983. It describes a test plan as:
“A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency
Planning.”
… (ANSI/IEEE Standard 829-1983)
This standard specifies the following test plan outline:
a. Test Plan Identifier:
· A unique identifier
b. Introduction:
· Summary of the items and features to be tested
· Need for and history of each item (optional)
· References to related documents such as project authorization, project plan, QA plan, configuration management plan, relevant policies, relevant standards
· References to lower level test plans
c. Test Items:
Test items and their version
Characteristics of their transmittal media
References to related documents such as requirements specification, design specification, users guide, operations guide, installation guide
References to bug reports related to test items
Items which are specifically not going to be tested (optional)
d. Features to be tested:
All software features and combinations of features to be tested
References to test-design specifications associated with each feature and combination of features
e. Features Not to Be Tested:
All features and significant combinations of features which will not be tested
The reasons these features won’t be tested
f. Approach:
Overall approach to testing
For each major group of features of combinations of featres, specify the approach
Specify major activities, techniques, and tools which are to be used to test the groups
Specify a minimum degree of comprehensiveness required
Identify which techniques will be used to judge comprehensiveness
Specify any additional completion criteria
Specify techniques which are to be used to trace requirements
Identify significant constraints on testing, such as test-item availability, testing resource availability, and deadline
g. Item Pass/Fail Criteria:
Specify the criteria to be used to determine whether each test item has passed or failed testing
h. Test Deliverables:
Identify the deliverable documents: test plan, test design specifications, test case specifications, test procedure specifications, test item transmittal reports, test logs, test incident reports, test summary reports
Identify test input and output data
Identify test tools (optional)
i. Testing Tasks:
Identify tasks necessary to prepare for and perform testing
Identify all task interdependencies
Identify any special skills required
j. Environmental Needs:
Specify the level of security required
Identify special test tools needed
Specify necessary and desired properties of the test environment: physical characteristics of the facilities including hardware, communications and system software, the mode of usage (i.e., stand-alone), and any other software or supplies needed
Identify any other testing needs
Identify the source for all needs which are not currently available
k. Responsibilities:
Identify groups responsible for managing, designing, preparing, executing, witnessing, checking and resolving
Identify groups responsible for providing the test items identified in the Test Items section
Identify groups responsible for providing the environmental needs identified in the Environmental Needs section
l. Staffing and Training Needs:
Specify staffing needs by skill level
Identify training options for providing necessary skills
m. Schedule:
Specify test milestones
Specify all item transmittal events
Estimate time required to do each testing task
Schedule all testing tasks and test milestones
For each testing resource, specify its periods of use
n. Risks and Contingencies:
Identify the high-risk assumptions of the test plan
Specify contingency plans for each
o. Approvals:
Specify the names and titles of all persons who must approve the plan
Provide space for signatures and dates
6.3. Test Design Phase:
6.3.1. Test Scenario Document:
A set of test cases that ensure that the business process flows are tested from end to end. They may be independent tests or a series of tests that follow each other, each dependent on the output of the previous one.
Test scenario templates:
- S.no
- Module
- Requirements
- Test Scenario.
- Test Case.
6.3.2. Test Case Document:
It is a group of steps that is to be executed to check the functionality of a specific object.
The main objective of writing test case is to validate the test coverage of an application.
Test case Templates:
- Test Case id.
- Test Case Description.
- Step name.
- Step Description.
- Test data (or) Test Input.
- Expected Result.
- Actual Result.
- Status.
6.4. Execute Test Case Phase:
Executing all the test cases based on the functional specification.
6.5. Test Report Phase:
6.5.1. Defect Report Document:
The document that contains the information regarding accepted defects & rejected defects, defect corrected, status of the defect.
IEEE format for defect report document:
a. Defect id (or) name:
A unique number or name must be given to he defect by the test engineer for future reference.
b. Defect description (or) introduction:
A brief summary or a brief description of the identified defects.
c. Severity:
It means the seriousness of the defect in terms of functionality.
i. High severity:
The software build is not working correctly due to occurrence of defect and not to able continue remaining testing until that defect is resolved.
Eg: login.
ii. Medium severity:
The software build is not working correctly due to occurrence of defect but able to continue remaining testing and that defect must be resolved completely.
iii. Low severity:
The build is having a defect but it may or may not be resolved.
Eg: unwanted options available in the application.
d. Priority:
The importance of the defect to be resolved in terms of severity.
(Or)
It is nothing but how fast to fix the bug in terms of severity.
e. Reprodusable:
It means during execution the defect can be reproduced again and again or not.
Two options are available to mention this
Yes: the defect can be reproduced again. Attach the test procedure in this component & send it to defect tracking team.
No: the defect cannot be reproduced again. Attach the test procedure & snapshot and forward to development team.
f. Status: the status will be new
g. Tested by: Testers name should be mentioned.
h. Fixed by: Developers name should be mentioned.
i. Reported on:
The date in which the defect report was reported.
6.5.2. Tools Used:
Tools that are used to track and report defects are,
a. Clear Quest (CQ)
It belongs to the Rational Test Suite and it is an effective tool in Defect
Management. CQ functions on a native access database and it maintains a common database of defects. With CQ the entire Defect Process can be customized. For e.g., a process can be designed in such a manner that a defect once raised needs to be definitely authorized and then fixed for it to attain the status of retesting. Such a systematic defect flow process can be established and the history for the same can be maintained. Graphs and reports can be customized and metrics can be derived out of the maintained defect repository.
b. Test Director (TD):
Test Director is an Automated Test Management Tool developed by Mercury Interactive for Test Management to help to organize and manage all phases of the software testing process, including planning, creating tests, executing tests, and tracking defects. Test Director enables us to manage user access to a project by creating a list of authorized users and assigning each user a password
and a user group such that a perfect control can be exercised on the kinds of additions and modifications and user can make to the project. Apart from Manual Test Execution, the Win Runner automated test scripts of the project can also be executed directly from Test Director.
Test Director activates Win Runner, runs the tests, and displays the results. Apart form the above, it is used for
To report defects detected in the software.
sweAs a sophisticated system for tracking software defects.
To monitor defects closely from initial detection until resolution.
To analyze our Testing Process by means of various graphs and reports.
c. Defect Tracker:
Defect Tracker is a tool developed by Maveric Systems Ltd. an Independent Software Testing Company in Chennai for defect management. This tool is used to manage the defect, track the defect and report the defect effectively by the testing team.
Test Closure Phase:
a. Sign Off :
Sign off Criteria: In order to acknowledge the completion of the test process and certify the application, the following has to be completed.
All passes have been completed
All test cases should have been executed
All defects raised during the test execution have either been closed or deferred
b. Authorities:
The following personnel have the authority to sign off the test execution process
Client: The owners of the application under test
Project manager: Maveric Personnel who managed the project
Project Lead: Maveric Personnel who managed the test process
c. Deliverables:
i. The following are the deliverables to the Clients
ii. Test Strategy
iii. High Level Test Conditions or Scenarios and Test Conditions document
iv. Consolidated defect report
v. Weekly Status report
vi. Traceability Matrix
vii. Test Acceptance/Summary Report.
d. Metrics:
i. Defect Metrics:
Analysis on the defect report is done for management and client information. These are categorized as
ii. Defect age:
Defect age is the time duration between the points of introduction of defect to the point of closure of the defect. This would give a fair idea on the defect set to be included for smoke test during regression.
iii. Defect Analysis:
The analysis of the defects can be done based on the severity, occurrence and category of the defects. As an example Defect density is a metric which gives the ratio of defects in specific modules to the total defects in the application. Further analysis and derivation of metrics can be done based on the various components of the defect management.
No comments:
Post a Comment