¿Cuáles son algunas de las ‘mejores prácticas’ de startups lean para implementar una operación de control de calidad ligera pero sólida?

Estoy de acuerdo con las recomendaciones de Brian, pero quería agregar algunas respuestas Lean Startup más específicas.

Primero, debe preguntarse si QA es realmente el modelo correcto . En el mundo Lean, como sugiere Brian, la calidad es asunto de todos. Especialmente si está adoptando la práctica Lean Startup de implementación continua, la noción tradicional de QA como puerta de entrada es insostenible. En cambio, me preguntaría: ¿cómo podemos asegurarnos de que las cosas funcionen tan bien como necesitamos en nuestra situación? Los probadores son solo una parte de eso.

En segundo lugar, debe observar las prácticas orientadas a la calidad de la Programación extrema . XP es una de las raíces del modelo LS, y tienen muchos buenos consejos. En particular, soy un gran admirador de las pruebas unitarias automatizadas, pruebas automatizadas de extremo a extremo, programación de pares, propiedad de código colectivo, confirmaciones frecuentes y lanzamientos frecuentes.

En tercer lugar, consideraría con atención el monitoreo y las métricas como formas de mejorar la calidad . Monitoree para asegurarse de que su sitio web esté activo, que las máquinas estén funcionando, que los recursos no se agoten y que su aplicación no genere errores. Haga que sus métricas comerciales clave estén visibles en todo momento para todos (por ejemplo, en un monitor de pared grande). Asegúrese de que cuando haya un problema, lo sepa de inmediato.

Cuarto, sigue escuchando a tus clientes . El desarrollo del cliente se trata de escuchar lo que sus usuarios, potenciales y reales, tienen que decir. Si mantiene un diálogo activo con ellos, no solo obtendrá mucha información sobre sus necesidades habituales de productos, sino que recibirá muchos comentarios sobre la calidad de sus productos.

Quinto, perseguir la mejora continua y los cinco porqués . Me gusta hacer una retrospectiva semanal regular, y ese es un buen momento para plantear cuestiones generales de calidad. Y cuando surgen problemas, no solo los arregles; usa los cinco porqués para eliminar clases enteras de problemas.

Espero que eso ayude. No dude en ponerse en contacto si necesita más.

Suponiendo que cuando dices “QA” te refieres a “pruebas de software”, entonces no hay mejores prácticas. Si desea un equipo de prueba liviano, es esencial contratar el probador adecuado. Hay dos extremos polares para evaluar las escuelas de pensamiento, a menudo denominadas la “Escuela de Fábrica” ​​y la “Escuela Controlada por el Contexto”.

Los evaluadores a menudo se encuentran en algún lugar de la escala entre estas dos escuelas con una inclinación hacia una sobre la otra.

En general, un probador de Factory se basa en documentación, requisitos bien definidos y un proceso más rígido para producir software. Si las cosas cambian constantemente, pasan una gran mayoría de tiempo tratando de recrear su sistema y documentación y menos tiempo probando. Los casos de prueba se derivan de la documentación a menudo antes de escribir cualquier código y se utilizará una gran dependencia de las métricas. Los probadores de fábrica la mayoría de las veces tienen la necesidad de crear un rastro de papel para demostrar que no son responsables de un error que se filtra en la producción. Los probadores de fábrica tienden a confiar en certificaciones para demostrar su competencia.

En general, un probador basado en el contexto no producirá casi la cantidad de artefactos a lo largo de un ciclo que el Probador de fábrica. Utilizan la huerustica para evaluar si el comportamiento del producto satisface las necesidades de las partes interesadas, se adaptan fácilmente a los cambios / pivotes y se esfuerzan por encontrar rápidamente los grandes problemas. Los probadores basados ​​en contexto utilizan menos las métricas a cambio de una comunicación abierta y honesta durante todo el ciclo, ya que entienden cuán peligrosas pueden ser las métricas para un proyecto. Las “mejores prácticas” se ignoran a cambio de la “mejor solución para este problema en particular”. Los evaluadores basados ​​en el contexto demuestran competencia señalando éxitos anteriores del proyecto y la mayoría rechaza que la certificación asegure o mejore la competencia en el campo.

Hay mucha controversia en el campo con polaridad entre estas dos escuelas principales de pensamiento. Definitivamente tengo mis inclinaciones, pero para la mayoría de las nuevas empresas, un probador basado en el contexto producirá los mejores resultados y el mejor valor.

Al contratar, sugiero usar el título de “Tester” en lugar de “QA” o “Quality Assurance”. Todo el equipo es responsable de la calidad y un probador solo lo evalúa e informa al respecto. Un probador, o grupo de probadores, no puede garantizar la calidad.

Avíseme si desea obtener más detalles y puedo proporcionar algunas referencias que pueden ayudar.

-Brian