QA Tech Argentina · Proceso de trabajo
Proceso de trabajo QA: del relevamiento al informe final
Un proceso ordenado evita que las pruebas dependan de la memoria de una persona. Acá describimos cómo trabajamos paso a paso, para que sepas qué esperar, qué te vamos a pedir y qué documento recibís en cada etapa.
Sirve si nos contratás o si querés copiar el esquema para tu equipo interno · Sprints cortos · Horario de Buenos Aires
Relevamiento
Accesos, flujos y vacíos detectados temprano.
Plan escrito
Alcance, riesgo y criterios de salida validados.
Ejecución
Ciclos cortos con reporte en tu tablero.
Informe
Foto honesta para decidir la liberación.
Cómo leer esta página
Un esquema que podés contratar o copiar
Este proceso QA está pensado para equipos argentinos que liberan cada semana, trabajan remoto y no tienen tiempo para burocracia. Cada etapa termina con algo concreto: un acceso verificado, un plan validado, un defecto bien cargado o un informe que ayuda a decidir. Nada queda en charlas sueltas.
Si trabajás con sprints cortos, el esquema se versiona por sprint. El plan, los casos y el informe viven en tus herramientas, Docs, Notion, Confluence, Jira o Trello, para que el conocimiento quede en tu empresa aunque cambien las personas. Y si preferís hacerlo con tu equipo interno, podés usar estas mismas etapas como lista de control.
Qué recibís en cada etapa
- Conversación inicialOrientación honesta
- RelevamientoMapa de flujos
- Plan y casosDocs versionados
- CierreInforme en español
Todo queda escrito. Si alguien se suma a mitad del release, puede entender qué se probó sin preguntar por chat.
Inicio del proceso QA
Antes de probar, entender el producto
Conversación inicial
Una videollamada de 30 minutos, sin tecnicismos de más
Todo empieza con una videollamada en horario de Buenos Aires. Nos contás qué producto tenés, qué te preocupa y qué fecha tenés en mente. Preguntamos stack, ambientes disponibles y quién responde dudas funcionales. Con eso vemos si podemos ayudar y qué modalidad conviene.
Si no somos adecuados para tu caso, te lo decimos en esa misma llamada y te orientamos sobre qué buscar en otro proveedor. Preferimos perder un proyecto antes que entrar a un contexto donde no vamos a aportar. La mayoría de las veces salís con una idea más clara del alcance aunque no sigamos.
Relevamiento y accesos
Recorremos tu producto como lo usaría un cliente
Si avanzamos, pedimos accesos a staging o desarrollo, usuarios de prueba con distintos roles, datos de ejemplo y especificaciones si existen. Firmamos NDA si lo necesitás. Revisamos los flujos principales por nuestra cuenta: cómo se registra un usuario, cómo compra, cómo se factura.
Detectamos vacíos de información temprano, cuando todavía son baratos de corregir. Esta etapa suele tomar uno a dos días hábiles si los accesos llegan completos. Si algo falta, te pasamos una lista corta y precisa en lugar de frenar todo en silencio.
- · Usuarios de prueba por rol, con permisos reales y datos locales realistas.
- · Ambiente estable separado de desarrollo, para no pisar deploys.
- · Una persona de referencia que responda dudas funcionales en el día.
Plan de calidad y diseño de casos
Lo escrito antes de ejecutar evita discusiones después
Redactamos un plan corto y operativo. Alcance incluido y excluido, prioridades por riesgo, dispositivos y navegadores a cubrir, datos necesarios y criterios para dar por terminado el ciclo. Lo validás vos antes de ejecutar, así no hay sorpresas sobre qué se probó y qué no.
Qué define el plan de pruebas
El plan queda en tu herramienta, Docs, Notion o Confluence, y sirve para futuros ciclos. Para equipos con releases semanales, se versiona por sprint. Incluye qué queda fuera con la misma claridad que lo incluido, porque decir qué no se prueba también es parte del trabajo.
Metodología de testing ágil en la práctica
Priorizamos por riesgo: pagos, facturación y accesos primero. Cubrimos combinaciones de dispositivos y navegadores que usan tus clientes en Argentina, incluidas conexiones lentas. Los criterios de salida dicen cuándo parar, aunque queden ideas sin probar.
Casos para lo crítico, checklists para el resto
A partir del plan, armamos casos detallados para lo crítico y checklists de una línea para lo secundario. Cada caso tiene resultado esperado explícito y precondiciones marcadas, con datos locales realistas. Si un flujo maneja dinero o datos fiscales, va detallado. Si es simple, una línea alcanza.
Validación temprana con producto
Compartimos el avance para que producto valide supuestos antes de gastar horas de ejecución. Es más barato corregir un malentendido en un documento que re-ejecutar un ciclo entero. No documentamos de más: el nivel de detalle sigue al riesgo, no a una plantilla rígida.
Ejecución en ciclos cortos
Primero humo, después lo nuevo, después regresión
Ejecutamos en ciclos de uno a tres días según el tamaño. Primero una pasada de humo para ver si el ambiente está probabe. Después lo nuevo del sprint y después regresión de lo importante. Reportamos defectos a medida que aparecen, no todo al final, para que desarrollo corrija en paralelo.
Coordinamos horarios para no pisar deploys. Si el ambiente se cae o cambia a mitad del ciclo, lo registramos y reprogramamos lo afectado con transparencia. Vas a saber siempre qué se ejecutó, qué quedó pendiente y por qué.
Hacer una consulta sobre tu releaseOrden de cada ciclo
Prueba de humo del ambiente
Verificamos accesos, datos y flujos base antes de gastar horas.
Funcionalidad nueva del sprint
Casos y checklists del plan, con evidencia por cada defecto.
Regresión corta de lo importante
Pagos, login, facturación y caminos que no pueden romperse.
Reporte de defectos en tu tablero
Defectos que desarrollo puede corregir sin adivinar
Cargamos cada defecto en Jira, Trello o la herramienta que uses, con título específico, pasos para reproducir, evidencia y entorno exacto. Separamos severidad de prioridad y sugerimos prioridad según impacto en usuarios argentinos: pagos, facturación y accesibilidad con conexiones lentas pesan más.
Buscamos duplicados antes de cargar para no llenar tu tablero de ruido. Cuando un error es intermitente, sumamos videos cortos que muestran el contexto. Respondemos dudas de desarrollo en el día hábil, para que la daily avance con el tablero ordenado.
Retest y regresión
Nada se cierra sin evidencia en el ambiente acordado
Cuando nos avisan correcciones, verificamos cada defecto en la versión indicada y hacemos regresión corta alrededor del cambio para detectar efectos colaterales. Si un arreglo rompe otra cosa, lo vinculamos para que se vea la cadena.
Este ida y vuelta se repite hasta cumplir los criterios de salida o hasta agotar el tiempo pactado, lo que se informa con claridad. No damos por cerrado lo que no pudimos reproducir.
Etapas de pruebas de software, en orden
Relevamiento, plan, casos, ejecución, reporte, retest e informe. Saltarse una etapa no ahorra tiempo: lo mueve al momento más caro, cuando el error ya llegó a producción.
Ver cómo cubrimos pruebas funcionales
Cada informe queda como evidencia para auditorías internas o clientes.
Informe final con riesgos
No es un aprobado genérico, es una foto honesta
Cerramos con un informe en español: qué se probó, en qué entornos, cuántos casos pasaron, defectos abiertos por severidad, riesgos para liberar y recomendaciones. Te permite decidir con información: liberar, liberar con limitaciones o esperar.
Incluimos sugerencias para el próximo ciclo, como qué automatizar o qué datos faltaron. El documento te queda como evidencia y como base para comparar releases. Con el tiempo, cada ciclo deja un proceso un poco mejor que el anterior.
Comunicación durante el proyecto
Un hilo por ciclo, una persona de contacto por lado, actualizaciones breves al cierre del día. Reuniones puntuales con agenda. Si surge un bloqueante crítico, ambiente caído o cambio de alcance, lo avisamos en el momento. Trabajamos en horario laboral argentino y respondemos en el día hábil, algo especialmente valorado por software factories con varios clientes.
Después de la entrega
Te quedás con papeles, plantillas y respaldo
Guardamos papeles de trabajo por 90 días para responder dudas sin empezar de cero.
Si algo aparece en producción
Si liberás y aparece un problema ligado a lo probado, lo revisamos sin costo dentro de una ventana acordada para entender qué pasó: si fue un caso no cubierto, un dato distinto o un cambio posterior.
Continuidad por sprint o por release
Podemos dejarte plantillas de plan, casos e informe para que tu equipo los reuse. Si querés continuidad, proponemos esquema por sprint o por release, con alcance ajustado a tu ritmo.
Ver servicios QAPreguntas habituales
Lo que nos preguntan antes de empezar
Si tu duda no está acá, escribinos con el detalle de tu release. Respondemos en horario laboral argentino, de lunes a viernes de 9:00 a 18:00.
¿Qué necesitan de nuestro lado para empezar?
Accesos a un ambiente de prueba estable, usuarios de ejemplo, una persona de referencia y la lista de cambios del release. Con eso alcanza para el primer ciclo.
Si tenés especificaciones, diseños o criterios de aceptación, mejor. Si no hay nada escrito, lo reconstruimos en el relevamiento y lo dejamos documentado para que no se pierda.
¿Se adaptan a nuestra metodología ágil?
Sí. Trabajamos por sprint con ceremonias mínimas y reportes en tu tablero, sin imponer un proceso pesado.
Nos sumamos a tu daily cuando aporta, coordinamos con desarrollo por tu canal y versionamos el plan por sprint para equipos con releases semanales.
¿Querés más detalle sobre tiempos y alcance?
Cada producto pide un recorte distinto del proceso. Contanos stack, ambiente y fecha objetivo y te proponemos un primer ciclo acotado.
Próximo paso
Contanos tu release y te proponemos un primer ciclo
QA Tech Argentina · Av. Corrientes 1233, Buenos Aires · Lunes a Viernes 9:00–18:00 · [email protected] · +54 11 4326 7890. Escribinos con tu fecha objetivo y te respondemos con una propuesta de trabajo clara.