As almost half of 2026 has passed, I'm stepping into a new chapter of my journey: mentoring. Mentorship has always been on my mind, but I never really had the opportunity to take it up before. This...

New collection

 Looking at my 1year of GitHub graph, I see periods of consistency, periods of silence, and a lot of starting again. Which is probably the most honest representation of my learning journey so ...

Traceability in software testing is the ability to connect and follow relationships between requirements, risks, test cases, defects, and code changes across the software lifecycle. It helps teams reason systematically about failures, gaps, and change, while providing visibility into what has been tested, what may be affected, and where uncertainty still exists. Traceability operates in multiple directions. Forward traceability follows requirements through implementation and testing to ensure expected behaviours are covered. Backward traceability links defects or test failures back to their originating requirements or risks. Horizontal traceability connects related artefacts at the same level, such as overlapping coverage across features, workflows, or services. Effective traceability requires all three perspectives, not just the vertical mapping many teams default to. A traceability link confirms that a test exists for a requirement not that the test is meaningful, well-designed, or passing. Traceability provides visibility into coverage relationships, but it does not guarantee coverage quality. The two should not be conflated. Connecting tests to explicit risks supports prioritisation, regression selection, release exposure assessment, and failure triage. Without risk linkage, traceability can incorrectly imply that all requirements carry equal importance, which rarely reflects the reality of systems under pressure. Traceability also strengthens impact analysis. When requirements change or defects are discovered, traceability links help teams identify which tests need review, which areas carry regression risk, and where coverage gaps may have been introduced. This becomes particularly valuable in large or distributed systems where the consequences of a change are not immediately obvious. Used well, traceability is a decision-making tool that helps teams test smarter, communicate coverage clearly, and respond to change with confidence rather than guesswork.

Load testing is a type of performance testing that evaluates how a system behaves under a defined workload, typically modelled on expected or peak production usage. Its primary goal is to determine whether the system can respond reliably, consistently, and within pre-defined performance thresholds when multiple users interact with it concurrently. Those thresholds expressed as Service Level Objectives or explicit acceptance criteria, must be agreed before the test runs. Without them, a load test produces observations, not pass or fail signals. Unlike stress testing, which pushes a system beyond its limits to identify breaking points, load testing operates within anticipated demand boundaries. It answers a focused question: does the system perform acceptably under the conditions it is expected to handle? A load test is only as meaningful as its workload model. This includes not just concurrent users or requests per second, but also the shape of the load: whether traffic ramps gradually, remains steady, or follows realistic production patterns such as a diurnal curve. Representative user journeys, think times, and session durations all matter. Wherever possible, the workload model should be derived from production traffic data or analytics rather than assumptions, this is one of the most consequential decisions in the entire exercise. Load testing measures response time, throughput, error rate, and resource utilisation across application, database, and infrastructure layers. It helps identify bottlenecks, slow dependencies, memory pressure, and scalability limitations. However, load tests reveal symptoms, not root causes. Diagnosing failures requires supporting telemetry metrics, distributed traces, logs, and profiling data collected during execution. The reliability of results also depends heavily on environment fidelity. If the test environment differs significantly from production in topology, configuration, data volume, or external dependencies, the conclusions may be misleading regardless of how well the test itself was designed. Effective load testing examines how performance degrades as demand increases, how the system recovers when load subsides, and whether user experience remains within acceptable bounds throughout. These behaviours matter as much as whether the system survives the load itself. Where tests involve sustained load over extended periods to observe memory growth or gradual degradation, this moves into the adjacent practice of soak testing, which carries its own distinct objectives. Load testing sits at the intersection of development, operations, and architecture. In organisations where ownership is unclear, it tends to be performed poorly or not at all. Treating it as a shared responsibilityoften under a performance engineering or site reliability function,, significantly improves both the quality of the tests and the organisational response to findings. In mature engineering organisations, load testing is not a one-time pre-release activity. It becomes part of continuous delivery pipelines and ongoing system health monitoring as systems change and user behaviour shifts.