Precise and Streamlined Testing Practices for B2B Services: Case Studies and Code Review

Introduction – While the industry often relies on diff tools and coverage metrics for precise testing, the author shares a more streamlined B2B testing methodology that combines deep code review with targeted test cases to uncover hidden issues and improve quality.

Scenario 1: Upload Spreadsheet Validation

Requirement: Operations need to upload multiple data rows via a spreadsheet template, validating headers and fields.

Problems identified:

Many validation cases for each field (missing, wrong format, etc.).

Need a faster, more efficient testing approach.

Precise testing steps:

Locate the upload handling code.

During code review discover misuse of startWith (should be equals for full match) and a faulty numeric regex ^-?\d+$ .

Submit a bug, fix the code, and verify the corrected behavior.

Validate numeric-only uploads using the same regex and length check.

Results:

Successful upload of correct data.

Failure for non‑numeric format and length‑exceeding rows.

Remaining cases verified through code review.

Overall test passed.

Discovered two hidden bugs (incorrect startWith usage and regex issue) and saved time by reducing ten upload‑exception cases.

Scenario 2: Retrieving Available Rules

Requirement: Match rules based on priority and activation status.

Problem: Complex rule set with many states and priorities makes exhaustive testing difficult.

Precise testing steps:

Understand that rule priority is obtained via a descending‑order SQL on priority and id .

Fetch the first record (get0) from the result set.

Insert three rules into the database, craft data that hits one rule, and verify that the sorting returns the expected rule.

Optionally run a second SQL check to confirm the same rule is selected.

Takeaway: Combining code insight with targeted SQL‑driven cases ensures comprehensive coverage without excessive test volume.

Scenario 3: Rule‑Group Matching Verification

Requirement: Each rule group contains up to four sub‑rules that must all match for the group to be hit.

Problem: Exhaustively testing all combinations (Cartesian product) is time‑consuming.

Reduction approach:

Identify that rule‑group testing can focus on group‑level hits, while sub‑rule correctness is verified separately.

Review code to confirm implementation matches design; the selected cases cover the essential logic.

Construct data that hits the rule group, then data that deliberately fails sub‑rules, and verify results via logs.

Conclusion: Splitting complex business logic into isolated tests clarifies the testing strategy and avoids redundant cases.

Scenario 4: Similar Rule Conditions

Requirement: All sub‑rules within a rule group must match; each sub‑rule’s matching logic needs verification.

Problem: Designing a full Cartesian‑product suite is impractical.

Reduction strategy:

Recognize that the underlying implementation is a multi‑condition SQL query.

Ensure both the most specific and partial parameter sets return correct results; reduce cases to a few representative queries.

Validate via hand‑written SQL; example code:

During review a bug was found: when using a broader condition the query limited to a single row (ORDER BY id DESC LIMIT 1) omitted additional matching rows. The fix was to remove the limit and aggregate with SUM.

Overall Summary

By analyzing technical designs and actual implementations, test cases can be categorized and reduced, leveraging code review to replace many manual validations. Focusing on field values, matching parameters, query conditions, and calculation formulas uncovers hidden defects, saves effort, and increases confidence in test outcomes.