Testing Strategy

This article closes the risk-based testing cycle: how to measure whether your testing portfolio is actually working, when to review it, what to track, and how to rebalance when the evidence says to.

With your risks ranked by exposure, the next question is how to actually address them: which testing types, at which levels, using which techniques, and with what coverage targets. This is where the portfolio gets built, and it's the most detailed part of the process, because the testing landscape is

When it comes to testing, quality assurance professionals, testers, and developers can only agree on two things: One, we should probably test, and two, no one knows how to define each test type and how many of each test we should run. Despite this confusion, there's one idea everyone reaches

This article takes the risk statements from the previous one and turns them into a ranked list you can act on. Each risk gets a score: exposure = likelihood × impact. The result is a prioritized table with traceable rationale, and explicit decisions about what not to invest in. At the end

This post is devoted to identifying and quantifying risks before deciding what to test. That means collecting stakeholder fears, converting them into explicit risk statements, and estimating their impact. The output is a prioritized list of risks, not a test plan. In most of the companies I worked for, testing

A software application typically consists of multiple small modules or components, each responsible for a specific functionality, such as user authentication, data retrieval, or form submission. A defect in one of these modules can render the entire application inoperable.   In this article, I’ll explain component testing, its objectives, types,