Accenture Case Study Solution by Amit Bhardwaj

XYZ
COMPANY
CGS QA Plan and Test Strategy Document Owner : Amit Bhardwaj
1 of 21
CCeennttrraalliizzeedd GGlloobbaall SSyysstteemm
QQAA PPllaann aanndd TTeesstt SSttrraatteeggyy
AMIT BHARDWAJ
QA INFOTECH
SOFTWARE TEST ENGINEER
amitbharadwaj@qainfotech.net
NOIDA, INDIA
+91-981-862-2019

XYZ
COMPANY
2 of 21
Table of Contents
1 Introduction .....................................................................................................................4
1.1 Purpose ....................................................................................................... 4
2 Product Description.........................................................................................................4
3 Scope of QA....................................................................................................................5
3.1 In Scope for testing...................................................................................... 5
3.1.1 Features to be tested................................................................................................. 5
3.1.1 Types of testing that are in scope:............................................................................. 7
3.2 Out of Scope for testing............................................................................... 7
3.2.1 Types of testing that are out of scope:....................................................................... 7
4 Test Design, Strategy & Objectives.................................................................................8
4.1 High Level Test Design................................................................................ 8
4.2 Test Entrance and Exit Criteria.................................................................... 9
4.2.1 QA Test Entrance Criteria.......................................................................................... 9
4.2.2 QA Test Exit Criteria .................................................................................................. 9
4.3 High Level Test Process............................................................................ 10
4.4 Test Objectives.......................................................................................... 10
5 Testing ..........................................................................................................................10
5.1 Guidelines.................................................................................................. 10
5.1.1 Prioritize Test Cases................................................................................................ 10
5.1.2 Test Case Review.................................................................................................... 11
5.1.3 Track Test Results................................................................................................... 11
5.2 Test Flow Process ..................................................................................... 11
5.2.1 Unit Testing.............................................................................................................. 11
• Developers will be responsible for Unit Testing and Integration Testing.......................11
• Known Issues should be added to Release Notes. QA will add known issues to
Issue Tracker if they are not already added..........................................................................11
5.2.2 Integration Testing ................................................................................................... 12
• Will be a joint effort between QA Team & Development Team.....................................12
• Issues found during Integration Testing should be formally documented in Issue
Tracker..................................................................................................................................12
5.2.3 Functional Testing.................................................................................................... 12
5.2.4 Regression Testing.................................................................................................. 12
5.2.5 Production Rollout Testing....................................................................................... 12
5.2.6 Smoke Testing......................................................................................................... 12
5.2.7 Exploratory Testing.................................................................................................. 12
6 Compatibility Requirements ..........................................................................................13
6.1 Browser Compatibility Matrix ..................................................................... 13
7 Status Tracking .............................................................................................................13

XYZ
COMPANY
3 of 21
7.1 Bug Tracking Tool ..................................................................................... 13
7.1.1 Bug Process/Cycle................................................................................................... 13
8 Roles and Responsibilities ............................................................................................14
9 Appendices ...................................................................................................................15
9.1 Document Information ............................................................................... 15
9.1.1 Revision History....................................................................................................... 15
9.1.2 References............................................................................................................... 15
9.1.3 Acronyms & Definitions............................................................................................ 15
9.2 Approvals – Signoffs.................................................................................. 17

XYZ
COMPANY
4 of 21
1 Introduction
This document describes the QA Plan and test strategy for the XYZ’s Centralized Global
System. It covers the test strategy for the builds planned for the project.
1.1 Purpose
The main purpose of creating this document is to ensure a common understanding
between the project team members (Business Analysts, Development, IT department,
Technical Support and QA) on the plan to deliver a quality product. This document
comprises of the testing scope, types of testing, entrance and exit criteria etc. This
document is an important tool the QA team uses to plan its activities.
2 Product Description
CGS is a single global instance of Oracle eBusiness Suite. A primary goal of this effort is to
make it simpler to share resource between each of the business units. It will reduce the
complexity from the firm’s one of the most critical system and provide one core system.
Together, the system allows for the deployment, management, and reporting of training-
related activities.
Following are the two modules in project:
• Time Sheet Entry to Project
This process starts with the entry of a time sheet either through electronic or
manual methods. This timesheet is then processed until it is ultimately posted to
Oracle project System against a particular set of projects.
• Time Sheet Entry to Payroll
This process also starts with the entry of a time sheet either through electronic or
manual methods. This timesheet is then processed until gross payroll amounts are
imported into the Payroll System by earnings type of eventual payment payment to
employee.
The CGS enterprise-wide computer-based Centralized Global System (CGS) is built on the
most intelligent and robust technology available, and can be delivered via the internet as well
intranet.
[Need to add product description from marketing requirements document, if any]

XYZ
COMPANY
5 of 21
3 Scope of QA
3.1 In Scope for testing
This project will be implemented in 4 phases. The scope of this document is limited to
Phase 1 features.
3.1.1 Features to be tested
The QA team will test the following features/functions of the Centralized Global System (CGS) in
Phase I.
S. No. Feature
1.0 Timesheet User Interface [Phase 1 will include the following key features:]
1.1 System will provide a way to authenticate the users who will entry in timesheet either
through electronic or manual methods.
1.2 System provides timesheet line that includes charge information and hours worked by
day.
1.3 System provides a way for user to total the timesheet by week, by day and time type
1.4 System will provide a way for the user to share the information system.
1.5 System provides all field labels displayed in German language.
1.6 System will display the date and numbers formatting follow The European convention.
1.7 System will provide a way for the users from other business units to work on project.
2.0 Workflow process [Phase 2 will include the following key features:]
2.1. System will provide a way for the users to get approval for his submitted timesheet.
2.2. System will provide a way for timesheet group level.
2.3. System will provide the way for timely submission of timesheet.
2.4. System will identified the different workflow and provide the utility to analyze it.

XYZ
COMPANY
6 of 21
3.0 Centralized Administration [ Phase 3 will include the following key features:]
The Administration function is two tiered. The initial centralized review of timesheet is done by
a local timesheet administrator who correct for missing timesheets or business rule violation.
Once these initial corrections are done, the local timesheet administrator can suspend invalid
job charge and close payroll.
Once the local administrator has closed payroll, the global administrator receives an email that
the timesheet group is closed and can perform a second screen and review of missing
timesheet and business rule violation and make any changes necessary before closing all
timesheets for final processing by project and/or payroll.
The Global administrator can perform all of the function of a local administrator including
suspend and close. This global close is at the payroll level (multiple timesheet groups’
equivalent to a payroll codes.)
3.1. System will provide a way for categories the different groups i.e. geographically and
organizational.
3.2. System provides the way to administrator to assign the multiple timesheet groups, if
needed.
3.3. System will provide a way to run reports to make sure all timesheet are submitted.
3.4. System will provide a way to review an error report to address violation of policy.
3.5. System will provide a way to enter missing timesheets so all employees can be paid
3.6. System will provide a way to enter timesheet manually for those users who are not able
to access.
3.7. System provides a way to close the local timesheet timekeeper group and send for
global approval.
3.8. System will provide a way to close the global timesheet group and send to Oracle for
extension.
3.9. System will provide adequate controls that the total of a timesheet group are valid and
that a timesheet group has closed prior to the final processing. Particular focus will
need to be placed on the requirement of this administrative function.

XYZ
COMPANY
7 of 21
4.0 Separate Extension of Timesheet [Phase 4 will include the following key features:]
4.1. System will provide the alternate way for those units which are not following the timesheet
method.(posting to project verses payroll processing)
4.2. System will provide the way to handle multiple payroll cycles.
4.3. System will provides the to process payroll based on the XYZ company code and pay
cycle.
4.4. System will provide the way of On Demand Bonus, periodically throughout the year.
4.5. System will provide the way to developed payroll extension module the calculation of
gross amount to be paid.
4.6. System will provide the way to import the amount calculated from time sheet to the
Company request (Account Dept. Or HR Dept.)
3.1.1 Types of testing that are in scope:
The QA team will test the following types of functionalities:
• Smoke Testing
• Functionality Testing
• Regression Testing
• System Testing
• End-to-end Testing
• Exploratory Testing
3.2 Out of Scope for testing
The QA team will not test the features / functions which are not listed in the Features to be tested
tale, of the CGS.
3.2.1 Types of testing that are out of scope:
[Need to add Types of testing that will not be performed by QA, if any]. For instance:
• Security Testing
• Performance Testing
• Automation
Failure / Recovery / Backup Testing are out of scope for QA.

XYZ
COMPANY
8 of 21
4 Test Design, Strategy & Objectives
4.1 High Level Test Design
The following overview outlines a high-level Test Design approach for the CGS’s Project.
1. The QA lead should be involved in the early discussion and review of Requirements and
attend technical design meetings for the project. As the requirements are baselined, it is
highly recommended that the primary QA engineer responsible for writing test cases is
invited to relevant CFT meetings in order to facilitate knowledge transfer.
2. Number of QA resources allocated for this project are ‘5’. But, we may need to add more
resources to the project at a later stage in case any ramp up is required.
3. QA resource(s) will be assigned for test case writing, test case execution, regression
testing, and bug verification. QA will report all the issues while writing test cases and all
Open Issues need to be resolved before test case execution.
4. Test Cases will be written based on the information provided on the CGS and the
Training Manual.
5. Updates regarding the functionalities or any other technical documentation related to the
project should be communicated to the Test team. The process of communicating
changes needs to be clearly outlined. For example, the Training Manual author should
send an email to QA as and when the changes are made to the Training Manual.
6. The Test Cases will be created in excel spreadsheet. Test cases will provide:
a) Description regarding the feature under consideration.
b) Specific data input in a systematic manner for testing.
c) The expected outputs corresponding to the input action.

XYZ
COMPANY
9 of 21
4.2 Test Entrance and Exit Criteria
4.2.1 QA Test Entrance Criteria
Criteria Responsible
1. Development team submits formal Build / Release notes, listing new
features that are coded, open issues, component versions, testing
considerations, and a list of bugs (SCRs) that are fixed.
Dev
2. Bugs that are fixed are moved to QA state for regression. Dev
3. When a new build arrives in QA, a QA Hand-off meeting should be
held between the Project Manager and QA Team, to discuss on the
new features added and/or the features that are updated.
Project Manager
4. All test cases have been created. QA
5. All test cases have been officially reviewed and approved. PM/QA
6. Staging Environment is available and accessible by QA team. Project Manager/
Technology Manager
7. The Staging Environment needs to be similar to the Production
environment.
Project Manager
/Technology Manager
4.2.2 QA Test Exit Criteria
Criteria Responsible
1. All tests have been executed and passed, or approval obtained from
the project manager for all unexecuted or failed tests.
QA
2. All Bugs in QA state are regressed and closed. QA
3. No High Priority/Critical Severity bugs are in Open state. QA
4. Major bugs in Open state should have a clear workaround and the
workaround needs to be documented and communicated to the
technical/customer support team
QA
5. Test Execution Report (TER) has been written and submitted for
approval by the Cross-Functional Team (CFT)
QA
6. Cross-Functional Team has reviewed all open problems (SCRs and
Proposals) and approved release during Release Readiness Review
(RRR) meeting.
CFT
7. A Production Deployment plan has been approved by the CFT. Dev

XYZ
COMPANY
10 of 21
4.3 High Level Test Process
Once the Entrance Criteria for Build/release to QA have been met, the overall Testing process
will proceed as follows:
1. Confirm the environment is stable and dependent components are using the correct
versions as listed in the Build/Release note. Development team needs to provide support
for confirmation.
2. Execute the functional and scenario based test cases.
3. Document the test results in the Pass/Fail column of the Test Case matrix.
4. Record bugs in Issue Tracker (whatever is decided with mutual understanding).
4.4 Test Objectives
Following the above approach QA will:
• Provide formal review of requirements, Use Cases and other specifications for testability
early in the project life cycle.
• Attend Technical Design meetings appropriate to Test Management.
• Use Requirements Based Testing (RBT) for Functional Testing driven from and tied
directly to requirements and user interface features.
• Use Scenario Based Testing (SBT) as a strategy for assuring the overall quality and
establishing the acceptance criterion in the early stages of development.
• Document all QA/Testing processes with respect to this project to facilitate utilization of
remote QA assets and improve overall flexibility and responsiveness.
5 Testing
5.1 Guidelines
5.1.1 Prioritize Test Cases
Tests shall be prioritized. Frequently, more tests are defined than can be executed within
resource constraints. Therefore, it is critical to execute the most important tests first. Test writers
shall prioritize the tests into 3 levels based on input provided from Development relative to Impact
Analysis and/or Critical Path statements.
High (1) these should be the first tests to execute. Typically, these tests verify
critical functionality or high-risk features. Commonly known as Main-Flow
test cases.
Medium (2) these tests represent valid conditions and likely invalid conditions. All
these tests must be implemented and executed.
Low (3) these tests typically represent low-risk conditions and rare invalid
conditions. Time permitting, these tests should be implemented and
executed, but may be omitted if resources or schedules are tight.

XYZ
COMPANY
11 of 21
5.1.2 Test Case Review
All tests should be reviewed prior to execution. Like any other deliverable, test cases can have
bugs. It is important to resolve the problems before testing so that testing is not based on
incorrect assumptions. Problems in the test documentation will be logged and tracked according
to standard inspection/review processes. Additionally, all changes to tests will be reviewed.
The CGS’s Test Cases use MS Excel and recommendations for changes will use the review
forms designated by the QA Team.
The Test Case Review Process should involve QA, the project manager writing the primary
requirements documentation, and the Development team. After all changes are made and
confirmed, the Test Case will be considered Baselined.
5.1.3 Track Test Results
Test results are logged and maintained in QA for later use. The following expectations are put on
all test results:
• The test results must include the following:
o date of the test
o version of the system under test
o name of the tester
o result (pass/fail/blocked)
o reference to any problem
• Retain test results to the greatest extent possible. If volume becomes unmanageable,
test results may be purged within the following constraints:
o Retain the results of the first test execution (where a pass or fail result was
achieved).
o Retain unit, integration, and system test records for any production-level release.
o Retain test records for the last promoted release and any test records since that
release (e.g. retain unit test records for the last release promoted to integration
and any unit test records since that release).
5.2 Test Flow Process
The Test Flow Process will incorporate the following steps.
5.2.1 Unit Testing
• Developers will be responsible for Unit Testing and Integration Testing.
• Known Issues should be added to Release Notes. QA will add known issues to Issue Tracker
if they are not already added.

XYZ
COMPANY
12 of 21
5.2.2 Integration Testing
• Will be a joint effort between QA Team and Development Team.
• Issues found during Integration Testing should be formally documented in defect tracker.
5.2.3 Functional Testing
QA will be responsible for Functional/System Testing. QA will write and execute the tests, and log
bugs into defect tracker. The Project Manager will monitor and control the staging environment
and facilitate resolutions of bugs.
The system test expectations are as follows:
• System testing will cover requirements, use cases and bugs , which are identified in the
Build/release notes. The tests should include references to the relevant requirements,
use cases and/or training manual.
• Functional/System testing will focus on the following areas:
o Compatibility Testing
o Functional Testing
o User Interface/Experience Testing
5.2.4 Regression Testing
Regression testing applies to all levels of testing (unit, integration, and system). The goal of
regression testing is to confirm that the functionality that previously worked still works. The
expectations for regression testing are as follows:
1. Development shall provide an Impact Analysis for each Build/Release detailing a list of
functionality potentially impacted by code changes in the release.
2. Regression testing shall include validation of SCRs listed in the Build/Release Notes for
each test cycle.
3. Regression tests shall exercise the important features of the system.
4. After a new feature passes testing, it should be included in the Regression test suite.
5.2.5 Production Rollout Testing
A series of planned Smoke Tests will validate rollout of the release to Production.
5.2.6 Smoke Testing
A specific set of test cases need to be run in order to verify whether the main functionalities are
working fine.
5.2.7 Exploratory Testing
Once the documented test cases are executed, QA will explore the CGS application and execute
scenarios that were not documented at the time of test case preparation.

XYZ
COMPANY
13 of 21
6 Compatibility Requirements
6.1 Browser Compatibility Matrix
The following table outlines the CGS’s Compatibility Matrix.
Browser / Platform IE 5.5 IE 6.0 Netscape 7.2 Firefox Safari
Windows 2000
Windows XP
MAC OS 10.3
MAC OS 10.4
** The supported versions and complete system requirements need to be reported to QA.
7 Status Tracking
The Test Case Summary Tab of the Bug Metrics will show the number of test cases executed,
passed, and remaining to be executed. Integration Bugs that are fixed will not be part of Bug
Metrics.
The Bug Triage report will show the bug report status by severity.
7.1 Bug Tracking Tool
The bug tracking tool that will be used by QA to report and track the status of the bugs will be
defect tracker.
7.1.1 Bug Process/Cycle
[Need to add Bug Process Workflow description from Project Manager.]

XYZ
COMPANY
14 of 21
8 Roles and Responsibilities
The table below shows the various roles required for the testing effort and the responsibilities for
each role. Please note that a person may fill multiple roles.
Role Responsibilities
QA Engineer/Lead
• Writes the overall test plan.
• Create/Execute functional/system test cases.
• Performs regression testing
• Documents all problems found using Issue Tracker.
• Executes system tests and verifies problem fixes.
• Maintains test case execution metrics.
• Sends daily QA status to the Project Manager
• Attends project meeting
• Participates in design/review meetings and provides review
comments
Tech Lead and/or
Developer • Generates Build/release notes and Impact Analysis guides.
• Create unit and integration test cases/scripts.
• Updates design documentation.
• Provide unit test results/coverage.
• Reviews QA Test Plan.
• Develop/executes unit tests.
• Writes problem reports for all open issues at the end of unit
testing.
Project Manager
• Works with QA to address test process issues, staging
environment issues, access issues.
• Tracks the status of testing tasks in the project schedules.
• Reviews QA test plan and test cases

XYZ
COMPANY
15 of 21
9 Appendices
9.1 Document Information
9.1.1 Revision History
Version Date Author Description Status
0.1
9.1.2 References
No. Title
1. Training Manual
2. Requirement Doc / SRS
Webex demo if possible
3. Wireframe
9.1.3 Acronyms & Definitions
Term Definition
Compatibility
Testing
Compatibility Testing ensures the functionality and reliability of the
product on the supported browsers and platforms
Impact Analysis A study of the impact of changes made by developers during a given
release that are likely to affect functional or non-functional requirements.
Recovery Testing Testing aimed at verifying the system’s ability to recover from varying
degrees of failure.
Failover Automatically switching to a redundant or standby server, system, or
network upon the failure or abnormal termination of the currently active
server, system, or network (a “hot standby” or “warm standby”). Failover
happens without human intervention. This feature is usually built-in to
expensive systems that must be available continuously.
Failover and
Recovery Testing
Failover and Recovery Testing ensures that the target-of-test can
successfully failover and recover from a variety of hardware, software or
network malfunctions with undue loss of data or data integrity. Failover
testing ensures that, for those systems that must be kept running, when a
failover condition occurs, the alternate or backup systems properly “take
over” for the failed system without loss of data or transactions. Recovery
testing is an antagonistic test process in which the application or system
is exposed to extreme conditions, or simulated conditions, to cause a
failure, such as device Input/Output (I/O) failures or invalid database
pointers and keys. Recovery processes are invoked and the application
or system is monitored and inspected to verify proper application, or
system, and data recovery has been achieved.

XYZ
COMPANY
16 of 21
Term Definition
Functional Testing Function testing of the target-of-test should focus on any requirements for
test that can be traced directly to use cases, click stream or business
functions and business rules. The goals of these tests are to verify proper
data acceptance, processing, and retrieval, and the appropriate
implementation of the business rules. This type of testing is based upon
black box technique in which internal processes of the application is
tested by interacting with the application via the Graphical User Interface
(GUI) and analyzing the output or results.
Production Roll-out
Testing
Production Roll-out Testing is a formal, well orchestrated, mini-regression
test that occurs in the production environment upon rollout of the product.
Regression Testing 1. Retesting of a previously tested program following modification to
ensure that faults have not been introduced or uncovered as a result
of the changes made.
2. Part of the test phase of software development where, as new
modules integrated into the system and the added functionality is
tested, previously tested functionality is re-tested to assure that no
new module has corrupted the system.
3. Regression Testing occurs after receiving iterative, bug fix or
enhancement builds of the product. Regression Testing confirms that
all functionality that worked before continues to function properly.
This is accomplished by executing a standard, repeatable series of
test cases following each build of the product.
User Interface
Testing
User Interface (UI) testing verifies a user’s interaction with the software.
The goal of UI testing is to ensure that the User Interface provides the
user with the appropriate access and navigation through the functions of
the target-of-test. In addition, UI testing ensures that the objects within
the UI function as expected and conform to corporate or industry
standards.
Scenario Based
Testing (SBT)
Functional Testing based on an integrated view of the system from the
intended users prospective. This form of testing is intended to model the
users “real world” behaviors and expectations of a system and confirm
they are implemented and exhibited properly and completely.
Requirements
Based Testing
(RBT)
Functional Testing driven from and tied directly to software requirements
and features. Requirement’s Based Testing is intended to validate the
completeness and correctness of those features.

XYZ
COMPANY
17 of 21
9.2 Approvals – Signoffs
Functional
Responsibility
Name Accept Reject Reason if
Rejected
Product Manager
Project Manager
Technical Lead
QA Lead
Data QA Engineer
Configuration
Management
Systems Analysis
QA/SA Management

Accenture Case Study Solution by Amit Bhardwaj

More Related Content

Similar to Accenture Case Study Solution by Amit Bhardwaj (20)

Recently uploaded (20)

Accenture Case Study Solution by Amit Bhardwaj