GitPrime eleva el liderazgo de la ingeniería con datos objetivos. En esta serie de entrevistas, los líderes de ingeniería hablan de cómo construir equipos de alto rendimiento.
Hablamos con Matt Brandt sobre la ingeniería de pruebas y la garantía de calidad (o QA). Matt es un ingeniero de pruebas senior de Mozilla, que trabaja principalmente en tecnologías web, con experiencia tanto en desarrollo de software como en psicología.
Compartió algunas ideas particularmente interesantes sobre cómo tener en cuenta al usuario, cómo construir un plan de pruebas y cuándo empezar a introducir el control de calidad en una organización.
Añadiendo valor a través del QA
Travis: Vamos a empezar con una pregunta clave. ¿Cuál es la diferencia entre el control de calidad y la ingeniería de pruebas?
A decir verdad, creo que las diferencias son insignificantes, si no inexistentes. En el mundo del software, encontrar individuos que sean elocuentes y capaces de examinar críticamente un producto de software requiere un alto nivel de habilidad técnica. Un equipo de prueba añade valor a los productos utilizando una variedad de herramientas y técnicas para evaluar los riesgos asociados con la entrega de un producto a los usuarios.
Nuestro papel es averiguar dónde podemos añadir más valor a un producto en un momento dado de su ciclo de desarrollo. A veces es la prueba manual, otras veces es crear herramientas que ayuden a estresar un sistema de maneras únicas. El punto es que siempre tenemos que buscar cómo podemos añadir valor y encontrar maneras de insertarnos en esas áreas. Nuestro enfoque es reducir y ayudar a identificar y comunicar los riesgos potenciales al equipo.
Travis: ¿Cómo se imagina las formas más fructíferas de añadir valor a través de la garantía de calidad?
Matt: Creo que se reduce a cómo los probadores de software abordan la complejidad del proyecto en el que están trabajando y lo descomponen en áreas manejables dentro de su estrategia de prueba. Es importante separar los sistemas complejos en conjuntos de problemas más pequeños que nos permitan analizar los componentes y cómo contribuyen a una jerarquía de riesgos potenciales.
Por ejemplo, cuando me incorporo a un nuevo proyecto me gusta tomarme el tiempo para entender el dominio comercial y técnico a varios niveles. Entrevistaré a los diferentes productos y partes interesadas para construir una imagen de lo que creen que estamos creando y las áreas de preocupación en las que se centran. Los desarrolladores, los analistas de negocios, los gerentes de producto, etc., todos tienen diferentes puntos de enfoque y preocupaciones cuando se trata de lo que un equipo está creando y lo que constituye el éxito. Se trata de un enfoque holístico para entender qué es el producto; cuáles son los modos de éxito y de fracaso. Esto ayuda a construir un cuadro completo de lo que un equipo de prueba necesita agregar al circuito de retroalimentación que el grupo consume. Específicamente, esta imagen identifica los riesgos e informa sobre lo que vamos a probar y cómo lo vamos a probar.
Cuando hablamos de mitigar los riesgos, es importante entender que el proceso de control de calidad no asegura que un producto nunca falle. En cambio, asegura que un producto falle dentro de los umbrales tolerables.
En otras palabras, el control de calidad es la gestión de riesgos. Ayudamos a identificar las áreas del software en las que los usuarios tolerarán el fracaso y las que no pueden fallar en absoluto. Luego creamos y mantenemos pruebas que proporcionan un circuito de retroalimentación apropiado para el equipo.
Cuando las cosas van mal
Travis: ¿Cómo se determina qué fallos son tolerables y cuáles no?
Me gusta dividir los componentes y características de un proyecto en tres amplios niveles.
El primer nivel involucra áreas que nunca pueden ir a la producción en forma interrumpida. Estas son áreas de funcionalidad que si enviamos a los clientes – ya sea un nuevo error, o simplemente resolvimos un problema mal para empezar – hemos fallado en nuestro trabajo de proporcionar un producto de calidad.
En el segundo nivel creo que son las roturas que pueden ir a un entorno de producción roto. El factor decisivo aquí es, cuáles son las consideraciones del SLA y cómo impactan en el negocio así como el nivel de confianza del usuario en un producto. Las características que caen en esta categoría deben ser cuidadosamente discutidas con el equipo y equilibradas con la rapidez con que un equipo puede recuperarse. Esa es la rapidez con la que podemos producir una nueva versión y hacerla llegar a nuestros clientes.
El tercer nivel son las áreas en las que está bien si el software sale a producción con problemas. No nos preocupamos por arreglarlos hasta que un usuario nos señala el problema – lo arreglaremos cuando nos demos cuenta de que tenemos un problema, a menudo la mayoría de los usuarios nunca se dieron cuenta de que algo andaba mal.
Genial. Entonces, ¿cómo abordas esta clasificación de riesgos de tres niveles? ¿Cómo se ve en acción?
Este esquema de tres niveles es la forma en que construyo un plan de pruebas. Veamos un proyecto de ejemplo, un producto que recoge los choques de Firefox.
Cuando Firefox se cae, le da al usuario la opción de enviar un rastro de la pila, lo que es realmente valioso en el extremo de control de calidad. Nos ayuda a mirar a través de varios cientos de millones de usuarios y averiguar dónde la gente está experimentando más caídas.
Ingeniería usa esta información para averiguar qué necesitamos reproducir para saber qué está fallando y por qué. Pero también tomamos decisiones de negocios con esta información. Desde el punto de vista de los negocios, es aceptable que algunas partes de la interfaz de información se caigan. Depende del control de calidad para impulsar la claridad en la priorización de los problemas, triaje de los mismos, y tener en cuenta una visión amplia de lo que significa «calidad».
En este caso, nuestra principal prioridad es no perder nunca las colisiones. Queremos recoger esos rastros de la pila. Así que diseñamos el sistema donde, seguro, el sistema puede caer, pero podemos garantizar cerca del 100% de tiempo de actividad en la recogida de los accidentes en bruto. Sabemos que todavía estamos recogiendo choques y podemos reprocesarlos. Ese tipo de respuesta se traduce a los usuarios de nuestro sistema como calidad. Es importante destacar que el front-end de la web de este sistema puede bajar, una regresión CSS o JS puede ocurrir, pero nunca podemos perder una caída en bruto debido al tiempo de inactividad.
Sobre la calidad
Travis: Parece que la forma en que piensas en la «calidad» no sólo se refiere a lo bien que funciona un producto, sino a lo positivo que el usuario ve e interactúa con él.
Sí. La calidad tiene que ver con la experiencia que el usuario percibe de un producto tanto como con las partes ocultas del propio producto. Puedes tener el mejor código del planeta, pero si el producto no resuena bien entre los usuarios, no es una aplicación de calidad.
Tengo experiencia en ingeniería de software y psicología. En el mundo de la ingeniería de pruebas, necesitas tener tanto habilidades humanas como técnicas. Necesitas habilidades sociales para tener empatía por tu equipo y por tus clientes. Habilidades técnicas para tener la capacidad de examinar críticamente las soluciones que se están creando.
Después de todo, todos estamos creando un producto que esperamos tenga un impacto positivo en la gente. Un ingeniero de pruebas necesita añadir a esa cultura de equipo, necesita entender las soluciones técnicas complejas, teniendo en cuenta también la experiencia del usuario final.
Personal para el control de calidad
Travis: Teniendo en cuenta la importancia del control de calidad, tengo curiosidad por la forma correcta de introducirlo. Una pequeña empresa con solo desarrolladores es puramente reactiva al principio. Los usuarios encuentran problemas antes que tú. ¿En qué momento empiezas a pensar en la garantía de calidad en un sentido más proactivo?
Si te refieres a tener un ingeniero de pruebas dedicado, creo que ninguna empresa es demasiado pequeña para el control de calidad. Incluso una nueva empresa. Para ser más específico, cualquier grupo que esté creando un complejo conjunto de software, una persona dedicada a desenterrar preguntas sobre la calidad es un beneficio. Los probadores son un tipo especial de geek. Sobresalimos en ayudar a un equipo a hacer las preguntas correctas y a entender los riesgos a medida que evolucionan. Formulamos planes para mitigar esas preocupaciones. Ayudamos probando de forma reproducible las afirmaciones de que tenemos un producto de calidad.
En cierto punto, un producto lo suficientemente complejo necesita que alguien cree pruebas automatizadas para comprobar y estresar el sistema. Aún no he estado en un proyecto que no se haya beneficiado de algún nivel de automatización de pruebas. Encuentro que la automatización viene como resultado de las pruebas exploratorias manuales o directamente como herramienta para ayudar a hacer pruebas manuales exploratorias.
En el tema del futuro del control de calidad, probablemente siempre automatizaremos las tareas repetitivas, lo que abre espacio para las pruebas exploratorias manuales. En este momento, la mayor parte de las pruebas de alta empatía que se hacen son realizadas por humanos.
Travis: Empezaste hablando de añadir valor a un producto. Así que para terminar, ¿cuál crees que es el valor de tener un sólido control de calidad como parte de un equipo de desarrollo?
Matt: El control de calidad siempre ayudará a identificar las preguntas específicas a la calidad del producto y ayudará a traducir esas preguntas en resultados procesables para que el equipo de ingeniería actúe. Ayudamos a defender al usuario final y nos aseguramos de que el equipo entienda sus necesidades. Eso es reducir los riesgos. Eso es aumentar la calidad de un producto.
El control de calidad añade valor a un equipo al tener una visión holística de todo el sistema, y al hacer aflorar los riesgos en evolución que cambian con el tiempo.