Software Development Life

Cycle
SOFTWARE TESTING LIFE CYCLE
SDLC: Software Development Life Cycle
has 5 Phases

1. Initiation
2. Define
3. Design and Development Phase
4. Testing Phase
5. Implementation Phase
6. Maintenance Release
 1. Initiation Phase

People Involved: Client Vice President, IT Vice President and Project Manager
Documents Created: Project Charter and Project Plan

 Project Charter document is created by IT VP, outlining the project budget, Project Timelines and Project History.
 Project Charter document is reviewed and signed off by both the parties (Client VP and IT VP).
 Project Manager is hired.
 Project Manager created a draft version of Project Plan using MS Project (MS Office Tool).
 Project Plan is reviewed with all the stake holders to understand the timelines of all the task deliverables.
 2. Define Phase

People Involved: Business Analyst, Business System Analyst

Documents Created: BRD, SRS

 BRD – Business Requirements Document is outlined by the Business Analyst.

 BRD consist of Business Requirements that were gathered by the BA (Business Analyst) by organizing constraint Brainstorming sessions.
 BRD document is created using a standard approved BRD Template created based on IEEE standards.
 BRD is a detailed non-technical descriptive document so that both Non Technical(Client) and Technical (Developers and Testers) people
can understand the documented requirements.
 BRD draft version is reviewed and presented to the project members for sign off.
 SRS – System Requirements Specifications/Document is outlined by the Business Systems Analyst.
 SRS is a technical requirement document created based on BRD.
 2. Define Phase(Continuation)

People Involved: Business Analyst, Business System Analyst

Documents Created: BRD, SRS, Use Case Documents

 SRS draft version is reviewed and presented to the Stake Holders for sign off.
 Use Case documents are created by Business System Analyst. It consists of UML(Unified Modeling Language)
diagrams which are created in MS VISIO
 Use Cases are created using a standard Use Case Template created based on IEEE standards.
 Use case documents are created to avoid miscommunication or misunderstanding of the requirements as both the
BRD and SRS are written using descriptive language.
 Use case documents outline the Flow of requirements using Main Flows diagrams, Alternative Flow diagrams, Pre
Condition, Post Conditions and Actors involved (Users using the functionality).
 3. Design & Development Phase

People Involved: System Architect, Database Administrator, Development Manager, Development Lead. Developers
and Programmers
Documents Created: System Architecture, Design Document

 System Architect created a System Architecture document outlining the type of technology to be used (EX: Client
Server (2-tier) or Web Based (3-tier)).
 SAD – System Architect document outlining the end to end architecture of the project with an architecture diagram.
 System Architecture document would help us to understand the project at the bird’s eye view.
 System Architecture document is reviewed and signed off by all the Stake Holders.
 3. Design & Development
Phase(Continuation)
People Involved: System Architect, Database Administrator, Development Manager, Development Lead. Developers
and Programmers
Documents Created: System Architecture, Data Model document

 Data Model document is created by the DBA to create the database and tables in the database.
 Data Model document outlines the complete database structure and its table relationship, primary keys and, foreign
keys.
 The data table fields are mapped to the application to front end fields.
 3. Design & Development
Phase(Continuation)
People Involved: System Architect, Database Administrator, Development Manager, Development Lead. Developers
and Programmers
Documents Created: System Architecture, Data Model document, Design Documents

 Design document is a low level (detailed) document created based on BRD, SRS, Use Cases, Data Model and
System Architecture documents.
 Design document is the most technical document which will help the developers and programmers to code the logic
of the software based on the requirements.
 Developers and Programmers create the code based on the assigned modules to them.
 White Box testing is performed on the created code. White Box testing consist of Unit, Integration and, Module
Testing. Once White Box testing is complete all the code Modules are put together into a Application Build
(Application itself).
 4. Testing Phase

People Involved: QA Manager, QA Lead, Sr. QA, Testers

Documents Created: Test Strategy/Test Plan Document

Test Planning
 All the project documentation are gathered (BRD, SRS, Use Cases, Architecture, Design, Data Model documents).
 After reviewing the documents Gaps (Missing information) are identified and reported to the author
 Based on the project documentation Master Test Plan (MTP) is created.
 MTP is a detailed plan on how to make the testing successful for a specific project that can involve multiple applications.
 MTP is documented in a standard approved Template based on IEEE standards.
 MTP is reviewed and signed off by the stakeholders.
 4. Testing Phase (Continuation)

People Involved: QA Manager, QA Lead, Sr. QA, Testers

Documents Created: Test Strategy/Test Plan Document

Test Planning
Test Scenarios
 Based on the project documentation Test Scenarios are created.
 Test Scenarios are created to ensure the requirement coverage.
 Test Scenarios are high level and used to identify the Test Data Requirements.
 4. Testing Phase (Continuation)

People Involved: QA Manager, QA Lead, Sr. QA, Testers

Documents Created: Test Strategy/Test Plan Document

Test Planning- Test Cases/Test Scripts

 Test Cases are created based on Test Scenarios.
 Test Cases are step by step details on how to test the functionality, created based on the project documentation.
 Test Cases are created based on standard approved test Case Template.
 Test cases are reviewed internally and produce for external review.
 Business Analyst reviews and sign off the test cases to ensure if all the functionality covered by the test cases.
 Once the Test Data is available test Cases are mapped with the test Data to ensure One to One relation.
 Test Cases are created and group according to its related functions; the concept is called as Equivalence Class.
 4. Testing Phase (Continuation)

People Involved: QA Manager, QA Lead, Sr. QA, Testers

Documents Created: Test Strategy/Test Plan Document

Test Planning- Test Cases/Test Scripts

 Test Environment Requirements are provided to the Test Environment Specialist (Developers, System Analyst and/or
DBA).
 Test Environments are identified and request for Environment Access.
 After all the above Planning tasks are completed Test Readiness Review is conducted to make sure the Application
Build, Test Scenarios, Test Cases, Test Data and, Test Environments are ready by organizing a meeting with Project
Manager, Business Analyst, Developer and, DBA.
 4. Testing Phase (Continuation)

People Involved: QA Manager, QA Lead, Sr. QA, Testers

Documents Created: Test Strategy/Test Plan Document

Test Execution
 Application Build is received into the test Environment.
 Sanity Testing is conducted to make sure its stable to perform further testing; this is Tester’s Build Acceptance
Testing.
 Sanity Testing is performed by executing Test Cases that belong to core functionality.
 Sanity Testing will be successful when 90% of the selected Test Cases pass
 4. Testing Phase (Continuation)

Functional Testing is performed by executing all the test cases on the application by applying both Positive and Negative testing.
The following types of tests are performed as part of functionality testing:
1. Cross Browser Testing is performed on the application to validate the compatibility of the browsers.
2. Cross Platform Testing is performed on the application to validate the compatibility of the Operating Systems.
3. Backend Testing or Database testing is performed to check if the data entered in the front end is properly being received at the
Backend database tables.
4. Data Mapping Testing is performed as part of Backend testing to check if the data entered from the front fields are properly getting
stored in the backend testing fields.
5. Data Validation Testing is performed to check if the data entered from the front end is properly getting stored without truncation or
corruption.
6. Data Integrity Testing is performed to check if the data is the same when retrieved to the front compared to the backend tables.
7. Data Conversion Testing is performed when data is moved from one database to another. Data Conversion is performed by
executing comparative Inquiry Testing by comparing data from Source database to the Target database.
 4. Testing Phase (Continuation)

System Testing

 System Integration Testing is performed to check if the data/information is properly being exchanged
between two applications.
 System Integration Testing can only be performed between two applications.
 System Integration Testing is performed between all the applications in the end to end architecture.
 4. Testing Phase (Continuation)

User Acceptance Testing

 User Acceptance Testing is performed by the actual end users validate the functionality to check if the
application functionality if users friendly to use.
 User Acceptance Testing is performed by coordinating with the System Testers by using System Test
Cases.
 User Acceptance Testing is performed in UAT Environment.
 UAT defect are identified by the End users but reported by System Testers.
 4. Testing Phase (Continuation)

Load Performance and Stress Testing

 Load Testing is conducted on the completely tested build after UAT.
 Load Testing is performed using LoadRunner by applying load (Virtual Users) on the server to identify
the Benchmark of the server. Benchmark of the server is identified by constantly increasing the load on
the server until the server crashes; the crashing point of the server is called as benchmarking.
 Performance Testing is done after Load Testing to ensure that the response times are acceptable when
Load is applied.
 When Load is applied Performance decreases, based on the response times the performance is evaluated
by comparing to service Level agreements (Performance requirements).
 Stress Testing is performed to check if the Performance response times are acceptable when load is
applied from multiple application servers.
 4. Testing Phase (Continuation)

Regression Testing
 Regression Testing is performed whenever there is a code change in the application because of Defects
or Enhancements.
 Regression Testing is performed to check if the existing functionality is not broken during code fixes.
 Regression Testing is usually performed using automated tools like: WinRunner, Quick Test,
Professional, Rational Quality Manager
 Daily Test Execution Status reports are provided to the management by providing a scrum meeting or a
status report.
 5. Implementation Phase

People Involved: Implementation Manager or Release Manager, System Analyst, DBA and, Development Team

Documents Created: Release Notes

 Implementation Manager creates a implementation plan on how to install and implement the software application into production.
 Implementation plan is reviewed and sign off by all the stake Holders.
 Based on the Implementation tasks DBA, System Analyst and Development team will prepare all the related tasks to move the code to
production.
 Final tested application build retested in Pre-Production tested to ensure all the files and folders are copied from development server to Pre-
Production server (Staging Environment).
 Pre-Production testing is signed off by all the Stake Holders.
 The application build will be then deployed into Production.
 Production testing is performed on live production environment to ensure all the application is deployed properly into production.