LO
Tester de software / ingeniero de QA — tareas, una a una
La unidad de análisis es la tarea, no el nombre del puesto. Cada una de las siguientes lleva su dirección, si el juicio se apoya en evidencia o en una inferencia de la plataforma, el razonamiento y lo que no establece.
Todas las tareas de esta página#
Pruebas de regresión manuales
Automatizándose≈ Inferencia de la plataformaPinchar por los mismos flujos en cada versión para confirmar que no se ha roto nada de lo que funcionaba.
La regresión con guion ya era automatizable; lo que cambió es que los agentes pueden ahora operar una interfaz real a partir de una descripción en lenguaje llano y reparar sus propios guiones cuando la interfaz cambia, lo que eliminó la carga de mantenimiento que mantenía a los equipos en pruebas manuales. Es el mayor bloque de horas de la mayoría de los puestos de QA y se está yendo rápido.
Es explícitamente el mayor bloque de horas de la mayoría de los puestos de QA. Nada de lo que queda es lo bastante grande como para absorber a la gente cuya semana llenaba.
Escribir casos de prueba y automatización
Automatizándose≈ Inferencia de la plataformaConvertir requisitos en casos, y casos en guiones que corren en la canalización.
Generar pruebas a partir de una especificación o del propio código es uno de los usos más eficaces de las herramientas de generación de código, y una cobertura que habría costado un sprint aparece ahora en una tarde. Las pruebas generadas son superficiales igual que lo es el código generado — confirman lo que el código hace y no lo que debería hacer — y por eso la tarea siguiente importa más.
Las pruebas generadas confirman lo que el código hace y no lo que debería hacer. Los equipos que miden cobertura en vez de defectos concluirán que esta tarea está resuelta, y es un problema de medición que perjudica a los testers.
Pruebas exploratorias y adversarias
Sigue llevándola una persona✓ Con evidenciaProbar lo que nadie especificó: la entrada rara, la condición de carrera, el usuario que hace el paso 3 antes que el 2.
Las pruebas generadas derivan de la especificación o del código, así que comparten sus puntos ciegos. Encontrar el fallo que nadie imaginó exige un modelo de cómo se comportan mal los usuarios y los sistemas reales, construido con experiencia sobre este producto y este dominio. Las herramientas ensanchan la búsqueda; la hipótesis sobre dónde mirar sigue siendo humana, y ahí están los fallos caros.
La hipótesis sobre dónde mirar se construye habiendo hecho el trabajo de regresión que está desapareciendo. Esta tarea está protegida por una experiencia que la cantera ya no produce.
Decidir si sale
Sigue llevándola una persona✓ Con evidenciaSopesar los fallos abiertos, el riesgo, el plazo y el negocio, y decir sí o no.
Es una decisión de la que se responde y con consecuencias organizativas, y los equipos no han mostrado ninguna gana de delegarla. Los cuadros de mando resumen el estado; la decisión sobre qué nivel de riesgo aguanta esta versión, esta base de clientes y esta semana la toma una persona en cuyo criterio confía el equipo.
En muchos equipos esta decisión es de un responsable de ingeniería, no de un tester. Donde es así, protegerla protege el puesto de otra persona.
Probar sistemas con un modelo dentro
Tarea nueva≈ Inferencia de la plataformaEvaluar software cuya salida no es determinista — construir conjuntos de evaluación, cazar regresiones de comportamiento, probar salidas dañinas.
La mayoría de los productos nuevos tienen un modelo en el circuito y no pueden probarse afirmando una salida fija. Diseñar evaluaciones, las instrucciones adversarias y la regresión de comportamiento son una disciplina nueva con pocos practicantes, y la mentalidad de QA — dar por supuesto que está roto y averiguar cómo — se transfiere directamente.
Que haya pocos practicantes es una afirmación sobre el ahora. La disciplina es tan joven que su tamaño final se desconoce, y puede acabar dentro de los equipos de modelo en vez de en QA.