swebok

Use black-box testing to validate behavior against requirements and white-box testing to measure code coverage. They are complementary because they start from different information sources and detect different classes of faults, so combine both rather than relying on one.

Start with a modular monolith when you have a small team, a single deploy, and one database. Choose microservices only when real forces demand it, such as independent deployment cadence, fault isolation, or separate scaling needs, since distributed transactions and observability costs are significant.

Match the technique to available information: expert judgment with no historical base, analogy with a comparable project, bottom-up decomposition when you can break down the work, and parametric models with a solid historical database. For high-impact decisions, use multiple techniques and look for convergence.

Refactor when external behavior must stay the same but internal structure is problematic. Quantify the debt in terms of current cost, potential savings, and urgency, and treat it as a financial investment decision rather than an aesthetic judgment about messy code.

Yes, it includes curated reference files covering all five SOLID principles with smell tests and over-application costs, plus all 23 GoF design patterns with one-line triggers for choosing between them. These complement the SWEBOK chapters with more practical depth.

A passing test suite only demonstrates the absence of failures in those specific cases, never the absence of faults in general, per Dijkstra's limit. Communicate the coverage and adequacy criteria achieved instead of claiming zero defects.