DEV Community: Jaren Cudilla

Running k6 on a Locked-Down Windows Machine: What Actually Worked and What the AI Endpoints Showe

Jaren Cudilla — Wed, 24 Jun 2026 05:22:52 +0000

Most k6 guides assume you are on Linux, or at worst on a Mac. They do not cover what happens when your setup is minimal by choice - no WSL, no Docker, and the standard install paths all stall before you get to the first test.

That was the actual situation on a recent retainer engagement. My Windows machine runs lean and I do not have repo access to the codebase I am testing, I am the QA engineer, not the dev. The workaround is not complicated, but nobody documents it clearly. k6 ships as a standalone binary. You download the Windows zip, extract k6.exe into a folder your user account controls, and call it from Git Bash with the full path. That is the entire setup. No installer, no package manager required.

The full breakdown at qajourney.net covers the binary setup, the DevTools recon process, the gzip-js compression wall that kills response inspection on Convex-backed apps, and the actual p95 numbers from three staged test runs against live AI endpoints. Worth reading in full if you are walking into a similar engagement.

What stands out from the actual test data is the latency tiering. Direct Convex queries with no AI in the path returned in the 288ms to 800ms range. Medium AI action calls came in around 3 seconds. The heavy AI generation endpoint, a complex multi-part structured output task, landed at a 26-second p95. That number is not a failure — it reflects the actual workload. The only actionable finding was a UX concern: 26 seconds with no feedback state is a separate problem from whether the backend is performing acceptably.

Custom metrics per endpoint matter here. The default k6 http_req_duration aggregation would bury the difference between a 288ms query and a 26-second AI action call in a single blended number. Defining a Trend metric per endpoint gives you per-tool visibility in the summary output.
One thing the DevTools path cannot tell you on a Convex backend: the response body. Convex uses gzip-js compression on responses, which the browser does not automatically decompress in the DevTools Response tab. You see raw compressed bytes. The request payload is readable and shows function names, which is useful. The responses are not. Know your escalation path before you hit this. For a retainer engagement, asking the AI dev directly for the function list was the right move. Fiddler Classic or mitmproxy are the proxy alternatives if direct access to the dev team is not available.

Zero errors across 105 checks on a single-VU baseline run confirms the backend is healthy before any concurrent testing is attempted. The concurrent stage, 10 to 50 VUs each firing AI action calls, is pending. That test requires coordination with the dev team first because AI endpoints burn compute credits on every call and a sudden spike looks like an attack to monitoring systems if nobody is warned.

Prompt Engineering for QA Engineers: The Four-Element Framework That Actually Works

Jaren Cudilla — Tue, 16 Jun 2026 12:34:52 +0000

QA engineers who are frustrated with AI tools are not using the wrong tool. They are writing the wrong prompt. The model is working exactly as designed. It is completing what they started. If what they started was vague, it completed it plausibly, not accurately.

QAJourney has a solid breakdown of the four-element framework for writing prompts that produce usable output: qajourney.net/prompt-engineering-for-qa-engineers/. The core argument is one QA practitioners should recognize immediately: the same discipline that separates a useful test case from a useless one separates a useful prompt from a useless one.

The framework is role, context, scope, and output format. Not because someone made up a mnemonic. Because those are the four things a model needs to stop filling gaps with assumptions.

Role tells the model what kind of reasoning to apply. "You are a QA engineer testing a payment flow on a mobile-first platform" produces fundamentally different output than the same task without that framing. Context gives the model what it cannot know on its own — acceptance criteria, known edge cases, tech stack constraints, user personas. Without it, the model invents plausible system details that do not match your actual system. Scope draws the boundary. Without scope, the model expands to fill whatever space looks reasonable. Output format eliminates reformatting. If you do not describe the structure, the model picks one. It will rarely match your test management system or your team's templates.

The breakdown also makes a point that engineers who have been using these tools for a while will recognize: prompt quality is bounded by system knowledge. You cannot write context you do not have. If you are new to a feature, learn the feature before you prompt. The model reflects your understanding back. Shallow in, shallow out.

Two practical takeaways worth implementing immediately: treat complex testing scenarios as iterative prompting sessions, not single-shot requests. Start wide, then drill. And build a reusable prompt library. The structure is the asset. Role, context, scope, and output format as a template. System-specific details filled in per engagement. Built once, refined over time, used across every project without starting from zero.

The model changes. The discipline does not.

I Built a One-Person AI QA Agency Using a Skill File and Local LLM

Jaren Cudilla — Mon, 01 Jun 2026 00:22:37 +0000

There is a specific failure mode in AI-assisted QA work that most tooling discussions skip entirely, and it shows up earliest when you are working solo on a real engagement.

Every new chat session is stateless. You paste the ticket, describe the feature, explain your severity logic, set up the context, and by the time the AI is actually useful, you have rebuilt your methodology from scratch for the third time that week. That is not a workflow problem you fix with better prompts. It is an architecture problem, and the fix is a skill file.

QAJourney has a full breakdown of this system at qajourney.net/ai-qa-workflow-for-real-projects, including the actual skill files as free downloads. The short version: a skill file is a context document you load as a system prompt. It carries your test surface tiers, your three-path testing framework, your bug report format, your severity and priority logic, your Playwright conventions, and an explicit definition of what the AI does and does not get to call. Load it once per session. The AI operates inside your methodology from the first message instead of a blank slate.

The local LLM layer solves a different problem. On a freelance or retainer engagement, tickets contain real product logic and real client data. Sending that to a cloud API on every session is a data exposure question whether or not it rises to a compliance issue. Running Ollama locally with the same skill file as system context keeps the engagement data on the machine. For the output quality required on QA tasks, current 7B to 14B models are sufficient. The cost at zero marginal per token makes it infrastructure rather than a service you pay by the session.

The three-role setup in the workflow: engineer as judgment layer, cloud AI loaded with the skill file for complex reasoning and active session output, local LLM for lightweight tasks and client data work. The skill file is the constant across all three.

The part that took time to internalize: AI dev teams already run their own QA layer. Linters on every change, unit tests automatically, agent-generated Playwright scripts before the PR opens. By the time you see a ticket in review, the obvious paths have already been tested. Your work starts where the agent's testing ends: testing what it built against what a real user would expect, not what the spec said to build. Those two things are not the same.

The billing feature case in the post is the clearest illustration. Every acceptance criterion passed. Code was technically correct. No billing history. No indication of recurring charges. A real user hitting that screen for the first time would have no idea what had happened to their money. The agent built what the ticket specified. The ticket did not specify what users need to orient themselves in a billing context. That is not a code problem. It is a product logic problem, and it only surfaces when a human reads the screen with user intent.

That check is not automatable. It is not a coverage gap the skill file closes. The skill file handles the mechanical work so the judgment layer has room to do the work only a human can do. Coverage mapping, test case generation, bug report scaffolding, edge case expansion, Playwright scaffolds: the system handles all of it faster and more consistently than manual. Reading the product as a user reads it: that is still yours.

The practical takeaway if you are running any kind of solo QA operation or retainer engagement: write down your methodology before you try to load it into an AI. The act of writing it makes the judgment layer visible. You will see exactly what travels into the file and exactly what does not, and the gap between those two things is the actual job description.

Full skill files, both full and lite versions, are available as free downloads on the post.

Scribe for QA Testing: The Manual Tester's Codegen Nobody Talks About

Jaren Cudilla — Thu, 30 Apr 2026 17:34:23 +0000

In the daily grind of QA, we often find ourselves overwhelmed by the sheer number of bugs to report and manual tests to document.

It's a tedious process that eats up valuable time we could be spending on more critical tasks.

Enter Scribe, a tool not originally designed for our domain, yet it promises to revolutionize how we approach bug reporting, exploratory sessions, and UAT sign-offs.

Let's delve into why manual testers should embrace this unexpected ally in our quest for efficient testing.

Read the full post at: https://qajourney.net/scribe-for-qa-testing/

Agile Testing is a Lie: You're Doing QA All Wrong

Jaren Cudilla — Mon, 20 Apr 2026 13:45:40 +0000

When it comes to Agile methodologies, one of the most contentious topics is Agile testing. Many teams adopt Agile without properly understanding its implications on Quality Assurance (QA). In reality, Agile testing is often misunderstood as a means to speed up the development process by rapidly testing software applications. However, this approach is fundamentally flawed.

The core principle of Agile is iterative and incremental development, which emphasizes continuous improvement through rapid cycles of planning, execution, and delivery. While fast testing might seem appealing, it's essential to recognize that testing should not be used as a means to bypass the need for thoroughness and quality in software development. The notion that "we'll just test it quickly and move on" is a recipe for disaster, leading to rushed releases, inadequate testing, and ultimately, products that are more prone to errors and bugs.

Moreover, relying solely on automation for testing is also misguided. While automation can be an incredibly valuable tool in the testing arsenal, it's no substitute for human expertise and judgment. There will always be aspects of a product or service that require human input to test thoroughly, such as usability, accessibility, and social implications. Automation can help streamline some testing tasks, but it should not replace the need for rigorous manual testing.

One of the biggest mistakes teams make when implementing Agile is failing to integrate testing into their workflows in a meaningful way. Testing should be an integral part of every development cycle, not something that's tacked on at the end. This means that testers need to be deeply involved in planning and execution, working closely with developers to identify risks and opportunities for improvement.

In reality, Agile teams often struggle with silos between testing and development. Testers are seen as separate from developers, rather than as partners who work together to create high-quality software. However, this approach is short-sighted and ignores the critical role that testers play in ensuring the overall quality of a product or service.

So, what's the solution? To truly integrate testing into Agile workflows, teams need to adopt a more collaborative approach. This means breaking down silos between teams, investing in training for both developers and testers, and establishing clear processes for testing and review. It also requires recognizing that testing is not just about automation or speed, but about creating high-quality software that meets the needs of users.

In conclusion, Agile testing is often misunderstood as a means to speed up development, rather than an opportunity to improve quality. By adopting a more nuanced approach to testing, teams can create software applications that are both efficient and reliable. So, if you're looking to revamp your QA processes or simply want to learn more about the importance of testing in Agile workflows, be sure to check out our original post at https://qajourney.net/agile-testing-is-a-lie-youre-doing-qa-all-wrong/ for a comprehensive guide on how to get it right.

Originally published at QAJourney.net

Creating Test Strategies and Detailed Test Plans: A QA Lead’s Responsibility

Jaren Cudilla — Mon, 20 Apr 2026 12:16:26 +0000

As a Quality Assurance (QA) Lead, creating effective test strategies is not just about writing detailed test plans, but rather about ensuring alignment with development workflows, business goals, and risk-based prioritization. In today's fast-paced software development landscape, QA leads play a critical role in designing adaptive and scalable test strategies that support the overall success of an organization.

A well-crafted test strategy serves as the foundation for a robust testing program, providing a clear direction for testing efforts and helping to ensure that quality is embedded throughout the software development lifecycle. At its core, a test strategy should be risk-based, taking into account the potential risks and vulnerabilities associated with the software being developed. By identifying and prioritizing high-risk areas first, QA leads can focus their testing efforts on the most critical components of the system.

One key aspect of creating an effective test strategy is to align it with business goals and objectives. This involves understanding the organization's overall mission and vision, as well as identifying specific goals and metrics that are relevant to the software development process. By tying testing back to these broader goals, QA leads can demonstrate the value of their efforts and ensure that testing is viewed as a key enabler of business success.

Another essential component of a test strategy is its scalability. As software systems evolve and grow in complexity, so too must the testing program. A scalable test strategy should be able to adapt to changing project requirements and priorities, while also maintaining consistency and quality across all testing activities. This requires ongoing planning, review, and revision of the test strategy to ensure it remains relevant and effective.

In addition to these key considerations, a good test strategy should also be aligned with development workflows and processes. This involves understanding how development teams work, including their workflows, tools, and methodologies, and tailoring testing activities accordingly. By working closely with development teams, QA leads can identify opportunities for collaboration and process improvement, leading to faster time-to-market and higher quality software.

To create an effective test strategy that goes beyond traditional test plans, QA leads must also consider the role of automation in testing. As software systems become increasingly complex, manual testing becomes less practical and more time-consuming. By incorporating automated testing into their strategies, QA leads can significantly reduce testing times while maintaining or improving overall quality.

Finally, a successful test strategy requires ongoing review and refinement to ensure it remains relevant and effective over time. This involves regular assessment of testing metrics, identification of areas for improvement, and updating the test strategy accordingly. By embracing this iterative approach, QA leads can help to ensure that their testing programs remain adaptable, responsive, and aligned with changing business needs.

By following these principles, QA Leads can design adaptive, scalable test strategies that support the overall success of an organization. In a rapidly changing software development landscape, effective test strategies are more critical than ever, providing a competitive edge for those who prioritize quality, efficiency, and collaboration. For more insights on creating effective test strategies, read our original post at https://qajourney.net/creating-test-strategies-and-detailed-test-plans-a-qa-leads-responsibility/.

Originally published at QAJourney.net

QA Tester to QA Lead: Complete Transition Guide

Jaren Cudilla — Fri, 17 Apr 2026 17:14:27 +0000

As a quality assurance (QA) tester, you've spent countless hours testing software applications, identifying bugs, and working closely with development teams to ensure products meet quality standards. But, have you ever thought about taking your career to the next level by becoming a QA lead? If so, this transition can be both exciting and intimidating. In this article, we'll explore what actually changes when moving from QA tester to lead, which skills matter most, and most importantly, how to avoid mistakes that could derail your new role.

One of the biggest differences between being a QA tester and a QA lead is the scope of responsibility. As a QA lead, you're not just focused on testing software applications; you're now responsible for overseeing the entire quality assurance process. This includes managing teams, creating test plans, prioritizing test cases, and working closely with stakeholders to ensure projects meet quality standards. To be successful in this role, you'll need to develop strong leadership skills, including communication, problem-solving, and decision-making abilities.

Technical skills are still essential for a QA lead, but the focus shifts from individual testing to strategic planning and execution. You'll need to stay up-to-date with industry trends, new technologies, and emerging standards in software development. This may involve training on tools like test automation frameworks, continuous integration, or data analytics platforms. As you transition into this role, take the time to learn these new skills and understand how they can enhance your team's quality assurance process.

Another critical aspect of becoming a QA lead is understanding the business context. You'll need to work closely with project managers, product owners, and stakeholders to ensure that testing aligns with project goals and timelines. This requires strong communication and collaboration skills, as well as the ability to understand the business needs and priorities of your organization. As you take on this new role, focus on developing these skills by attending industry events, joining professional organizations, or participating in online forums.

Mistakes can be costly when transitioning from QA tester to lead. One common mistake is trying to replicate your old role without adapting to new responsibilities. For example, if you're used to working independently, becoming a QA lead may require you to take on more people management and team leadership tasks. Don't be afraid to seek guidance from experienced colleagues or mentors who can offer valuable insights and advice.

Another mistake to avoid is overcommitting yourself. As a QA lead, your responsibilities are now much broader, and it's easy to get overwhelmed with new tasks and projects. Take the time to prioritize your work, focus on high-impact activities, and delegate tasks when necessary. Remember, effective leadership involves empowering others to take ownership of their work, which means trusting your team members to do their jobs.

In conclusion, transitioning from QA tester to lead requires a comprehensive approach that goes beyond technical skills alone. By understanding the scope of responsibility, developing key leadership skills, staying up-to-date with industry trends, and avoiding common mistakes, you can successfully navigate this new role. If you're ready to take your career to the next level, start by reading our in-depth guide to becoming a QA lead: https://qajourney.net/qa-tester-to-lead-transition-guide/.

Originally published at QAJourney.net

QA Basics: Essential Tools, Test Plans & Practices

Jaren Cudilla — Fri, 17 Apr 2026 16:57:30 +0000

As a Quality Assurance (QA) professional, having the right tools, test plans, and practices in place is crucial for delivering high-quality software products on time. In today's fast-paced development environment, QA teams face numerous challenges that require specialized knowledge and expertise to overcome.

One of the most essential tools for any QA team is bug tracking software. Bug trackers like JIRA, Trello, or Asana enable teams to manage and prioritize defects, track progress, and assign responsibilities effectively. A well-organized bug tracking system helps QA professionals identify and fix issues quickly, reducing the likelihood of downstream problems and ensuring that bugs are addressed in a timely manner.

Test planning is another critical aspect of QA that sets the stage for successful testing. Effective test planning involves identifying the key functionality, user stories, and acceptance criteria for a software product. It also requires understanding the project's requirements, timelines, and resource constraints. By creating a comprehensive test plan, QA teams can ensure that all aspects of the software are thoroughly tested, reducing the risk of defects and improving overall quality.

Automated testing is another crucial practice in modern QA. Automation tools like Selenium or Appium enable teams to write automated tests that cover specific scenarios, reducing manual testing time and increasing efficiency. By automating repetitive tasks, QA professionals can focus on more complex and high-risk areas of software development, ensuring that defects are caught early and often.

Another essential tool for any QA team is version control systems like Git or SVN. Version control enables teams to track changes made to the codebase, collaborate with colleagues, and manage different branches effectively. By using version control, QA professionals can identify and fix issues quickly, reducing the likelihood of downstream problems and ensuring that changes are rolled back if necessary.

Agile methodologies like Scrum or Kanban also play a critical role in modern QA. These frameworks emphasize iterative development, continuous improvement, and collaboration between teams. By adopting agile practices, QA professionals can work closely with developers, designers, and product managers to ensure that software meets the requirements and expectations of users.

Lastly, good communication and documentation skills are essential for any QA professional. By creating clear and concise test reports, documenting defects and fixes, and communicating with stakeholders effectively, QA teams can ensure that issues are addressed promptly and efficiently. Good communication also helps build trust with colleagues, managers, and customers, which is critical for successful software development.

In conclusion, having the right tools, test plans, and practices in place is crucial for delivering high-quality software products on time. By understanding the essential tools, test planning practices, and habits that actually matter, QA professionals can improve their skills, reduce errors, and increase efficiency. If you're interested in learning more about QA basics, check out our original post at https://qajourney.net/qa-basics-tools-test-plans-practices/.

Originally published at QAJourney.net

Manual vs Automated Testing: When and Why to Use Each Approach

Jaren Cudilla — Wed, 15 Apr 2026 03:44:51 +0000

When it comes to ensuring the quality and reliability of software applications, two approaches have gained prominence in recent years: manual and automated testing. Both methods have their own strengths and weaknesses, and choosing the right one for a project depends on various factors such as budget constraints, development timeline, and specific testing requirements.

Manual testing involves human testers who manually execute tests on software applications to identify defects or bugs. This approach requires skilled testers who can interpret the application's functionality, identify potential issues, and reproduce them. Manual testing is particularly useful when dealing with complex applications that require nuanced understanding of user interactions, such as those involving multiple screens or complex workflows.

However, manual testing has its drawbacks. It can be time-consuming and resource-intensive, requiring large teams of skilled testers to cover all possible test cases. Moreover, it's prone to human error, where a single tester might miss an issue due to fatigue, distraction, or lack of knowledge about the application's functionality. To mitigate these issues, manual testing often relies on heuristic-based methods, such as trial and error, which can lead to inconsistent results.

Automated testing, on the other hand, uses software scripts to execute repetitive tasks that would otherwise be performed manually by testers. This approach can significantly reduce testing time and increase efficiency, particularly when dealing with large applications or complex workflows. Automated testing is ideal for identifying functional defects, such as those related to user input validation, data integrity, and API connectivity.

However, automated testing has its limitations. It requires significant upfront investment in tooling and infrastructure, which can be costly and resource-intensive. Moreover, it may struggle to capture edge cases or exceptional scenarios that are difficult to replicate using software scripts alone.

In reality, both manual and automated testing have their place in the testing landscape. A well-rounded testing strategy typically involves a combination of both approaches, where manual testing is used to validate the results generated by automated testing. This ensures that defects identified through automation are verified through human interpretation, reducing the likelihood of false positives or false negatives.

In addition to the method itself, the type and quantity of test cases also play a critical role in determining when to use manual versus automated testing. For instance, when dealing with complex applications or new features, it's often necessary to rely on manual testing to ensure that all possible scenarios are covered. Conversely, for applications with established functionality and well-understood workflows, automated testing can be sufficient.

In conclusion, the choice between manual and automated testing depends on various factors, including project requirements, budget constraints, and available resources. By understanding the strengths and weaknesses of each approach and selecting the right one for a project, organizations can ensure that their software applications meet the highest standards of quality and reliability. To learn more about the nuances of manual and automated testing, read our comprehensive guide on the subject at https://qajourney.net/manual-vs-automated-testing-when-and-why-to-use-each-approach/.

Originally published at QAJourney.net

Leveraging Negative Traits for QA Excellence

Jaren Cudilla — Tue, 14 Apr 2026 20:27:14 +0000

As the quality assurance (QA) landscape continues to evolve, organizations are looking for innovative ways to enhance their testing capabilities and ensure the delivery of high-quality products. While traditional traits like attention to detail and analytical thinking have long been valued in QA professionals, some unique characteristics often overlooked can actually drive success in this field.

One such trait is hyperfocus - the ability to concentrate intensely on a task for an extended period, without distractions. For QA teams, this means being able to thoroughly review complex test cases, identify issues, and provide detailed reports. However, hyperfocus can also be seen as a potential drawback, as it may lead to burnout if not balanced with self-care and team collaboration. By recognizing the value of hyperfocus in QA, teams can tap into its benefits while mitigating its risks.

Another underappreciated trait is attention to detail - that meticulous quality that distinguishes exceptional QA professionals from those who struggle to meet standards. While often seen as a necessary skill, attention to detail can also be a strength when balanced with other skills, such as creativity and problem-solving. By harnessing the power of attention to detail, teams can ensure that their testing processes are robust and effective.

Analytical thinking is another key trait in QA that's often overlooked. By analyzing complex data sets and identifying patterns, QA professionals can provide actionable insights to development teams, helping them identify and fix issues early on. However, analytical thinking requires a unique blend of technical skills and creative problem-solving abilities - making it an attractive asset for any organization.

So, how can organizations leverage these negative traits to drive QA excellence? The answer lies in team collaboration and strategic planning. By recognizing the strengths and weaknesses of individual team members, teams can develop targeted training programs that enhance their skills and maximize their potential. For example, a hyper-focused team member may benefit from participation in mindfulness workshops or stress management courses, while an attention-to-detail specialist may require additional support to balance their analytical thinking.

To foster collaboration and innovation among QA teams, organizations should also encourage open communication, flexible work arrangements, and regular feedback sessions. By creating a culture of trust and support, teams can tap into the collective strengths of each member and drive excellence in quality assurance.

In addition, embracing a mindset of continuous improvement can help maximize the benefits of negative traits. By recognizing that there's always room for growth and learning, QA professionals can stay motivated and engaged, even as they tackle complex challenges. Moreover, this mindset enables teams to innovate and adapt quickly, staying ahead of the curve in an ever-changing landscape.

In conclusion, unique traits like hyperfocus, attention to detail, and analytical thinking are not weaknesses, but rather key strengths that can drive QA success. By recognizing their value and leveraging them strategically, organizations can build more effective testing processes, foster a culture of collaboration and innovation, and ensure the delivery of high-quality products.

To learn more about how negative traits like hyperfocus, attention to detail, and analytical thinking can be harnessed for QA excellence, read our in-depth post on Leveraging Negative Traits for QA Excellence at https://qajourney.net/leveraging-negative-traits-for-qa-excellence/.

Originally published at QAJourney.net

Understanding QA Testing – Key Concepts & Tools for Success

Jaren Cudilla — Mon, 13 Apr 2026 16:10:34 +0000

Title: Navigating the Labyrinth of Quality Assurance (QA) Testing: Essential Knowledge for Modern Developers and Testers

In the fast-paced world of software development, understanding Quality Assurance (QA) testing is no longer an option but a necessity. QA testing serves as the beacon guiding developers towards building reliable, user-friendly, and high-performing applications. But, like any complex maze, navigating through its labyrinth requires knowledge, skill, and the right tools.

This comprehensive guide, titled "Understanding QA Testing: Key Concepts & Tools for Success," is designed to help you master the art of QA testing and stand out in today's competitive tech landscape. Delve into this treasure trove of information as we explore the fundamental concepts that underpin QA testing, the indispensable tools that make it efficient, and the strategic approaches that ensure success for both developers and testers alike.

Whether you are a seasoned software professional or a novice just starting your journey in tech, this guide will serve as an invaluable resource. From the importance of testing methodologies to the significance of test automation, we cover it all. Discover the crucial role that QA testing plays in fostering application stability, user satisfaction, and overall product quality.

Get ready to level up your skills and take control of your QA testing adventures! Dive deep into our detailed guide on "Understanding the Basics of Quality Assurance (QA) Testing" at https://qajourney.net/understanding-the-basics-of-quality-assurance-qa-testing/ today and join the ranks of experts who are redefining the future of software development. Happy exploring!

Originally published at QAJourney.net

Why QA Fails Without Fragmentation (and How Fragmentation Protects Systems)

Jaren Cudilla — Tue, 27 Jan 2026 05:03:26 +0000

Most system failures don't happen because teams miss details. They happen because teams refuse to break things apart early enough.
QA doesn't exist to "check quality." It exists to contain blast radius. That only works when systems are fragmented on purpose.

Why Monolithic Systems Break

When teams ship features as a single unified block as one epic, one massive PR, one "we'll test it later" delivery, they create systems that can't be reasoned about, can't be isolated when something breaks, and can't be tested meaningfully.
The bigger the unit, the more fragile the system. QA doesn't scale against monoliths. It scales against pieces.

Fragmentation ≠ Technical Debt

Fragmentation gets mislabeled as overhead because people confuse it with bureaucracy.
Fragmentation is smaller tickets, narrower acceptance criteria, isolated functions, testable boundaries, and clear ownership per component.
Technical debt is uncontrolled complexity. Fragmentation is controlled complexity. QA depends on that distinction.

Test Cases Need Fragmentation to Work

A good test case validates one behavior, under one condition, with one expected outcome. That's not laziness that's how causality stays traceable.
Regression suites rot when they grow without structure. Teams eventually rebuild them not to add coverage, but to restore meaning. A fragmented regression suite survives change because each test protects a specific behavior, not a vague promise that "everything still works."

Bad test: "Login button appears after input"
Fragmented test: Valid credentials → authenticated session + dashboard redirect + usable token.

Separately: timeout handling, invalid credentials, locked accounts. One assertion per condition.

That's what survives product evolution.

Fragmentation Makes Debugging Possible

Systems that aren't fragmented force teams to debug by guessing. That's how outages stretch from minutes into days.

Branch-level QA works because behavior is validated before merge. Failures stay close to their source. Cause and effect remain local instead of spreading across the codebase.

When defects appear in production, nobody debugs "the whole application." They trace a request, a module, a function, a condition. Without fragmentation, you're searching the entire codebase. With it, you know exactly which PR introduced the regression because it was tested in isolation before merge.

Testing in Production Fails Without Fragmentation

Testing in production isn't inherently wrong. Testing only in production is.
Production testing works when systems are already fragmented, rollback paths exist, and failure impact is isolated. Without fragmentation, production testing becomes gambling.

Teams who lean on production testing without isolation confuse speed with courage. Feature flags, logs, and metrics become testing tools only when you've already built the boundaries that make failure observable and reversible.

QA's job is to make failure boring, not heroic.

Agile Formalized Fragmentation (Didn't Invent It)

Scrum didn't invent fragmentation.

It formalized it: stories instead of features, tasks instead of stories, acceptance criteria instead of assumptions. Each split reduces uncertainty.

Shift-left testing works because work is broken earlier. When QA receives a PR with its own isolated test environment, they're not testing "the feature" they're validating one change in one context. That PR gets closed or merged based on that specific verdict. The next PR starts fresh. No contamination. No collision.
That's fragmentation enabling speed.

What Happens When Teams Skip Fragmentation

You've seen this:

"QA will test it at the end"
"It works on my machine"
"Let's just merge and see"
"It's probably related to something else"

These aren't symptoms of bad QA. They're symptoms of systems designed without fragmentation. When everything is interconnected, failures become mysteries. When work is fragmented, failures point directly to their source.

How Fragmentation Protects Reality

QA isn't about slowing teams down. It's about forcing reality checks early, when fixes are cheap.
Fragmentation enables meaningful regression testing, targeted automation, predictable releases, and survivable failures.
Without fragmentation, QA becomes a bottleneck or a scapegoat. With it, QA becomes the mechanism that keeps complexity under control while velocity stays high.

Why This Matters More Than Frameworks

Every reliable system you've worked on was fragmented long before QA touched it. Every unstable one tried to stay whole for too long.
That instinct to fragment shows up wherever failure teaches faster than theory. It appears in environments where systems either adapt or collapse long before formal QA roles exist.
QA doesn't demand fragmentation to be difficult. It demands it because reality is unforgiving.

Read the full breakdown at qajourney.net/fragmentation-qa-testing