Introduction
A test strategy involves identifying the scope of quality that the team will need to call an implementation or solution successful. The test strategy covers how the team will approach the program or project(s), the level of depth they will go to so that they achieve a quality product, and the exit criteria necessary for a successful delivery.
This help content is designed to assist you in creating the test strategy. You can use this template to create your version for your project or initiative.
Every project or initiative should have a test strategy and should include plans for not only testing but ensuring quality of the work and data being transmitted.
As we proceed through the article, we will use the term “program” to describe either a program, project, initiative or work effort. The term is used interchangeably.
Scope of Change
In the Seagen environment, the work done in Global IT can be visualized by using the chart below. Your test strategy should cover each of the sections in the Digital Transformation Architecture.
Many of the work efforts done via the program teams will focus on the areas that add the most value. There are many ways to identify value. Value can come in some of the following ways.
Process optimization
Cost optimization
Faster time to delivery
Simplified solution landscape
Reduced operating cost
Interoperability
Reusability
Outlined below are the core areas that are affected the most by a test strategy. This strategy determines the level at which the team works to so as to provide quality.
Engineering
Engineering includes any of the following activities. If the work your team is doing falls into one of these areas you need to determine the level of engineering testing.
Any code development checked into a repository
Any integration using data
Any transfer of data
Any code that manipulates or transforms data
The following will be tested in the engineering efforts.
Code Deploys and Pipelines
Functionality
Automation
Feature Delivery
Load and Performance
Applications and Solutions
The following will be tested in Applications and Solutions.
Unit
Usability
Features
Integration Scenarios Workflows (CSV)
API and Service Orientation
Data and Information Management
User Acceptance
DevOps Automation Testing
Data and Information Quality Management
Identify which types of tests you will use to test the Data and Information Management practices of the program, project or solution.
Data Classification
Backup and Recovery
Encryption
Boundaries
Referential Integrity with relational data
Data Evolution through Transactions
Field Changes for Regression Testing
Fuzzy Testing
Baseline Testing
Baseline testing refers to the nominal state a service, application or environment runs in. The baseline is context driven in that some tests run maximum number of concurrent users whereas others run to a specific SLA. When testing your various services, choose the appropriate baseline and then document that. When the deploy runs, the baseline will run and provide statistics on whether or not the change that was made was impactful. If it was is it within tolerances? If not, the change needs to be adjusted or refined.
Infrastructure and Hardware Testing
DeltaV - how is it tested and configured?
Reference existing test plans and compliance documentation for ongoing operations
BAS / PAS (new model) meet with implementation and design teams to understand their config and setup as well as ongoing practices (look at this from a data continuity perspective)
network connectivity
backup testing
firewall configuration (rerouting)
transactions/events (timing)
failover
antivirus
logging and telemetry
handoff responsibility
HyperV, Dell Storage, Dell Servers, Blades, Network Gear
3rd party engagements from vendors
threats, hacking, ransom
frameworks, code staleness
patch management
data quality
airgapped system
multihoming avoidance
DMZ