This is just a rough template for test drivers to get started with identifying gaps, working out squad-specific plans. Test drivers can customize this template based on their iteration plans and priorities. So, please feel free to update and improve it.
Module/Microservice: output-manager
Testing | Required? | Framework ready? | Critical paths identified? | Critical paths covered? | Quality Gates | Action Points | Comments |
|---|---|---|---|---|---|---|---|
Unit | Yes | Yes | Yes | Yes | coverage is 84.2%, duplicated lines less than 1% code smells, etc | N/A | |
Component | Yes | Yes | Yes | No | N/A | write cases the cover critical paths identified | |
Contract | No | No | No | No | N/A | 1, get contract test framework ready; 2, identify critical paths; 3, create epic tickets in Jira backlog to keep track of test cases for critical paths 4, write test cases to cover the critical paths | We have the REST client library there, so we don’t think contract test is necessary; we also have the Kafka library there |
Smoke | Yes | No | No | No | N/A | ||
Performance | Yes | No | No | No | QPS/TPS? Response time(Percentile) |
Critical path: with any micro services/common modules, there are parts that are more critical if they break; other parts are less critical, but nice to have. Anything that inhibits a necessary core functionality is considered a critical path. This doesn’t mean that we don’t need to write test cases for non-critical paths, rather it means that critical paths have higher priorities in terms of bug fix, task prioritization and automation testing. Identifying critical paths is the point for you to get started with figuring out the current status and identifying the gaps and plan for next step.
How to identify critical paths?
1), is it a business requirement?
2), does it have a high volume of usage?
3), will it disrupt the common workflows if it breaks?
4), will a customer leave us if it breaks for an hour?
5), if it breaks, do we need a rollback?
6), would the business owner challenge us if it breaks?
If your answer is Yes to one of them, just mark it as critical.
Create squad-specific automation testing epics to keep track of different types of testings. When you create an automation testing ticket, please make sure that you associate it with a specific epic. Recommended epic format is given below:
Automation{squad_name}{testing_type}
For example,
AutomationLoanUnitTest
AutomationCustomerComponentTest
AutomationAccountContractTest
AutomationCardSmokeTest
AutomationTransactionPerformanceTest
Quality Gate
For unit and component tests, it would be code coverage, duplication rate, etc. For performance test, it would be Queries Per Second/Transactions Per Second, and response time percentile(e.g: 95% of the requested have been handled within 500 milliseconds)
Test Directory Layout
ctest/
for contract test cases
itest/
for integration test cases
ptest/
for performance test cases
stest/
for regression/smoke/user journey test cases
test/
for unit and component test cases
We expect each chapter member to present this at the weekly SyncUp meetings. We wanna know where we are, what’s next and also share questions/ideas/tools.