TestStrategy-QA

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 20

Insignia Consultancy Solutions

1|Page
Insignia Consultancy Solutions

Amendment History:
Summary of changes in test strategy document:

Version Date Amendment History


Draft 09-Feb-2024

Reviewers:
This document must be reviewed by the following:

Name Signature Title / Responsibility Date Version

Approvals:
This document must be approved by the following:

Name Signature Title / Responsibility Date Version

Glossary of Terms:
List any terms used in this document.

Term Acronym Definition

2|Page
Insignia Consultancy Solutions

Table of Contents

1. Introduction………………………………………………………………………………….4
1.1 Objectives………………………………………………………………………………4
1.2 Scope……………………………………………………………………………………4
2. Types of Testing………………………………………………………………………….…5
2.1 Functionality Testing…………………………………………………………………..5
2.2 Non-Functionality Testing…………………………………………………………….6
3. Testing Overview……………………………………………………………………………7
3.1 Test Life Cycle………………………………………………………………………….7
3.2 Requirement Analysis…………………………………………………………………7
3.3 Test Planning…………………………………………………………………………..8
3.4 Testcase Design……………………………………………………………………….8
3.5 Test Environment Setup………………………………………………………………9
3.6 Test Execution………………………………………………………………………….9
3.7 Test Closure……………………………………………………………………………10
4. Testing Tools and Technology…………………………………………………………....10
5. Process of End-to-end Testing…………………………………………………………...11
5.1 TDD (Test Driven Development) ……………………………………………… …...11
5.2 BDD (Behaviour Driven Development) ……………………………………………..12

6.Security Testing Strategy…………………………………………………………………15


7.Defect Management………………………………………………………………………….15
7.1 Defect Severity………………………………………………………………………...15
7.2 Defect Reporting………………………………………………………………………15
8.Roles and Responsibility of each Team member…………………………………………16
9.Test Environment……………………………………………………………………………..17
10.Release Control……………………………………………………………………………..17
11.Risk Mitigation……………………………………………………………………………....18

12.Review and Approval…………………………………………………………………….18


13.Backup and Recovery Plan………………………………………………………………..19
14.Frameworks……………………………………………………………………………….....19
15.Benefits…………………………………………………………………………………….....20

16.Summary…………………………………………………………………………………….20

3|Page
Insignia Consultancy Solutions

1. Introduction
Test strategy is a high-level plan consisting of principles that guide the overall software
testing process. It is an approach to verify and validate the projects to the maximum extent.
The important part of test strategy document is to explain how the risks are mitigated, which
test cases are performed in the different test phases, and how the responsibility has been
distributed for testing.

1.1 Objectives
Test Strategy is a set of guidelines that explains test design and determines how testing
needs to be done. It provides a structured approach to the entire QA team, guiding them
toward achieving testing objectives in the most efficient way. It defines the testing approach,
scope, and objectives, clarifies roles, responsibilities, and addresses potential risks and
contingencies. By providing clear guidelines and standards for testing activities, the
document aims to facilitate effective communication, collaboration, and decision-making
among project stakeholders. Ultimately, it ensures that testing efforts are aligned with project
goals, requirements, and industry best practices, leading to the successful delivery of a high-
quality product.

1.2 Scope
It determines the testing tasks and responsibilities, along with their respective timelines.
Identify the individuals responsible for approving, reviewing, and utilizing the test strategy
document. The scope outlined in the testing strategy document encompasses a
comprehensive range of testing activities to ensure thorough evaluation of the product. Key
points include:

Functional Testing: It is a type of software testing that verifies the functionality of a software
system or application. It focuses on ensuring that the system behaves according to the
specified functional requirements and meets the intended business. For example, testing
core functionality of Flipkart is checking user can able to place the order or not.

Non-Functional Testing: It is a type of testing used to evaluate a software application’s


performance, usability, dependability, and other non-functional characteristics. It is intended
to test a system’s readiness according to non-functional criteria that functional testing never
considers. For example, using performance testing is a type of non-functional testing that lets
you check the performance of an application under heavy traffic or user load.

Local Configuration Testing: Validation of the application's behavior under different local
configurations to ensure consistent performance across environments. For e.g. VPN setup,
API Execution

4|Page
Insignia Consultancy Solutions

IT Health Security Check: Conducting penetration testing and adhering to security


guidelines to identify and mitigate potential security vulnerabilities. E.g. Checking SSL
certificate

By encompassing these testing types, the scope ensures a thorough evaluation of the
product's functionality, usability, performance, security, and compatibility, thereby enhancing
its overall quality and reliability.

2. Types of Testing
2.1 Functional Testing

1. Unit Testing: Software verification and validation method in which a programmer


tests if individual units of source code are fit for use. It is usually conducted by the
development team.

1.1 Boundary Value Testing: Software testing technique in which tests are
designed to include representatives of boundary values. It is performed by the
QA testing teams.

2. Smoke Testing: Testing technique which examines all the basic components of a
software system to ensure that they work properly. Typically, smoke testing is
conducted by the testing team, immediately after a software build is made.

3. Integration Testing: The phase in software testing in which individual software


modules are combined and tested as a group. It is usually conducted by testing
teams.

4. Regression Testing: Regression Testing is a type of testing in the software


development cycle that runs after every change to ensure that the change
introduces no unintended breaks. Regression testing addresses a common issue
that developers face — the emergence of old bugs with the introduction of new
changes.

5. Sanity Testing: Testing technique which determines if a new software version is


performing well enough to accept it for a major testing effort. It is performed by
the testing teams.

6. System Testing: The process of testing an integrated hardware and software


system to verify that the system meets its specified requirements. It is conducted
by the testing teams in both development and target environment.
5|Page
Insignia Consultancy Solutions

6.1 Exploratory Testing: Black box testing technique performed without


planning and documentation. It is usually performed by manual testers.

6.2 Equivalence Partitioning Testing: Software testing technique that


divides the input data of a software unit into partitions of data from which test
cases can be derived. It is usually performed by the QA teams.

7. Acceptance Testing: It is a formal testing conducted to determine whether or not


a system satisfies its acceptance criteria and to enable the customer to determine
whether or not to accept the system. It is usually performed by the customer.

8. Security Testing: A process to determine that an information system protects


data and maintains functionality as intended. It can be performed by testing teams
or by specialized security-testing companies.

8.1 Penetration Testing: Testing method which evaluates the security of a


computer system or network by simulating an attack from a malicious source.
Usually, they are conducted by specialized penetration testing
companies.

2.2 Non - Functional Testing

1. Performance Testing: Functional testing conducted to evaluate the compliance of a


system or component with specified performance requirements. It is usually
conducted by the performance engineer.

1.1 Load Testing: Testing technique that puts demand on a system or device and
measures its response. It is usually conducted by the performance engineers.

1.2 Stress Testing: Testing technique which evaluates a system or component at or


beyond the limits of its specified requirements. It is usually conducted by the
performance engineer.

2. Agile Testing: Software testing practice that follows the principles of the agile
manifesto, emphasizing testing from the perspective of customers who will utilize the
system. It is usually performed by the QA teams.

3. Ad-hoc Testing: Testing performed without planning and documentation – the tester
tries to ‘break’ the system by randomly trying the system’s functionality. It is
performed by the testing team.
6|Page
Insignia Consultancy Solutions

4. API Testing: Testing technique similar to Unit Testing in that it targets the code level.
API Testing differs from Unit Testing in that it is typically a QA task and not a
developer task.

 Return value based on input condition: it is relatively easy to test, as input


can be defined, and results can be authenticated
 Does not return anything: When there is no return value, a behavior of API
on the system to be checked
 Trigger some other API/event/interrupt: If an output of an API triggers some
event or interrupt, then those events and interrupt listeners should be tracked
 Update data structure: Updating data structure will have some outcome or
effect on the system, and that should be authenticated
 Modify certain resources: If API call modifies some resources, then it should
be validated by accessing respective resources.

5. Automated Testing: Testing technique that uses Automation Testing tools to control
the environment set-up, test execution and results reporting. It is performed by a
computer and is used inside the testing teams.

6. Error-Handling Testing: Software testing type which determines the ability of the
system to properly process erroneous transactions. It is usually performed by the
testing teams.

7. End-to-end Testing: Similar to system testing, involves testing of a complete


application environment in a situation that mimics real-world use, such as interacting
with a database, using network communications, or interacting with other hardware,
applications, or systems if appropriate. It is performed by QA teams.

8. GUI software Testing: The process of testing a product that uses a graphical user
interface, to ensure it meets its written specifications. This is normally done by the
testing teams.

9. Database Testing: It is a type of software testing that checks the schema, tables,
triggers, etc. of the Database under test. It also checks data integrity and consistency.
It may involve creating complex queries to load/stress test the Database and check
its responsiveness.

7|Page
Insignia Consultancy Solutions

10. Globalization Testing: Testing method that checks proper functionality of the
product with any of the culture/locale settings using every type of international input
possible. It is performed by the testing team.

SonarQube

It collects and analyzes source code, and provides reports for the code quality of your
project. It combines static and dynamic analysis tools and enables quality to be
measured continually over time. Everything from minor styling choices, to design
errors are inspected and evaluated by SonarQube. This provides users with a rich
searchable history of the code to analyze where the code is messing up and
determine whether or not it is styling issues, code defeats, code duplication, lack of
test coverage, or excessively complex code. The software will analyze source code
from different aspects and drills down the code layer by layer, moving module level
down to the class level, with each level producing metric values and statistics that
should reveal problematic areas in the source code that needs improvement.

3. Testing Overview

3.1 Test Life Cycle


It is a systematic approach to testing a software application to ensure that it meets the
requirements and is free of defects. It is a process that follows a series of steps or phases,
and each phase has specific objectives and deliverables. The software testing life cycle
(STLC) is used to ensure that the software is of high quality, reliable, and meets the needs
of the end-users. Below all topics are in-depth details of STLC

3.2 Requirement Analysis


Requirements analysis is a fundamental aspect of ensuring the successful delivery of high-
quality software products. It involves meticulously examining project requirements to gain a
thorough understanding of the desired outcomes and functionalities.

During requirements analysis, QA professionals meticulously review project documentation,


including business requirements, functional specifications, user stories, and acceptance
criteria. They seek clarity on the project scope, objectives, and constraints, identifying
potential ambiguities, inconsistencies, and gaps in requirements.

3.3 Test planning


Test planning is a crucial phase in the testing process where the overall testing strategy and
approach are defined to ensure the successful execution of testing activities. In this phase,
QA professionals collaborate with stakeholders to establish clear objectives, scope,
timelines, and resources for testing.

8|Page
Insignia Consultancy Solutions

Project-specific Considerations: The selection of methodologies, tools, and techniques


may vary based on the company's preferences, industry standards, and project-specific
requirements. Some companies may have preferred tools and established processes, while
others may adopt a more flexible approach to accommodate changing project needs.

3.4 Test Case Design

The first step in test case design is a thorough understanding of project requirements. QA
professionals collaborate closely with stakeholders, including business analysts, product
owners, and developers, to gain clarity on the desired functionalities and features of the
software. They review project documentation, such as requirement documents, user stories,
and design specifications, to identify testable scenarios and acceptance criteria.

Identifying Test Scenarios: Based on the requirements analysis, QA professionals identify


various test scenarios representing different user interactions and system behaviors. Test
scenarios encompass both positive and negative test cases, covering typical user workflows
as well as edge cases and exceptional conditions. Each test scenario is designed to validate
a specific aspect of the software's functionality or behavior, ensuring comprehensive test
coverage.

Creating Test Cases: Once test scenarios are identified, QA professionals translate them
into detailed test cases. Test cases outline the steps to be executed, including preconditions,
test inputs, expected outcomes, and post conditions. They also include information on test
data, test environment setup, and any dependencies or assumptions. Test cases are
typically documented in a test case management tool or spreadsheet for easy reference and
execution.

Ensuring Test Coverage: During test case design, QA professionals strive to achieve
maximum test coverage by addressing all aspects of the software's functionality, including
boundary conditions, error handling, and system integrations. They prioritize test cases
based on the criticality of features, risks, and business priorities to optimize testing efforts
and resources.

Review and Validation: Once test cases are created, they undergo review and validation to
ensure accuracy, completeness, and relevance. QA professionals collaborate with team
members, including peers and subject matter experts, to review test cases for clarity,
correctness, and alignment with requirements. Any identified issues or discrepancies are
addressed promptly to maintain the quality of the test cases.

Documentation and Maintenance: Finally, test cases are documented in a test repository
along with relevant metadata, such as test case ID, description, priority, and status. Test
cases are regularly updated and maintained to reflect changes in requirements,
functionalities, or system behavior. QA professionals continuously refine and enhance test

9|Page
Insignia Consultancy Solutions

cases to adapt to evolving project needs and ensure effective test coverage throughout the
software development lifecycle.

In summary, test case design is a systematic and iterative process that involves translating
requirements into detailed test cases to validate the software's behavior. By following best
practices in test case design, QA professionals ensure comprehensive test coverage and
contribute to the delivery of high-quality software products

3.5 Test Environment set up

The test environment decides the conditions on which software is tested. This is
independent activity and can be started along with test case development. In this process,
the testing team is not involved. either the developer or the customer creates the testing
environment.
3.6 Test Execution
After the test case development and test environment setup test execution phase gets
started. In this phase testing team starts executing test cases based on prepared test
cases in the earlier step.

 Defect logging: Any defects or issues that are found during test execution are
logged in a defect tracking system, along with details such as the severity,
priority, and description of the issue.
 Test data preparation: During form fill, table data add, credentials and in many
places test data is required. It should be prepared and loaded into the separate
system and can be used in test execution
 Test result analysis: The results of the test execution are analysed to
determine the software’s performance and identify any defects or issues.
 Defect retesting: Once developer has fixed the defects then during again
process of test execution it should be retested to ensure that they have been
fixed correctly.

10 | P a g e
Insignia Consultancy Solutions

 Test Reporting: Test results are documented and reported to the relevant
stakeholders.

3.7 Test Closure


Test closure is the final stage of the software testing. Where all testing-related activities are
completed and documented. The main objective of the test closure stage is to ensure that
the software is ready for release. The testing team should have a clear understanding of
the software’s quality and reliability, and any defects or issues that were identified during
testing should have been resolved. The test closure stage also includes documenting the
testing process and any lessons learned so that they can be used to improve future testing
processes

 Test summary report: A report is created that summarizes the overall testing
process, including the number of test cases executed, the number of defects
found, and the overall pass/fail rate.
 Defect tracking: All defects that were identified during testing are tracked and
managed until they are resolved.
 Test environment clean-up: The test environment is cleaned up, and all test
data and test artifacts are archived.
 Test closure report: A report is created that documents all the testing-related
activities that took place, including the testing objectives, scope, schedule, and
resources used.
 Knowledge transfer: Knowledge about the software and testing process is
shared with the rest of the team and any stakeholders who may need to
maintain or support the software in the future.
 Feedback and improvements: Feedback from the testing process is collected
and used to improve future testing processes

4. Testing Tools and Technology


Testing Type Tools and Technologies

Unit Testing JUnit, TestNG

Integration Testing Postman, Rest Assured, Playwright

System Testing Playwright, TestNG, BDD

Acceptance Testing Playwright, BDD

Regression Testing Playwright, TestNG, JUnit, BDD

Performance Testing Apache JMeter, LoadRunner

Security Testing SonarQube

Database Testing SQL

11 | P a g e
Insignia Consultancy Solutions

Testing Type Tools and Technologies

API Testing Postman, Rest Assured

Mobile Testing Appium, XCTest, UI Automator

API Testing Tools and Technologies:

Tool/Technology Description

A comprehensive API testing tool with features for testing, debugging, and
Postman monitoring APIs.

A Java library for testing RESTful APIs, offering a fluent API and easy
RestAssured integration with testing frameworks.

Mobile Testing Tools and Technologies:

Tool/Technology Description

An open-source automation tool for testing mobile, native, and hybrid apps
Appium across different platforms.

Apple's native testing framework for writing unit, performance, and UI tests
XCTest for iOS and macOS apps.

A testing framework provided by Google for writing UI tests to interact with


UI Automator Android app components.

These tools and technologies are widely used in the industry for various testing purposes,
catering to different aspects of software development and ensuring the quality and reliability
of applications across different platforms and environments.

5. Process of end-to-end Testing


5.1. TDD (Test Driven Development)
To begin with TDD (Test Driven Development) approach originates from the Agile process
by understanding the requirements or specifications of the features.

12 | P a g e
Insignia Consultancy Solutions

Steps that need to follow to test the application are as:

1. Write Test cases: Test case prepared by testing team before developing the functionality.
2. Run the Test: Execute the test suite. This step ensures that the test is valid and actually
tests the behaviour intended.
3. Write the code: Implement the functionality or behaviour in the simplest way possible and
writing the minimal code required to make the test pass.
4. Run all tests: Once the code is written, run the entire test suite, including all previously
written tests as well as the new one. This ensures that the new code didn't break any
existing functionality.
5. Refactor code: Refactor the code if necessary to improve its design, readability, or
performance. Refactoring should not change the external behaviour of the code; the tests
should still pass after refactoring.
6. Repeat: Repeat the process for each new functionality or behaviour that needs to be
implemented.
By following these steps, developers can ensure that their code is thoroughly tested and that
new features or changes don't introduce unintended side effects or regressions.

5.2. BDD (Behaviour Driven Development)


To Automate scenarios by using “BDD approach” based on prepared Test cases by following
“Agile Process” that extends the principles of Test-Driven Development (TDD) by
encouraging collaboration among developers, QA engineers.

13 | P a g e
Insignia Consultancy Solutions

In BDD, whatever we write must go into Given-When-Then steps called Gherkin language.
1. Formulation of Scenarios: Scenarios are typically written in a structured format using
“Given-When-Then (GWT)” syntax to describe the initial context, the action being
performed, and the expected outcomes.
2. Automation of Scenarios: Once scenarios are defined, the testing team automates them
using BDD testing frameworks such as Cucumber BDD.
3. Implementation of Step Definitions:
 For each scenario, the corresponding step definitions are implemented in code.
 Step definitions are written in “Java programming” language and map the plain-text
scenario steps to executable code that interacts with the system under test.
4. Execution of Scenarios:
 The automated scenarios are executed against the system under test to verify that
it behaves as expected.
 Scenarios can be executed locally during development and as part of continuous
integration (CI) pipelines to ensure that new changes don't introduce regressions.
Tool, we use for execution of scenarios – Jenkins.
5. Review & Feedback:
 After execution, the team reviews the test results and identifies any failures or issues.
 Failed scenarios are investigated, and necessary fixes or adjustments are made to
the implementation or the scenarios themselves.
Review & feedback tool: JIRA.

6. Continuous Refinement:
 The scenarios and step definitions are continuously refined and updated as the
requirements evolve or new features are added.
 Updated code shared with other testing team so that they can merge with their
code.
Code repo management tool: GIT.
By following this step-by-step workflow, teams can leverage BDD to ensure that software
requirements are clearly defined, understood, and validated through automated tests.

6.Security Testing Strategies


Best Security Testing strategies are important to make an application vulnerable
resistance. Developing secure design and code is the main focus of software developers.
Security checking out must starts from the requirement gathering stage to understand
security requirements. Unlike useful testing that validates what the testers should know to be
true, security testing focuses on unknown factors and assessments the infinite ways that an
14 | P a g e
Insignia Consultancy Solutions

application can be broken.


To ensure an application secure, security testers need to do the following Tests:
 Vulnerability Scanning: The entire system is tested for vulnerabilities or loopholes
or any suspicious activities. This scan can define and classify the entire system
weakness.
 Penetration testing: To check how an application responds during an attack,
penetration test is used. It mimics an attack and finds entry point into the application
for the real attacks. After the penetration testing, there will be clear idea of application
behaviour in the event of an attack.
 Security Risk Assessment: Assessing the risk identified and ranking them based on
their severity level, followed by taking the right mitigation methods. And security
check for service access points, inter-network, and intra-network access, and data
protection is conducted at this level.
 Ethical Hacking: An authorised practise of detecting vulnerabilities in a system or
application or data or infrastructure by mimicking the manner of actual hackers.
 Security Scanning: To enhance the security periodic scanning needs to be done for
networks weakness. Testers should check for major vulnerabilities which are then
studied, analysed, and fixed.
 Access Control Testing: Access control testing ensures only authorised users who
meets the security policies is permitted to access the application. It is to confirm that
the security policies implemented.

7. Defect management

Based on the severity levels of defects reported, issues are being resolved in defect
management. By Considering the cost, risk, and benefits associated with each defect to
decide whether it should be fixed or withheld.

6.1 Defect Severity

 Critical Defect: The Defect affects critical functionality or causes critical system
crashes or data loss.
 High Defect: The defect affects some major areas of functionality but not in whole.
 Medium Defect: The defect affects minor functionality and non-critical data.
 Low Defect: The defect does not affect functionality or data. It does not have any
impact on productivity and efficiency.
6.2 Defect Reporting

 Identification: During the test execution phase, QA professionals actively monitor


the software for defects, anomalies, and inconsistencies. When a test case fails or
deviates from expected results, they immediately identify and document the defect.

15 | P a g e
Insignia Consultancy Solutions

 Documentation: QA professionals meticulously document defects found during


testing. The defect report includes detailed descriptions of the issue, steps to
reproduce, screenshots, video links or logs if applicable, and the severity level
assigned based on the impact on the system or business.

 Classification: Defects are classified based on their severity, priority, and impact on
the software's functionality. Common severity levels include critical, major, minor, and
cosmetic, while priority levels range from high to low based on the urgency of
resolution.

 Reporting: Once documented and classified, defect reports are submitted to the
defect tracking system or bug repository. This centralized repository serves as a
record of all reported defects, providing visibility to stakeholders and facilitating
tracking and management of defect resolution efforts.

By following a systematic defect reporting process, QA team can effectively manage and
resolve issues identified during testing, ultimately delivering high-quality software products
that meet user expectations and business requirements.

8.Roles and Responsibilities of Each Team Member


The testing team members have specific jobs and responsibilities. For example - the
software testing roles of software developers can be to focus on planning and designing
tests. At the same time, the software tester’s role and responsibilities can be to execute
those tests. So each person contributes uniquely to the overall quality of the software.
 QA team has main responsibility to check entire software with all the testing types and
highlight the issues to developers, designers, database engineers, cloud engineers and
Project manager and stakeholders.

16 | P a g e
Insignia Consultancy Solutions

9. Test Environment
The test environment setup should outline information about the number of environments
and the required setup for each environment. For example, one test environment for the
functional test team and another for the UAT team. Define the number of users supported in
each environment, access roles for each user, software and hardware requirements like
operating system, memory, free disk space, number of systems, etc.

The common Test Environments are listed below:

 Development: It is used by developers for preliminary testing of their code. Mainly to


test newly developed features before sending it to the QA team.
 Test Environments: Used by QA to perform different testing activities include
manual and automation testing
 Staging/Pre-Production Environment: This environment provides the actual user
live system. It gives the same configuration as the production environment. Staging
environment ensures code works without any major issues and bugs.

10.Release Control
Release Control is used to make sure that test execution and release management
strategies are established systematically. This contains information related to the
successive updates of the product. Release control ensures the software meets the
necessary standards before it is delivered to the User. Release Control must include the
history of Test Processes, Teams responsible for each case, Main components,
Modification done, the first error encountered, and the measures taken to overcome.

The Main features of Release Control are:

 Release Criteria: Defining specific conditions like performance benchmarks to be


met before release.

 Planning: Creating a Detailed plan for the steps involved in the Releasing process
such as deployment schedules, testing activities, and backup procedures in case of
errors.

 Testing and Validation: Conducting detailed testing and validation before


releasing to avoid issues during release time. This includes functional testing,
regression testing, performance testing, security testing, and UAT.

 Deployment and Rollback: According to the release plan, deploying the product at
the scheduled time in coordination with the development team.

17 | P a g e
Insignia Consultancy Solutions

11. Risk Mitigation


 Identifying potential risks: The primary purpose of a risk management plan is to
identify potential risks associated with the project. This helps project teams anticipate
potential problems and plan accordingly, reducing the risk of project failure.
 Prioritizing risks: A risk management plan allows project teams to prioritize risks
based on their likelihood and potential impact. This helps teams focus their attention
and resources on the most critical risks, reducing the chances of project failure.
 Improved decision-making: With a risk management plan in place, project
managers can make informed decisions based on the identified risks. They can better
allocate resources and make necessary adjustments to the project plan to avoid
potential pitfalls.
 Mitigating financial impact: Risks in software development can be costly to fix. By
identifying and mitigating risks early in the development process, the financial impact
of these risks can be significantly reduced.
 Ensuring compliance: A risk management plan can also help ensure compliance
with legal and regulatory requirements. By identifying potential risks related to
compliance, project teams can take necessary steps to mitigate these risks and avoid
any legal or regulatory issues.
List the Risk related to the Test and Treatment plans for each.

ID Risk Probability Impact Mitigation


Statement
High
Medium
Low

12.Review and Approval


Before executing the Test Plan based on the Test Strategy Document, it should be reviewed
and approved by the project Stakeholders. Ensures it covers all the main aspects of the
project and confirms whether it is aligns with project Requirements and Objectives. During
the review, stakeholders may find risk factors like the lack of crucial stages of test planning.
Based on the feedback received, the document should be revised and updated in a way that
solves the identified issues. Once the document is revised and updated then it goes for
approval from the stakeholders. The approved strategy will communicate with all the team
members involved in the Projects to make sure that everybody is aware.

18 | P a g e
Insignia Consultancy Solutions

13.Back Up and Recovery Plan


Software testing team should have backup and recovery plan before actual project starts.
Team has to defined a role to each team member for clear instructions on How to take
backup, who will take backup, when to take a backup, what to include in backup and when to
restore the backup.

 Backup Procedures: Set a regular backup schedule for frequently doing tasks or for
Most Important Data. Depending upon the requirements backups can be chosen
either full or Differential or Incremental.
 Backup Storage: Decide where to store backups, and ensure that a secure and
reliable medium is chosen. Cloud-based storage solutions give more protection, since
the chance for physical damage or loss of data is less.
 Backup Validation: Validating the backups by performing periodic test to restore
data and ensure data restored successfully.
 Documentation: Documenting the detailed procedures involved in the recovery of
test environment and backup data in the event of failures and data loss can be useful
for further reference.
 Regular review and Testing: According to the business requirements and change in
test environments periodically update backup and recovery plans. perform recovery
testing often.

14. Frameworks used in Testing Environment


Automation Testing Framework:
Framework Description

Widely used automation tool for web application testing, supporting various
Playwright programming languages.

Testing framework for Java, providing advanced features for test


TestNG management, parallel execution, and reporting.

15. Benefits of Documentation and Reporting


19 | P a g e
Insignia Consultancy Solutions

In an environment that prioritizes short release cycle, it is critical for all stakeholders to
understand what is necessary to get the job done. If the QA team doesn’t communicate their
vision for quality testing through a test strategy, there will be gaps in communication before
the project ever get started. By following a unified Test Strategy Document, organization can
avoid such difficulties. Major Benefits of a good documentation is listed below.
 Transparency: Comprehensive documentation and reporting ensure transparency and
visibility into testing activities, enabling stakeholders to track progress and make informed
decisions.
 Traceability: Well-documented testing artifacts facilitate traceability between requirements,
test cases, test results, and defects, ensuring alignment with project objectives.
 Communication: Regular test reports facilitate effective communication between QA teams,
development teams, project managers, and other stakeholders, fostering collaboration and
alignment of efforts.
 Decision Making: Insights provided through documentation and reporting enable
stakeholders to make informed decisions regarding software quality, release readiness, and
risk mitigation strategies.

16.Summary
This document contains the unified test Strategy for the QA Team. The Following Information
has been covered in this document.
 Definition of Test Strategy.
 Levels of Testing and Tools and Environment Used for Testing.
 Software Testing Life Cycle
 Method of Defect Management, Risk Mitigation and Backup Plans.
 Communication and Responsibilities
 Review and Approval Methods.
 Benefits of Test Strategy

20 | P a g e

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy