American Car Center (ACC) MVP

Test Strategy
Date Version Author Description
3/10/2022 1.0 Chilenew QA test strategy for ACC
Belachew System

ACC Test Strategy Document

Contents
Abstract 4
Background 4
Concepts 5
1. Agile Process/ Procedure 5
2. Test Approach 6
I. Test Types 7
3. Test Environment 9
4. Test Automation and Testing Tools 10
I. Automation Strategy: 10
II. Tools 10
III. Test Data 10
5. Risk Analysis 10
6. Test Planning and Execution 11
1. Test Case 11
2. Test Suite 13
3. Defect Management 13
7. Reporting/Metrics: 15
I. Test Completion Criterion 15
II. In - Sprint testing: 16
III. Regression Testing: 16
IV. Performance Testing: 16
V. Defects: 16
8. Communication Strategy and Approach 16
9. Review and Approval 20

ACC Test Strategy Document

Document Version Control

Version History
Version No. Date Reason for
Amendment
- - -

Document Reviewer and Approver

Actions Name Date
Authorized for Release By Rediet Tsigeberhan
Approver -
Reviewer Daniel Hagos 03/16/2022,
Yonas Demeke 03/16/2022,
Original Author Chilenew Belachew
Owner Chilenew Belachew

ACC Test Strategy Document

Abstract

This document provides strategies to be followed in testing American Car Center (ACC) MVP
projects at DePalma Studios. The document does not include specific test cases, the list of test
cases and steps for each test case are provided in a separate document. This document
presents a strategy for testing, acceptance criteria, test related products and responsibilities
related to quality assurance tasks in ACC. The document should be use as a guideline for
performing all activities within the testing process.

It could be used by all participants in the project. Especially it should be use by development
teams (the unit/integration tests and the bugs definition), test teams (the whole document),
architects (bugs and test cases processes), use case application users (test reporting and bugs
handling) and managers (management of the releases and the testing process). In detail, this
document defines the test strategy, and describes various levels of testing (e.g. unit testing,
integration testing, functional testing, and non-functional testing). The next main topic covered
is the environments configurations, including their purposes, followed by test process
descriptions. For the test process descriptions, the document explains the process of testing,
how to use it in the project, the purpose of the process, and where to find more information.
Furthermore, this document describes test related products delivered within the ACC project,
including a Test Plan, Test Cases with scenarios, and a Test Report. Finally, the document
covers communication and responsibilities related to quality assurance in the project.
Altogether, this deliverable should represent a complete and comprehensive guide for the
most important quality assurance tasks with regards to testing in the project.

ACC Test Strategy Document

Definitions and Acronyms
The following list will help the team to handle different terms and definitions:
• QA = Quality Assurance
• DEV = Development
• AC = Acceptance
• ACC= American Car Center
• CMS = Content Management System
• FAQs= Frequently Asked Questions
• MVP = Minimum Valuable Product
• PO = Product Owner
• CI/CD= Continuous Integration / Continues Deployment
• API = Application Programing Interface
• UI = User Interface

Background

Client
American Car Center is company that has been helping connect hardworking people with
quality, pre-owned vehicles and innovative financial solutions regardless of their credit history.
The very first American Car Center was opened in 2000 on Mt. Moriah Rd. in Memphis,
Tennessee. The success of this dealership led us to open 3 more locations in the Memphis area.
Company has now grown to over 68 dealerships in 10 states, becoming the "go-to" solution for
people across the Southeast outside of the traditional used car dealership. Here we are
developing web application for this company which is American Car Center System
(Application).
American Car Center application is web application that will allow companies to post available
car products, Dealerships, and shop of the company. This system will also help you to look
shops with available vehicles, blogs posted by company within different time, and FQAs,
Contact us and about us of ACC. This effort will focus on MVP that is allow ACC to post shop
with available vehicles, globs, location of dealers near with you, about us, contact us and FAQs
of ACC.

ACC Test Strategy Document

Concepts
In this section, we will be covering the test strategy approach component in detail.

Concept Description
Agile Process/ Procedure The Product Management, Development, QA
team plays a key role in delivering a product
with superior quality.
Test Approach Defines testing strategy, roles and
responsibilities of various team members,
and test types.
Testing Environments Outlines which testing level is carried out in
development, QA, Production environment.
Testing Automation and Tools Addresses test management and automation
tools required for test execution.
Risk Analysis Defines the approach for risk identification
and plans to mitigate risks as well as a
contingency plan.
Test Planning and Execution Defines the approach to plan the test cases,
test scripts, and execution.
Communication Strategy All test activity is visible and transparent to
the project stakeholders.
Review and Approval Lists individuals who should review, approve
and sign off on test results.

1. Agile Process/ Procedure

Quality should be owned by every single team that is part of the Agile Software Development Life
Cycle.

 Pre-Planning (Backlog Grooming): QA needs to be involved early in the cycle.

Product backlog should be detailed appropriately, estimated, and prioritized that
owns the quality of the requirements.QA should be able to identify both
functional and non-functional requirements.
 Development: Coding standards, code quality, and code reviews by the

ACC Test Strategy Document

 developer team.
 Testing: In Agile methodology, Stories should be tested within the sprint and
testing must start early in the sprint cycle. The team should focus on the below
testing.
 Structured testing - Ensure all test cases are executed and passed.
 Non - Structured testing: Perform exploratory testing that makes the QA team
think outside the box and come with up edge case scenarios and break the
application.
 Non- Functional testing: Identify any performance and security testing that
needs to be done.

2. Test Approach
It describes how and who will do the testing, the type of testing being conducted, features
being tested, environment(s) where the testing takes place, what testing tools are used.

Type of testing Automation/ Manual Roles

Unit Testing Automation Dev
Integration testing Automation + Manual Dev
Functional/In-sprint testing Manual + Automation QA
Regression testing- In-Sprint Automation + Manual QA
Regression Testing- End to End Automation + Manual QA
Performance Testing Automation QA
User Acceptance Testing Manual PO
Smoke Testing Automation QA
Prod Sanity Testing Automation + Manual QA
I. Test Types
Software Testing means Verification of Application Under Test (AUT). To achieve this, we need
to perform a different activity to check whether the actual results match the expected results
and to ensure that the software system functioning as expected.

Unit tests, Integration Test and System Tests are good ways to verify the functional
requirements of the application.

ACC Test Strategy Document

1. Unit Testing: This Will be performed by developers to ensure each individual unit
or function produces the expected output.
Frequency: Before new code is written
2. Functional/ In Sprint Testing: QA will verify the software system against the
functional requirements based on the test cases prepared.
Frequency: In Every Sprint
3. Integration Testing: Dev will perform integration testing to evaluate the
compliance of a system or component with specified functional requirements
Frequency: After Unit test is conducted
4. Regression Testing: QA will perform regression to ensure that existing
functionality is not broken due to the code changes made for the current
release.
Frequency: Once a release/At the end of every sprint
5. Performance Testing:
Load & Stress Testing: QA will perform load testing by constantly and steadily
increasing the load on the system and measure how the system responds to it.
Frequency: Before a release

6. Smoke Testing: QA ensures the build is stable by verifying whether the important
features are working.
Frequency: After a release

ACC Test Strategy Document

 7. Browser compatibility testing: ensuring that website or web application works as
intended in any given browser.
Frequency: For every feature

8. Browser Device Compatibility testing: Check the application working in the same
way on different browser-OS combinations, devices, and assistive tools.
Frequency: For all features
9. Security Testing: To uncover vulnerabilities of the system and determine that its
data and resources are protected.
Frequency: Once a release
10. Localization Testing: It is a process of testing a globalized application whose UI,
default language, currency, date, time format is designed as per the targeted
country or region. It ensures that the application is capable enough for use in that
country.
Frequency: For all features
11. Prod Sanity Testing: After production deployment, QA will execute a high-level
checklist to catch any deployment-related issues.
Frequency: Post-deployment
12. User Acceptance Testing: this testing is performed by end users before the system
can be certified as ready to go live. It is conducted in the last sprint before go live,
and by the end users who would use the system after it is live. Users must be given
brief training in the requirements. Acceptance criteria must be clearly defined for the
system functions required to go live.
13. Production Validation: validation testing should be carried out after the build has
been released to the production environment to ensure the functionality has been
deployed correctly. Typically, production validation is executed during off hours using
a sample data set in production. Proper and complete production verification
requires knowledge of the solution and experience with common build issues. If
issues are found, the agile team should determine if the functionality was deployed
correctly or whether roll-back procedures must be implemented. Once completed,
the test data sets should be removed or deactivated within the environment.
Production validation is conducted by the agile core team members, CA PPM
administrator and end users.
3. Test Environment
A test environment is any space in which software undergoes a series experimental uses.
The following table shows which types of testing are conducted in each environment.

ACC Test Strategy Document

Whenever the changes are migrated from one environment to another, it is advisable to
revalidate testing conducted in the prior environment in the new environment.
Type of testing Environment Team
Unit Testing Dev Dev
Integration testing Pre-prod Dev
Functional/In-sprint testing QA QA
Regression testing- In-Sprint QA QA
Regression Testing- End to End Pre-Prod QA
Performance Testing Pre-Prod QA
User Acceptance Testing Prod PO
Smoke Testing Prod QA/PO/Client
Prod Sanity Testing Prod QA
4. Test Automation and Testing Tools
I. Automation Strategy:
 Identify the features of sprint items for regression.
 Prioritize and plan the efforts for reducing the backlog based on resource availability.
 Identify automation tools, a framework to be incorporated.
 Coordinate with the Dev team to implement the framework specific to the product
line.
II. Tools
 Test Case Management: testlink, Testrail, testQ
 Requirement management tool: Jira
 Automated test script repository: Bitbucket
 Unit test: Jest and Xunit
 Browser compatibility: Browser stack.
 Functional Automation: Cypress, Visual Studio.
III. Test Data

Test Data is data that is used to execute the tests. It is data which has been specifically identified for
use in tests. Test data needs to be precise & exhaustive to uncover the defects.

 Test Data Generation Techniques:

 Manual
 Mock data generated from the API

ACC Test Strategy Document

 5. Risk Analysis
The agile core team should develop a comprehensive list of all potential risks. The following
Risks are identified.
• Resource Availability
• Technical
• Scope
• Business Process

Risk Mitigation Strategy Impact

Delays in delivering completed Test Product Management and Development

Items from Development would to advise of any delays and adjust Release
1 High
impact test timescales and final Scope of Resources to allow the test
Release quality activities to be performed.
Delays in the turnaround time for Strong management of bug resolution
fixing critical bugs, which would would be required from Development to
2
require re-testing, could have an ensure bugs are fixed and available for re- High
impact on the project dates. testing in the scheduled time.
The Test Team, Development, or PM
The Test Team, Development, and PM
teams require domain guidance from
teams to ensure they are available at
3 one or the other and they are not Medium
critical points or contactable during the
available. This would delay project
project activities.
activities.
The Test Team will record untested
Features of Test Items will not be features and request the PM to assess Low
4
testable. business risk in support of the release of
untested features.

6. Test Planning and Execution

Test planning and execution are tasks that should be done for every sprint.
The steps involved in planning and executing testing are:

• Use cases/user stories have been clearly defined

• Build test cases and test scripts based on use cases
• Define acceptance criteria for each feature and each process

ACC Test Strategy Document

 • Conduct testing
• Review and approve test results
1. User Story
User stories are short, simple descriptions of a feature told from the perspective of the person
who desires the new capability, usually a user or customer of the system. A user story is an
informal, general explanation of a software feature written from the perspective of the end
user. Its purpose is to articulate how a software feature will provide value to the customer. It's
tempting to think that user stories are, simply put, software system requirements.
A user story is a requirement for any functionality or feature which is written down in one or
two lines and max up to 5 lines. A user story is usually the simplest possible requirement and is
about one and only one functionality (or one feature). The most commonly used standard
format for a User Story creation is stated below:
As [a user persona], I want [to perform this action] so that [I can accomplish this goal].
Definition of Ready
Definition of Ready defines the criteria that a specific user story has to meet before being
considered for estimation or inclusion into a sprint. Whereas a Definition of Ready is focused
on user story level characteristics, the Definition of Done is focused on the sprint or release
level User Story is clear
Sample Definition of Ready (DoR)

 User Story is testable

 User Story is feasible
 User Story defined
 User Story Acceptance Criteria defined
 User Story dependencies identified
 User Story sized by Development Team
 Scrum Team accepts User Experience artefacts
 Performance criteria identified, where appropriate
 Scalability criteria identified, where appropriate
 Security criteria identified, where appropriate
 Person who will accept the User Story is identified
 Team has a good idea what it will mean to Demo the User Story

Definition of Done

ACC Test Strategy Document

The Definition of Done is an agreement between Development Team and the Product Owner
on what needs to be completed for each user story – and it is often standardized across the
company in order to guarantee consistent delivery of quality.
Sample Definition of Done

 Code produced (all ‘to do’ items in code completed)

 Code commented, checked in and run against current version in source control
 Peer reviewed (or produced with pair programming) and meeting development
standards
 Builds without errors
 Unit tests written and passing
 Deployed to system test environment and passed system tests
 Passed UAT (User Acceptance Testing) and signed off as meeting requirements
 Any build / deployment / configuration changes are implemented / documented /
communicated
 Relevant documentation / diagrams produced and / or updated
 Remaining hours for task set to zero and task closed.

2. Test Case and test Suite

A test case is a document, which has a set of test data, preconditions, expected results, and
post-conditions, developed for a particular test scenario to verify compliance against a specific
requirement. It is a set of actions performed on a system to determine if it satisfies software
requirements and functions correctly.
Test Case acts as the starting point for the test execution, and after applying a set of input
values, the application has a definitive outcome and leaves the system at some endpoint or
also known as execution post-condition. Every test case should have at least the following Test
Case Parameters
 Test Case ID
 Test Scenario
 Test Case Description
 Test Steps
 Prerequisite
 Test Data
 Expected Result

ACC Test Strategy Document

  Actual Result
 Environment Information
A Test Suite is a container that has a set of tests that helps testers in executing and reporting
the test execution status. It can take any of the three states namely Active, in progress, and
completed.
Note:
 Test suites are created for each related user story. It can contain any type of tests
functional or Non-Functional.
3. Test Case Review and Approve
Test case Review:
Test case review process is an important process to follow in software testing. Test case
ensures that each and every functionality mentioned in Software Requirement
Specification is covered. Test case should be effective and also follow the standards to
write test case.
 Test cases created by the QA team for in-sprint/functional testing will be
reviewed with respective SCRUM team members.
 Mandatory Participants: Product owner, Dev, QA.
Test case Approve: QA Lead, if present, will approve the test cases. Otherwise, Peer Reviews
are a good way of evaluating the test cases.

4. Test Execution
Test execution refers to execution of test case or test plan on a software product, to ensure the
fulfilment of the pre-defined requirements and specifications of the developed software
product. Test execution is the process of executing the code and comparing the expected and
actual results. Following factors need to be considered for a test execution process − Based on a
risk, select a subset of test suite to be executed for this cycle. Assign the test cases in each test
suite to testers for execution

5. Defect Management
A Defect is an error in coding which causes incorrect or unexpected which does not meet actual
requirements.
 Defect Management Process/ Cycle
Defect management is a systematic process to identify and fix bugs. A defect management cycle
contains the following stages.

ACC Test Strategy Document

 Discovery of Defect
 Detect the defect
 Investigation about defect
 Report the defect to the development team
 Developer accept or reject the defect
Defect Category
 Pre -Production: is defect is discovered before released to Production
 Production: if defect is discovered on production environment by end user
 Defect Priority: Defect categorization help software developers prioritize their tasks.
 Critical The defect needs to be fixed immediately that may cause great damage
to the product.
 High: The defect impacts the product main features
 Medium: The defect causes minimal deviation from product requirement
 Low: The defect affects has a very minor effect on product operation

ACC Test Strategy Document

  Fixing of Defect by developers/ Resolution

 Assignment: Assigned to a developer

 Schedule fixing: The developer side takes charge in this phase. They will create a
schedule to fix these defects, depend on the defect priority.
 Fix the defect: While the development team is fixing the defects, the Test Lead
tracks the process of fixing the defect compared to the above schedule.
 Report the resolution: Get a report of the resolution from developers when
defects are fixed.

 Verification by Testers
 After the development team fixed and reported the defect, the testing team
verified that the defects are resolved.
 Defect Closure
 Once a defect has been resolved and verified, the defect is changed status as
closed.
 If the defect is not resolved properly. defect should be reopened again for
developers.
 Test Reports
 Test Lead prepares and sends the test report to the management team for
feedback on the test management process and test status.

7. Reporting/Metrics:
I. Test Completion Criterion
A check against the test exit criteria is very much essential before we claim that the testing is
completed. Before putting an end to test process the product quality is measured against the
test completion criteria.
The Exit criterion is connected to the test coverage, test case design technique adopted; risk
level of the product varies from one test level to another.
Test Completion Criteria - Examples:
 Specified coverage has been achieved.
 No Showstoppers or critical defects.
 There are very few known medium or low-priority defects that don't affect the
usage of the product.
Test Completion Criteria - Significance:

ACC Test Strategy Document

  If the Exit criterion has not been met, the test cannot be stopped.
 The Exit criterion must be revamped, or the time should be extended for testing
based on the quality of the product.
II. In - Sprint testing:

 Coverage for references

 Summary for References
 Number of Test Cases Passed
 Number of Test Cases Failed
 Number of Test cases blocked
 The Number of bugs based on severity.
III. Regression Testing:
 Number of Test Cases Passed
 Number of Test Cases Failed
 Number of Test cases blocked
 The Number of Bugs/Defects based on severity.
IV. Performance Testing:
 Set baseline metrics
 Latency
 Connect time
 Elapsed time
 Throughput
 Response time
V. Defects:
 Escape rate: Number of defects per release that are discovered in production by
customers.
 The Number of defects based on severity.
 The Number of defects based on priority.
 Number of defects by component.
 Number of defects by customer

8. Communication Strategy and Approach

ACC Test Strategy Document

The communications approach described here will ensure that key questions are answered
throughout the testing phases.

Question Action to communicate answers The Benefit of this

approach
In each phase of Test Leads will produce a Test Formal document
testing: Approach for their test phase. produced
What is being <phase> Test Plan
tested? Where is it detailing:
being tested? * What is being tested?
When will it be tested? * What isn't being tested?
Who will be testing it? * Who is testing what?

* Where will the testing

occur?
When will it happen?
Produce a coverage matrix of test Requirements without
requirements to test scripts. tests can be identified and
Are we testing managed.
enough during each Get agreement from the project
phase? stakeholders that the test scripts cover
the requirements to the required depth.
Work on the principle of Plan, Do,
Check, Act. Identify what needs to be Confidence in the depth,
tested. breadth, accuracy, and
Are our test scripts Document how to verify each
correct and completeness of the tests
requirement. Get agreement from the planned to be executed.
complete? Design, Build, and Business Teams that
the test steps and expected results are
correct and email confirmation of
agreement to the project.
Requirements that have no apparent A complete list of
measurable success criteria, e.g., no requirements that will
method of verifying if they operate not be tested is available
correctly or not, are given a status of for the Test Lead and
How do we handle 'Test Exclusion'. project stakeholders to
requirements that see.
we cannot verify? The 'Test Exclusions' are reviewed by the

ACC Test Strategy Document

 Test Leads and project stakeholders and
either a measurable success criteria An agreed list of
method and expectation are identified, or requirements that will not
the status of 'Test Exclusion' is agreed, be tested is visible to
with a Risk value assigned to it. everyone on the project.
Delivery of each Entry
List the entry criteria for the test phase Criterion can be allocated
Are we ready to start and report progress on the delivery of to a person, responsible
testing? each in the Weekly <phase> Test to deliver, and progress
Progress Report can be reported on that
delivery.
Daily get together by Test Lead and Test Short meeting, to
Managers to explain what was delivered exchange information, and
yesterday and what is planned to be to enable the Test Lead to
delivered today. priorities strategic
What needs to be done requirements, and for Test
today? Managers to understand
what is needed to be
delivered and to
escalate risks and issues.
Test Manager issues email to Test Team The Test Team share
with a summary of: success has clearly
what was delivered yesterday? defined goals, with a
What needs to be delivered today, method of knowing when
identified risks and issues, and what they have met their goals.
is being done to manage them. The Sight of issues and
risks that have been
escalated, and what is
being done to resolve
them.
Documented summary of
<Phase> Test Managers will produce a what has happened
Test Phase Results report, detailing during a test phase,
what was tested, what wasn't, where which is an indication
and how it was tested, the results of that a test phase is ready
every test and the status of all defects for the Quality Gate
found. Management process to
start.

ACC Test Strategy Document

 Execute a Quality Gate Management The project will have
Process that reviews the following: confidence that the
Have we finished Evidence of what has been tested, by required testing has been
testing? whom, and when has been provided. completed satisfactorily.
The phase Entry Criteria have been met.
The phase Exit Criteria have been met.
The outstanding defects have been
reviewed and an agreement obtained
that we can proceed to the next phase
of the
project.
Meetings are held before a Gate Everyone knows what
Delivery, to ensure that the actual they need to do to
Quality Gate Meeting results in achieve a successful gate.
approval to proceed. Everyone can help in
delivering the gate. There
are no surprises that can
impact the current and
downstream test teams.
Hold a Post Test Phase Execution A document is available
Review Meeting and produce a report that details the activities
What did we learn of the findings. that worked well, the
during this phase of things that need to be
testing? looked at and improved,
the problems
encountered and how we
dealt with them.

9. Review and Approval

Either the Product owner or the project leader should be responsible for validating and
approving all test results.
 The functional administrators of the subsystem should sign off on integration test and
Unit test results.
Note: Subsystems may include, Front-end, Back-end subsystem (API)
 The end-users and their authorized representative(s) should validate and sign off on the
User Acceptance Test results and production validation.

ACC Test Strategy Document