As is shown below, when a new requirement coming, Normally we will do a static check, test design, test preparation, then start a series of checks and test activities…
To Understand Features from PRD
-
To Find the 1st Impression About New Product Features
The PRD is the first impression you have for a new feature. The upcoming test activities will go around this Doc.
-
To Mark Unclear Or Unstable Requirement Design
As early as you can to find unclear requirement design, that will save more cost when it will be found in the later phase.
Also to detect some unstable or risky requirements in the phase of requirement design, then mark down and track for it.
To Start Your Design
-
To Design Your Test Cases
Statically to design test cases may be boring, but a necessary part for you to clear your mind.
-
To Design Your Test Data
Test data may classify to 2 classes:
1st is the pre-preparation data, which is not directly for testing the new feature, but you have to create in advance.
2nd is the real-time data, which are with your test cases move forward they are created at the same time.
-
To Design Your Test Scripts
At the first version publishing the new feature to be tested, may don’t have enough time to develop automation scripts.
So the best is to prepare it as early as you can.
To Start Your Test Preparation
-
To Collect the Environment Info
If related environments are new to the new feature, will need you to collect env info before testing.
-
To Close Watch on The Change of PRD or Development
To track those unstable requirement points, so that to make sure your test preparation works are valid.
-
To Prepare the Basic Frame of Test Script
Don’t need to develop a workable script at this stage. Try to prepare the basic script frame and code.
To Start Your Test
-
To Check the Environment
Often block your testing to start is your environment, to check it fist, and quickly report env issue to related co-workers.
-
To Set the Test Data
Once environments are fine, to quickly set up pre-preparation test data for your subsequent testing.
-
To Run Your Smoke Test Cases
To quickly run given smoke test cases, to find some blocking bugs, and sent them to related co-workers to solve.
-
To Run Your Sanity Test Cases
Once the smoke test passed, you can start to run your sanity test cases for the new feature.
Also, it may fail in some key data chain for passing the new feature, to report it and track until to be fixed.
-
To Run Your System Test Cases
Once your new feature testing finished, you need to continue your system test cases.
If you and related co-works have confirmed some function will not be impacted, you could just quickly run the regression test.
The best way is to gradually accumulate automation test scripts to help you do the system test.
-
To Report Test bugs
To report test bugs will come through the whole test process from product design to test execution
-
To Run Your Regression Test Cases
To let your automation scripts do the test for old function.
To manually do the regression test for the new feature.
-
To Complete Your Test Scripts
CICD also makes sense to test. When the first version for the new feature you don’t enough time to complete test scripts.
You can finish them before the next version. So that all the new feature test cases will be included in your test scripts.