DEV Community: Faris Kurnia

Bug Deduplication with AI (Node.js + OpenRouter)

Faris Kurnia — Wed, 24 Sep 2025 16:52:04 +0000

QA teams often face the same problem: duplicate bug reports. Different test cases fail, but the root cause is actually the same. To cut through the noise, I built a Proof of Concept (PoC) using Node.js + OpenRouter AI to automatically cluster similar failures and suggest root causes

Why?

🚫 Less time wasted triaging duplicate bugs
🔍 Faster root cause analysis
🤖 AI-driven clustering & summarization

Tech Stack

Node.js
ml-kmeans for clustering
OpenRouter API (chat model for semantic grouping)

Setup
Install dependencies:
npm install node-fetch ml-kmeans dotenv
Add your API key to .env:
OPENROUTER_API_KEY=your_api_key_here CHAT_MODEL=google/gemma-3n-e2b-it:free

Example snippet:

Example result:

Takeaways

✅ AI reduces noise from duplicate bugs
✅ Saves QA team time during triage
✅ Extensible to native CI/CD logs

This is just a PoC, but it shows how AI can make QA workflows smarter. What do you think of this POC? If you have any suggestions, leave a comment

Or if you want to read the full version, you can click here

3 Groundbreaking AI Developer Tools That Are Redefining Software Automation

Faris Kurnia — Sun, 27 Jul 2025 06:24:52 +0000

In today's fast-paced software development landscape, the demand for speed, quality, and automation has never been higher. From intelligent task planning to autonomous testing and DevOps orchestration, a new wave of AI-powered tools is emerging, designed not just to assist developers and QA engineers, but to act on their behalf

In this article, we explore 5 cutting-edge platforms and open-source projects that leverage Large Language Models (LLMs) and agentic frameworks to automate workflows, generate tests, debug code, and manage infrastructure, pushing the boundaries of what's possible with AI in software engineering

In the full article there are 5 tools discussed as well as feedback from the community, here is the link for medium members

Plandex - The AI Task Planner for DevOps Automation
GitHub: plandex-ai/plandex
Type: Open Source, with 14k stars 💥

Overview:
Plandex is an open-source agentic framework built for intelligent task planning and execution. It enables the creation of AI agents capable of understanding task chains and running them independently using LLM

AnyAny.js - CLI Framework for AI Agents
GitHub: modalqa/anyany.js
Type: Open Source

Overview:
AnyAny.js is a prompt-driven CLI framework for building AI agents that can run commands, test flows, and read documentation contextually through a terminal interface

CodeOps AI - Your DevOps Copilot
Website: https://getcodeops.ai
Type: Commercial

Overview:
CodeOps is a DevOps AI assistant that allows teams to operate and observe CI/CD pipelines, analyze logs, and manage infrastructure via natural language prompts

🎯 Final Thoughts: AI Agents Are the New DevOps & QA Superpower
These 3 tools represent a growing shift in how developers and testers can delegate repetitive or complex tasks to autonomous AI systems. Whether you're building custom test flows, managing infrastructure, or debugging large applications, these tools can:

Increase productivity
Reduce errors
Accelerate release cycles
Enhance quality through deeper analysis

As the AI-agent ecosystem continues to mature, teams that embrace and experiment with these tools will gain a competitive edge in both innovation and delivery speed

In the full article there are 5 tools discussed as well as feedback from the community, here is the link for medium members

QA Assistant Agent with Runner H: Validate Bug Priority from Google Sheets and Send Report via Email

Faris Kurnia — Mon, 09 Jun 2025 04:29:58 +0000

This is a submission for the Runner H "AI Agent Prompting" Challenge

What I Built

I built a simple yet impactful AI QA Assistant Agent using Runner H that automatically:

Accesses a shared Google Sheet containing bug reports
Analyzes whether each bug description aligns with its assigned priority
Detects any mismatch or inconsistency
Summarizes the findings
Sends the result directly via email to the QA team

This helps streamline manual QA validation work and promotes consistent prioritization of issues.

Demo

👉 https://www.loom.com/share/49b5aa14077e4d3da64f8ed1638fb20d?sid=76f974ce-198d-4c99-9e18-95974c75e2a1

How I Used Runner H

Here's how I set up the workflow:

Tools Integrated:
- Google Sheets (read access)
- Gmail (send report)

Prompt Used:

Access the Google Sheet at this link: https://docs.google.com/spreadsheets/d/1astlWEzpP1FiLOqhojPuMC_Kzdto8zv7Hybr7Oa098A/edit?usp=sharing 
Analyze each row to check if the 'Bug Description' matches the assigned 'Priority' level appropriately. 
For any mismatch or inconsistency, list the row number, bug description, and explanation. 
Then, email the result to testing.niar@gmail.com with the subject: 'Bug-Priority Validation Report'.

Logic Flow (MermaidJS):

flowchart TD
    A[Access Google Sheet] --> B[For Each Row: Analyze Bug Description vs Priority]
    B --> C{Is Priority Appropriate?}
    C -- No --> D[Add to Report]
    C -- Yes --> E[Skip to Next Row]
    D --> B
    E --> B
    B -->|All Rows Processed| F[Summarize Result]
    F --> G[Send Email with Result]

Execution: Runner H parsed and ran the above logic in one smooth flow with no custom code needed.

Use Case & Impact

🎯 Use Case:

This agent is designed for QA Teams, Project Managers, or Bug Triage Committees who want to validate if developers/testers are assigning appropriate priority levels based on bug severity.

🚀 Impact:

Saves time from manually reviewing each entry
Ensures alignment in issue prioritization
Prevents "low priority critical bugs" slipping through

👤 Who Benefits:

QA Engineers
Product Owners
Agile teams who manage large-scale issue tracking via shared spreadsheets

Please like, comment, or share if you find this useful! ❤️

Thanks to Runner H and DEV for enabling makers to build no-code intelligent automation this easily!

Exploring QA Opportunities & Challenges When Transition from HTMX to HMPL.js

Faris Kurnia — Sat, 07 Jun 2025 07:39:03 +0000

This article was inspired by Anthony Max discussing replacing HTMX with a new module called HMPL.js. From a QA Engineer’s POV, there are many important lessons to be learned from this approach

What is HTMX and HMPL.js?
HTMX is a frontend library that allows page manipulation via HTML attributes such as “hx-post”, “hx-target”, and “hx-swap” without writing explicit JavaScript. HTMX uses “XMLHttpRequest” as the main engine behind its AJAX

HMPL.js is a modern alternative. It uses a fetch API based approach and pure JavaScript to handle requests and responses, as well as templating using {{ … }} placeholders.

And, after reading the article by Anthony Max, I started to see the approach in a different light — especially as a QA Engineer. There are a lot of interesting things that come up, both in terms of technical challenges and quality improvement opportunities, that are worth discussing briefly but deep!

Opportunities For QA Engineer
More Control Over Testing, HMPL uses fetch explicitly, so QA can easily:

Install mocks/interceptors (using MSW or Playwright)
Test payloads and headers with precision
Simulate error handling

JavaScript Skill Development, The transition to HMPL provides an opportunity to deepen understanding of:

Async/await
Fetch API & Error Handling
Dynamic DOM Manipulation

Early Involvement in Technical Decisions, As a QA, you can be more active in:

Determining testable structures
Developing testing strategies based on full control on the JS side
Providing input early on in frontend architecture development

Challenges to Anticipate
Lack of Documentation & Community, HMPL is still relatively new. This means:

Few references
Minimal best practices
Must do a lot of self-exploration

Testing Complexity Increases, As logic moves from HTML to JavaScript, QA needs to:

Read JS code to trace request flow
Understand response structure & target DOM
Anticipate race conditions and async rendering

Hidden Bug Risk, Error handling can be overlooked

Dynamic DOM structures are prone to selector breaks
API response schemas need explicit validation

Based on my opinion above and after exploring some additional references, I realized that the case studies that are worth considering are as follows:

Sample case
Context: A frontend team replaced HTML with HMPL on a user registration form to be more flexible in processing data and handling custom validation

Technical Changes

HTMX originally used hx-post=”/register” directly in the form tag.
In HMPL, the form is rebuilt with a JavaScript “onSubmit” handler, which uses fetch(‘/register’, { method: ‘POST’, body: JSON.stringify(…) })

Challenge

Need to rewrite test script that previously only checked for automatic DOM changes from HTML
Need to validate fetch payload contents manually
Create new test scenario for 422 error response and its handling in JavaScript

Solution

Using Mock Service Worker (MSW) to fake server response, if needed
Adding assertion to JSON request structure
Simulating error response and validating error message rendering in form

Result

QA gets full visibility into a form’s data flow
Test automation becomes more resilient to markup changes
Developers and QA work more closely together because the flow is no longer “hidden” in HTML attributes

Conclusion

HMPL offers high flexibility for development teams, but demands more technical and adaptive QA. So if you are a QA Engineer who wants to level up and be relevant in modern architecture, understanding the transition from HTMX to HMPL is a very valuable opportunity and worth trying or learning more deeply

CSS Doom and Modern QA Challenges: Learning Visual Regression and DOM-less Testing from Extreme Experiments

Faris Kurnia — Thu, 15 May 2025 04:23:25 +0000

Imagine the classic game DOOM running in the browser, not with JavaScript, WebGL, or Canvas, but with just a single "div" and CSS. It sounds impossible, but that's exactly what GrahamTheDev managed to create in his article "DOOM…rendered using a single div and CSS"

As a QA Engineer, I see this experimental project not only as frontend art, but also as an experimental ground to test modern testing capabilities, especially in the era of an increasingly visual, dynamic, and unconventional web

👀 What is CSS Doom?

Simply put, it's an implementation of DOOM (yes, that 1993 FPS game) using:

A single HTML element
Thousands of lines of CSS to create the 3D visual effects
No JavaScript or Canvas

An extreme experiment, which actually presents new challenges for QA

🔍 QA Engineer Perspective: What Can We Test?

Visual Regression Testing

In projects where all logic is wrapped in visual styles, Visual Regression becomes the main focus:

Tools like Percy, BackstopJS, or Playwright can compare rendering between versions
Experiment: run snapshots in different resolutions, browsers, or even OSes to see rendering "glitches"

Performance Testing: CSS Rendering Stress
This game pushes the browser's capabilities hard to:

Render multiple CSS layers
Handle parallax, gradient, and transform effects

🛠️ Use:

Chrome DevTools (FPS meter, Performance tab)
Lighthouse: especially the Layout Shift & Main Thread Work sections

Automation Testing in an "Empty" DOM
Since only 1

No regular DOM structure
Can't use data-testid, role, or conventional selectors

🤔 "This could be a case study: "How do automation tools like Cypress or Playwright adapt when the DOM is so minimal?"

Accessibility Testing (A11y)
HTML without semantic structure = a nightmare for screen reader users
Tools that can be used:

Axe DevTools
Lighthouse Accessibility Audit
NVDA / VoiceOver

💡 From here, we can discuss the importance of HTML semantics for accessibility QA, even in experimental projects

AI-Based Visual Comparison
As a modern QA, we can try:

Use AI models like Applitools Eyes or OpenCV to compare "rendered" frames between versions
Analysis: Can the AI visually distinguish different levels or maps?

🎓 Educational & Experimental Opportunities
I see this as an opportunity for founders to host bootcamps in groups or privately:

🎥 Create a mini-workshop: "Visual Regression 101 via CSS Doom" and, add Comparative study: Rendering vs Performance - CSS-only vs Canvas vs WebGL

Conclusion

CSS Doom is not just about CSS genius, but also about:
How QA can continue to evolve following extreme frontend experiments
As QA Engineers, we can learn a lot:

The importance of visual regression in the era of dynamic UI
The limitations of automation when DOM is unconventional
The importance of accessibility even in experiments
The opportunity to use AI to detect visual differences

Closing

Frontend experiments like this will continue to emerge. The challenge is: can our QA approach be adaptive, creative, and even exploratory?

If you're a QA who wants to explore beyond just clicking and verifying, a project like CSS Doom can be a fun, yet challenging, starting point