<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Qa on AI VOID</title><link>https://ai-blog.noorshomelab.dev/tags/qa/</link><description>Recent content in Qa on AI VOID</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 09 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://ai-blog.noorshomelab.dev/tags/qa/index.xml" rel="self" type="application/rss+xml"/><item><title>Method-level Change-proneness: A Better Metric for Black-box Test Suite Minimization: Research Explainer for Builders</title><link>https://ai-blog.noorshomelab.dev/research/method-level-change-proneness-test-minimization/</link><pubDate>Thu, 09 Jul 2026 00:00:00 +0000</pubDate><guid>https://ai-blog.noorshomelab.dev/research/method-level-change-proneness-test-minimization/</guid><description>&lt;h2 id="the-challenge-of-growing-test-suites"&gt;The Challenge of Growing Test Suites&lt;/h2&gt;
&lt;p&gt;As software systems evolve, test suites grow. This growth is a double-edged sword: more tests mean better confidence, but also slower execution, higher infrastructure costs, and increased maintenance overhead. For many engineering teams, running the full test suite for every commit or pull request becomes a bottleneck, especially with large, complex applications. This is where &lt;strong&gt;test suite minimization&lt;/strong&gt; comes in. The goal is to reduce the number of tests in a suite while retaining its effectiveness, primarily its ability to detect faults.&lt;/p&gt;</description></item></channel></rss>