1 puntos por kyo3553 7 시간 전 | 1 comentarios | Compartir por WhatsApp

Hola. Estoy desarrollando QAMap, una CLI local que lee el contexto de los cambios en un PR y diseña el QA necesario.

El cuello de botella que sentí en equipos de producto no era tanto escribir código de pruebas, sino volver a decidir en cada PR “qué debe demostrar este cambio”. Al principio analizaba el diff y la estructura del proyecto para recomendar borradores de E2E con Playwright y Maestro, pero en la práctica se quedaba en cosas que el desarrollador ya sabía y en pruebas simples de pantalla de éxito.

Por eso cambié el objetivo. En lugar de entender perfectamente todos los dominios, organiza la intención del cambio y el flujo funcional con base en los commits y el diff, y propone QA que probablemente falte entre casos normales, fallos, límites y transiciones de estado. Para los juicios difíciles de asegurar, también muestra la justificación y el nivel de confianza.

En última instancia, el objetivo es una herramienta local de QA que, cuando se registra un PR, encuentre las funciones afectadas, configure los E2E necesarios junto con mocks y fixtures, los ejecute de forma segura y deje evidencia de la verificación. Actualmente está en v0.4.0, y se está actualizando para acercarse a ese objetivo verificando uno por uno los casos en los que falla en repositorios reales.

Todavía está en una etapa temprana, así que puede interpretar mal o pasar por alto escenarios importantes. Lo que más necesito ahora son casos reales de fallo. Si QAMap juzga algo de forma equivocada o propone pruebas que no se pueden usar, agradeceré que me lo digan con toda confianza.

1 comentarios

 
jeongjin0 1 시간 전

Está buena la dirección de proponer localmente, con base en el diff, incluso los límites y las transiciones de estado. Si se pudiera ver mejor de qué diff hunk o archivo sale la evidencia para cada escenario, creo que sería más fácil filtrar los falsos positivos al revisar.