Software Testing Life Cycle

Go to Top The internal processes in each of the following software lifecycle stage descriptions are
Kickoff Process in Software Testing, Informal iteration Process, Formal iteration Process, In-stage assessment Process, and Stage exit Process.

Kickoff Process in Software Testing:

• Each stage is initiated by a kickoff meeting, which can be conducted either in person, or by Web teleconference.
• The purpose of the kickoff meeting is to review the output of the previous stage, go over any additional inputs required by that particular stage, examine the anticipated activities and required outputs of the current stage, review the current project schedule, and review any open issues.
• The Primary Developer Representative is responsible for preparing the agenda and materials to be presented at this meeting.
• All project participants are invited to attend the kickoff meeting for each stage.

Informal Iteration Process:

• Most of the creative work for a stage occurs here. Participants work together to gather additional information and refine stage inputs into draft deliverables.
• Activities of this stage may include interviews, meetings, the generation of prototypes, and electronic correspondence.
• All of these communications are deemed informal, and are not recorded as minutes, documents of record, controlled software, or official memoranda.
• The intent here is to encourage, rather than inhibit the communication process.
• This process concludes when the majority of participants agree that the work is substantially complete and it is time to generate draft deliverables for formal review and comment.

Formal Iteration Process

• In this process, draft deliverables are generated for formal review and comment.
Each deliverable was introduced during the kickoff process, and is intended to satisfy one or more outputs for the current stage.
• Each draft deliverable is given a version number and placed under configuration management control.
• As participants review the draft deliverables, they are responsible for reporting errors found and concerns they may have to the Primary Developer Representative via electronic mail.
• The Primary Developer Representative in turn consolidates these reports into a series of issues associated with a specific version of a deliverable.
• The person in charge of developing the deliverable works to resolve these issues then releases another version of the deliverable for review.
• This process iterates until all issues are resolved for each deliverable. There are no formal check off / signature forms for this part of the process. The intent here is to encourage review and feedback.


• At the discretion of the Primary Developer Representative and Primary End-user Representative, certain issues may be reserved for resolution in later stages of the development lifecycle.
• These issues are disassociated from the specific deliverable, and tagged as "open issues." Open issues are reviewed during the kickoff meeting for each subsequent stage.
• Once all issues against a deliverable have been resolved or moved to open status, the final (release) draft of the deliverable is prepared and submitted to the Primary Developer Representative.
• When final drafts of all required stage outputs have been received, the Primary Developer Representative reviews the final suite of deliverables, reviews the amount of labor expended against this stage of the project, and uses this information to update the project plan.
• The project plan update includes a detailed list of tasks, their schedule and estimated level of effort for the next stage.
• The stages following the next stage (out stages) in the project plan are updated to include a high level estimate of schedule and level of effort, based on current project experience.
• Out stages are maintained at a high level in the project plan, and are included primarily for informational purposes; direct experience has shown that it is very difficult to accurately plan detailed tasks and activities for out stages in a software development lifecycle.
• The updated project plan and schedule is a standard deliverable for each stage of the project.
• The Primary Developer Representative then circulates the updated project plan and schedule for review and comment, and iterates these documents until all issues have been resolved or moved to open status.


• Once the project plan and schedule has been finalized, all final deliverables for the current stage are made available to all project participants, and the Primary Developer Representative initiates the next process.

In-stage Assessment Process:

• This is the formal quality assurance review process for each stage in Software Testing.
• This process is initiated when the Primary Developer Representative schedules an in-stage assessment with the independent Quality Assurance Reviewer (QAR), a selected End-user Reviewer (usually a Subject Matter Expert), and a selected Technical Reviewer.
• These reviewers formally review each deliverable to make judgments as to the quality and validity of the work product, as well as its compliance with the standards defined for deliverables of that class.
• Deliverable class standards are defined in the software quality assurance section of the project plan.
• The End-user Reviewer is tasked with verifying the completeness and accuracy of the deliverable in terms of desired software functionality.
• The Technical Reviewer determines whether the deliverable contains complete and accurate technical information.
• The QA Reviewer is tasked solely with verifying the completeness and compliance of the deliverable against the associated deliverable class standard.
• The QAR may make recommendations, but cannot raise formal issues that do not relate to the deliverable standard.
• Each reviewer follows a formal checklist during their review, indicating their level of concurrence with each review item in the checklist.
• Refer to the software quality assurance plan for this project for deliverable class standards and associated review checklists.
• A deliverable is considered to be acceptable when each reviewer indicates substantial or unconditional concurrence with the content of the deliverable and the review checklist items.
• Any issues raised by the reviewers against a specific deliverable will be logged and relayed to the personnel responsible for generation of the deliverable.
• The revised deliverable will then be released to project participants for another formal review iteration.
• Once all issues for the deliverable have been addressed, the deliverable will be resubmitted to the reviewers for reassessment.
• Once all three reviewers have indicated concurrence with the deliverable, the Primary Developer Representative will release a final in-stage assessment report and initiate the next process.

Stage Exit Process in Software Testing:

• The stage exit is the vehicle for securing the concurrence of principal project participants to continue with the project and move forward into the next stage of development.
• The purpose of a stage exit is to allow all personnel involved with the project to review the current project plan and stage deliverables, provide a forum to raise issues and concerns, and to ensure an acceptable action plan exists for all open issues.
• The process begins when the Primary Developer Representative notifies all project participants that all deliverables for the current stage have been finalized and approved via the In-Stage Assessment report.
• The Primary Developer Representative then schedules a stage exit review with the project executive sponsor and the Primary End-user Representative as a minimum.
• All interested participants are free to attend the review as well. This meeting may be conducted in person or via Web teleconference.
• The stage exit process ends with the receipt of concurrence from the designated approvers to proceed to the next stage.
• This is generally accomplished by entering the minutes of the exit review as a formal document of record, with either physical or digital signatures of the project executive sponsor, the Primary End-User Representative, and the Primary Developer Representative.

The initial steps to get a project is one of our Organization Business Analysts will go to Client place and he collects all the requirements and negotiate with the Clients regarding project and once it is approved he prepares documents like Project Proposal, Statement of Work, User Requirements Document and Business Rules. So these are the initial documents for any project.

Let us discuss in the stages of the Life cycle in Software Testing