Si soy el CEO de una empresa de tecnología, ¿por qué debería considerar contratar a un personal de control de calidad? Parece que este rol podría estar cubierto por un gerente de producto y una ingeniería que divida el rol de un personal tradicional de control de calidad.

El personal de control de calidad aporta ciertas ventajas únicas:
1. No temen las pruebas destructivas. Los desarrolladores subconscientemente evitan las pruebas de escenarios negativos. Si usa una aplicación de una manera específica, los escuchará exclamar: “¡Se supone que no debes hacer eso!”
2. Encuentran defectos ocultos. Los desarrolladores en situaciones de alto estrés a menudo pueden no revelar escenarios de error de baja probabilidad, pensando “Arreglaré esto la próxima vez. Nadie lo notará de todos modos”.
3. Tienen una mayor disciplina para el seguimiento de defectos, priorización e informes. Los desarrolladores generalmente son reacios a la documentación, aunque siempre hay muchas excepciones. Tienden a contener mucha información de defectos en su cabeza. “Oh, ya lo sé. Johnny y yo lo discutimos y pensamos que lo arreglaremos en el parche el próximo mes”. “¿Está siendo rastreado?” “Ya está arreglado en la rama. Así que no es un problema”.
4. No se cansan de la regresión: es su trabajo. Los desarrolladores están aburridos de las pruebas de regresión. Si están seguros de que un cambio no afectará lógicamente una función relacionada, no lo prueban. Es inútil y aburrido. El personal de control de calidad no asume tales riesgos y surgen defectos: después de todo, somos humanos y no podemos pensar en cada escenario.
5. Un entorno de control de calidad restringido y dedicado impone la disciplina de implementación, por lo que tendrá menos sorpresas durante la puesta en marcha. Los desarrolladores tienden a jugar con código y bases de datos ad-hoc en cada entorno sobre el que tienen control.
6. Los productos generalmente comienzan con un gran diseño y facilidad de uso, pero luego la realidad se cuela porque algunas características son demasiado complejas, otras simplemente no son factibles como están diseñadas, los productos de la competencia presentan una nueva característica, o alguien acaba de tener una idea de la característica asesina. Tanto los gerentes de producto como los desarrolladores están a la altura de sus decisiones y cambios minuciosos todos los días, y es fácil perder de vista la experiencia general. El control de calidad desempeña un papel vital como punto de control para garantizar que el producto siga siendo utilizable en todo esto.
7. Hay personal de control de calidad especializado para pruebas de rendimiento, pruebas de vulnerabilidad, pruebas de accesibilidad, etc. y son mucho más eficaces y eficientes que los desarrolladores.
8. Los gerentes de producto y los usuarios finales no son tan efectivos como el personal dedicado de control de calidad. Tienen sus propios trabajos diarios.

Habiendo dicho todo esto, si su empresa es lo suficientemente pequeña, sus desarrolladores están lo suficientemente experimentados, su aplicación no es de naturaleza financiera y nadie va a perder dinero por un accidente, entonces, por todos los medios, retrasar la contratación de personal de control de calidad hasta Necesitas escalar. Pero su gerente debe implementar revisiones por pares en su equipo, y debe haber un sistema de seguimiento de errores dedicado y fácil de usar.

El Gerente de Producto está faaaaaaaaaaaaaaaaaaar lejos de verificar a sí mismo que las cosas que se construirán son las que deberían ser. Si los PM tuvieran que hacer esto para cada característica, vería el lanzamiento de un producto / servicio en una década después de la competencia. Tan sencillo como eso. Los PM transmiten los QA para ese trabajo y los PM tienen UN trabajo más importante que hacer: cumplir con la fecha límite del lanzamiento con todas las características (de trabajo) a las que se han comprometido.

Ahora olvidemos los PM e imaginemos que solo tenemos desarrolladores que escriben las pruebas para su código, crean casos de uso y encuentran defectos.

La gran mayoría de los desarrolladores conocen el código, y conocer el código no significa que conozcan el producto, servicio o función. No se espera de ellos. Sí, un desarrollador puede escribir pruebas bastante claras para probar el código, pero ¿a qué precio? Hora. Y el tiempo es todo lo que importa porque hay algo llamado “Objetivos de negocio” y para cumplirlos no puede permitirse tener un desarrollador con una mentalidad muy diferente a la mentalidad de un control de calidad para probar su propio código por completo. Incluso si tiene éxito, ¿qué pasa si se ha perdido muchos casos de uso? Al final, tendría un código perfecto que solo hace la mitad del trabajo.

Ahora imaginemos que tiene híbridos Dev-QA. Hacen todo: codifican y prueban el código como monstruos y se aseguran de que el cliente obtenga lo que quiere. Los humanos son incapaces de realizar múltiples tareas por diseño, de lo que somos capaces es de cambiar rápidamente de contexto, lo que no es lo mismo. Una persona puede (a veces) hacer con éxito solo una cosa a la vez, por lo que tendrá que duplicar el personal y los desarrolladores son más caro que los QA … y eso puede suceder solo si encuentra los híbridos antes mencionados. Y pagarlos. Ahora eso es una sobrecarga y uno de los peores: financieros.

Sin embargo, hay un caso en el que realmente no necesita QA: veeeeeeeeeeery pequeños proyectos. Como “Hello World” o tu sistema casero para encender y apagar las luces con un aplauso. 🙂

Si desea hacer negocios y el tiempo y el dinero son una restricción, entonces necesita QA. Al igual que los arquitectos necesitan ingenieros de construcción y los ingenieros de construcción necesitan a alguien que haga el trabajo.

En un mundo ideal, todo el código estaría libre de errores, haría exactamente lo que se especificaba y coincidiría con los requisitos del cliente. Todos entenderían exactamente lo que se dijo en cada reunión y comunicarían la esencia y los detalles de todo a todos los involucrados, asegurando una comprensión idéntica en todas las organizaciones.

Como cualquier persona que haya pasado 10 minutos en la vida real podría decirte que lo anterior es prácticamente imposible de lograr, incluso cuando trabajas contigo mismo.

El rol del control de calidad varía, pero en general el control de calidad es responsable de asegurarse de que (1) el software haga lo que se supone que debe hacer correctamente, (2) el software no haga lo que se supone que debe hacer, y (3) documentar 1 y 2. Idealmente, QA también se asegura de que el software realmente cumpla con los requisitos del cliente, pero eso depende más de la visión de QA de la organización.

Aquí hay un gran ejemplo de por qué necesita control de calidad. Tiene un sitio web donde puede depositar dinero mediante una transferencia. El usuario debe ingresar un valor para depositar. El ingeniero dice “genial, lo agregaré al saldo del cliente”. ¡Perfecto!

Una persona de control de calidad probablemente intentaría, en sus pruebas, agregar un saldo negativo a la cuenta, lo que en este caso sería esencialmente un retiro ilimitado no autorizado. Tenga en cuenta que esto realmente ha sucedido en la vida real.

Independientemente de tener un personal de control de calidad o no, con el software, las pruebas automatizadas son imprescindibles si alguna vez espera probar completamente la regresión sin dejar de expandir las funciones.

Si necesita un personal separado en un análisis de costo-beneficio depende de la utilización del producto final. Si su negocio requiere que el producto final sea ajustado en el primer lanzamiento, debe pagarlo. Dando a los desarrolladores / ingenieros de software objetivos duales, presenta las funciones lo más rápido posible y asegurándose de que sea perfecto, cuando se trata de un momento crítico, la calidad se verá afectada. Tener un equipo de control de calidad es el control de esto, ya que su objetivo total es arrojar luz sobre los problemas. Si intenta hacerlo barato, espere obtener lo que paga.

La otra alternativa es darle a los desarrolladores de software tiempo para resolver las cosas en el tiempo que creen que necesitan. Nunca he visto que eso suceda.

Como resultado sin QA dedicado, los errores aquí y allá serán su primer problema. El rendimiento será tu segundo. Por último, tendrá su CTO o Director de TI diciéndole que necesitará un refactor masivo o una reescritura significativa que parece venir cuando no puede pagarlo.

Cuando las personas piensan en las pruebas, el 99% de las veces asumen que solo se trata de las pruebas, pero no lo es. Las pruebas se tratan principalmente de gestión del trabajo y priorización.

Verá, más allá de encontrar el error real, un probador tiene que pensar en las siguientes cosas:

1. ¿Qué debería importarme?
La prueba es un ejercicio infinito en el sentido de que hay más combinaciones válidas posibles para evaluar que el tiempo para hacerlo. Eso significa que un probador necesita comprender tanto la tecnología, el negocio y las prioridades del proyecto para saber qué perseguir.

Esto es realmente clave para entender porque no existe una versión libre de errores. Esta es una falacia completa y a menudo es la causa de una tonelada de conflictos en un proyecto.

Este pensamiento surge de las pruebas tradicionales en las que alguien escribiría 1000 casos de prueba, los probaría y luego anunciaría “¡Está completo!”. La realidad es que cualquier proyecto experimenta una TONELACIÓN de cambio de alcance durante el desarrollo.

Yo lo llamo el Problema Crappy Churn.

El abandono revela diferencias en la interpretación, decisiones que se cambian y una captura inadecuada de esas decisiones.

Ninguna de estas cosas es evitable. Siempre.

La estructura de comunicación y jerarquía de poder de su equipo afecta gravemente el movimiento de la información y, a menudo, puede saber dónde se ubican las personas en esa jerarquía analizando su rastreador de errores.

Lo que me lleva al punto 2.

2. Los probadores a menudo actúan como el equipo de limpieza para el problema Crappy Churn.
La razón por la que esto sucede es porque las pruebas son la confluencia de muchos ríos. Todo, desde el análisis, el desarrollo y cualquier decisión de gestión, TODO TIENE que pasar por pruebas.

Entonces, si hay alguna discrepancia, aparecerá en las pruebas, ya que las pruebas son principalmente una práctica binaria (ya sea incorrecta o correcta).

Lo que me lleva al punto 3.

3. El problema del contexto cambiante.
Es reconfortante obtener una decisión fija. Nos gustan las cosas fijas. Nos gusta saber que cuando se decida algo, seguirá siendo así.

Pero aquí está la cosa. Algo que se registró como error puede cambiar (según el contexto) para convertirse en una solicitud de cambio o una función.

La persona responsable de la gestión es el probador. Tienen que vigilar “el qué” de las cosas.

Esto sucede diariamente. Cada reunión de scrum. planificación del proyecto, “como se llame su reunión”, estos cambios se ponen de manifiesto.

Lo que me lleva al punto 4.

4. La prueba es su propio dominio.
Es realmente una práctica infravalorada. De hecho, lo llamo la Práctica de Estirar y Exprimir (porque siempre se estira por recursos y por tiempo).

En esencia, un gran probador es alguien que está capacitado para absorber información en diferentes niveles de detalle y extrapolar, según el análisis de patrones, donde se encuentran las áreas de riesgo potencial. Todo teniendo en cuenta las últimas prioridades, los últimos cambios en el código y los últimos requisitos.

Lo que me lleva al punto 5.

5. No contrate a los tradicionales (por falta de un término mejor).
Si tienen los casos de prueba como su principal medio de análisis y le hablan detenidamente sobre cómo redactar un plan de prueba de 50 páginas, y luego armar 1000 casos de prueba, no los contrate.

Apunta a probadores basados ​​en contexto.

Son malos cuando se trata de detectar problemas y pueden sobresalir en documentación muy limitada (proviene de los requisitos de reingeniería sobre la marcha).

Y finalmente, punto 6.

6. Nunca olvides que es un paquete.
La prueba no se trata simplemente de evaluar el software. Como se mencionó anteriormente, se trata de obtener la información correcta de la persona adecuada, administrar el flujo de trabajo dentro del equipo y proporcionar orientación sobre si seguir adelante o no.

Ps Una última nota final. Si su aplicación es simple y no tiene una complejidad tecnológica inherente y su ciclo de desarrollo es constante y lento (4 lanzamientos de producción al año), no se preocupe por contratar un probador.
Sin embargo:

1. Si tiene una plataforma en rápida evolución, múltiples tecnologías o está tratando con software heredado …
2. Si su producto es inherentemente técnico, utiliza algunos algoritmos de levantamiento pesado para hacer cosas debajo del capó, o le falta madurez dentro de quien haga los requisitos.

Consigue un probador.

Después de haber trabajado, construido y administrado equipos tecnológicos que han incluido y se han ido sin equipos formales de control de calidad, la experiencia me ha enseñado que tener una cultura de ingeniería dirigida por la calidad (lectura: prueba) es fundamental, tener un equipo de control de calidad no lo es. Esto es especialmente cierto si su producto / servicio está basado en la web, donde hay una gran cantidad de excelentes herramientas y marcos de código abierto para pruebas e implementación automatizadas.

Mi consejo..

* Inculcar una cultura basada en pruebas lo antes posible. Antes de escribir su primera línea de código, los desarrolladores (que deberían ser responsables de escribir sus propias pruebas) deberían preguntarse “¿cómo voy a probar esto”?

* Diseñar y escribir código para admitir la capacidad de prueba. Organice el código de modo que las clases / métodos puedan ser probados en unidades.

* Encuentre una manera de integrar algún nivel de revisiones de código de pares en sus prácticas de desarrollo. Si está utilizando git, las solicitudes de extracción son una gran herramienta para facilitar estas revisiones. Haga que las pruebas unitarias sean un requisito para aceptar solicitudes de extracción.

* Desarrollar una pasión igual por la automatización desde cero, incluyendo
– Tu construyes
– Ejecución de pruebas unitarias
– Implementación de su software en entornos de prueba
– Ejecución de pruebas de extremo a extremo
– Implementación de su software en producción

Nuevamente, hay excelentes herramientas de código abierto o servicios disponibles para implementar estas prácticas.

En mi empresa actual, hemos implementado todas estas prácticas con un equipo de tecnología de cuatro personas, incluidos yo (veterano con costra) y tres desarrolladores junior (medidos en años). Con este pequeño equipo, hemos podido implementar características y actualizaciones con velocidad y confiabilidad que nunca pude igualar con equipos mucho más grandes y experimentados, obstaculizados por la falta de pruebas automatizadas sustantivas.

Nuestro software está literalmente respaldado por miles de pruebas unitarias y un conjunto creciente de pruebas automatizadas de extremo a extremo. A medida que la complejidad de nuestra base de código ha aumentado, tener este gran conjunto de pruebas nos ha permitido realizar algunos cambios bastante significativos bajo el capó mientras tenemos transparencia en las partes del sistema afectadas y la confianza de que los cambios no rompen nuestras aplicaciones.

En términos de quién trabaja en las pruebas automatizadas, aunque podría ser posible traspasar la responsabilidad de desarrollar las pruebas de extremo a extremo a ingenieros de control de calidad dedicados, no me atrevería. Cualquier ahorro que pueda pensar que logrará al liberar a sus desarrolladores para que se centren en las nuevas características probablemente se verá erosionado por la sobrecarga que surgirá de la separación de las preocupaciones. Promover una cultura en la que los desarrolladores sean totalmente responsables de la calidad del código que producen es saludable para la organización.

Finalmente, como CEO, depende de usted establecer los estándares de excelencia que espera de su equipo de tecnología. Construir una plataforma de tecnología altamente automatizada basada en pruebas finalmente dará buenos resultados cuando pueda actualizar su sistema con frecuencia sin tener que cruzar los dedos cada vez que lo haga. Sin embargo, construir ese tipo de sistema requiere una inversión inicial en tiempo, recursos y priorización. En nuestro caso, nos beneficiamos de recibir todo lo anterior de nuestro CEO.

Hay una cosa que determina si necesita personal de control de calidad: su nivel de automatización y habilidad de software en su equipo . ¿Cuánto de su proceso de desarrollo, prueba y entrega está automatizado?

Muchas empresas más pequeñas y nuevas empresas lanzan software de alta calidad con equipos pequeños y sin roles / personal de control de calidad. Lo hacen automatizando todo y escribiendo excelentes pruebas automatizadas. Los ingenieros de software a menudo son probadores manuales deficientes, pero la automatización de pruebas sólidas es ahora una competencia fundamental de la ingeniería de software.

Sin embargo, ¿son estos el tipo de ingenieros en su organización? ¿Ya realiza pruebas e implementación automatizadas? ¿Es parte de tu cultura? Si la respuesta es no, entonces tendrá que cargar con el costo del control de calidad manual para mejorar la calidad de su software.

Alternativamente, podría gastar menos dinero y contratar ingenieros de software con experiencia y liderazgo para comenzar a llevar la automatización y la propiedad a su cultura de ingeniería. Hay muchos beneficios para los ingenieros que poseen software desde el inicio, las pruebas y la producción, pero no todos los equipos son capaces de trabajar de esta manera.

Los programadores y los gerentes de producto tienen una actitud de creador, mientras que el control de calidad tiene una mentalidad diferente de hurgar en las cosas para ver si se rompe. Necesita una mentalidad similar al realizar pruebas de seguridad. En el pasado, conocí a un alumno de secundaria que hacía mejores pruebas de seguridad que los ingenieros de mi equipo porque requiere una mentalidad diferente.

Si tiene cerca de un 100% de pruebas de automatización para su código, entonces también contrataría a un equipo de control de calidad para tener una opinión independiente de cómo está funcionando un lanzamiento.

Si está en contra del control de calidad manual, le recomendaría contratar un control de calidad de automatización que sea ingeniero, pero escriba pruebas de automatización como selenio o pruebas de API de descanso.

Además, a veces tiene problemas con el lanzamiento e hizo una corrección 2 horas antes del lanzamiento y luego el ingeniero no tiene tiempo suficiente para agregar todas las pruebas y realizar el control de calidad, por lo que mientras está automatizando la prueba, el control de calidad puede hacer las pruebas. Además, el tiempo del gerente de producto es más adecuado para la gestión del producto que para hacer un control de calidad de regresión. Supongamos que realizó una refactorización de la infraestructura o se mudó de su propio centro de datos a AWS, entonces el gerente de producto podría no estar motivado para hacer todo el control de calidad de regresión. Dicho esto, el punto anterior solo se aplica si no tiene un 100% de automatización. He trabajado con equipos haciendo sprints de 1 a 2 semanas y en 2 semanas no hay suficiente tiempo para escribir pruebas de selenio. Quiero decir que sí, el desarrollador escribirá pruebas unitarias y pruebas funcionales, pero para cuando la función esté desactivada, o bien debe retrasar el lanzamiento o es mejor probarlo manualmente y luego automatizar el selenio en paralelo.

En primer lugar, voy a suponer que te refieres a “probadores” y no a “personal de control de calidad”. Debido a que los ingenieros, gerentes de producto, de hecho, todos los que trabajan en el proyecto están allí para ayudar a crear un producto de calidad: Probadores: salgan del negocio de aseguramiento de calidad

Es posible que no desee contratar probadores. Quizás los errores en la naturaleza no son tan importantes para ti. Pero suponiendo que lo sean …

Un buen probador no solo verifica que el producto funcione. Sus pruebas automatizadas, sus casos de uso, su gerente de producto, parece que van a ayudar a verificar que el producto funciona. Un mal evaluador también solo hará eso, por lo que puede ser un desperdicio contratar a un mal evaluador.

Un buen probador piensa “más allá de los requisitos” e intenta descubrir todas las formas en que el producto no funcionará. Serán entrenados en pensamiento crítico y análisis, diseño de pruebas y desempeño de experimentos. Un gran probador ejercitará su producto para obtener la mayor cantidad de información posible y le brindará la información que necesita para tomar decisiones comerciales informadas. Un gran probador encuentra amenazas de valor y las comunica de manera significativa.

Si desea estar completamente informado de todas las formas en que su producto puede fallar antes de que lo hagan sus clientes, entonces sí, debería considerar contratar probadores. Encontrar buenos probadores es difícil porque la mayoría de los probadores no están bien entrenados, pero dan la ilusión de estar bien entrenados. Hablarán sobre “casos de prueba” y “cobertura de prueba” y proporcionarán gráficos y métricas, pero en realidad no saben de qué están hablando y terminarán costándole tiempo y dinero. Aunque este artículo es antiguo, sigue siendo un gran artículo sobre la contratación de evaluadores: Página en testingeducation.org

No conozco los detalles de su organización, por lo que no puedo dar más comentarios específicos que este, pero estoy feliz de hablar en cualquier momento. Puede que conozca personas en su área que puedan ayudarlo.

Cuando no prestas atención a la calidad, terminas defendiendo productos pobres por otros medios. Gasta más tiempo y dinero en soporte y obtiene más problemas posventa o posventa.

Por ejemplo, ha creado un producto SaaS con pruebas limitadas (solo con el departamento de desarrolladores). No ha pasado por UX y no tiene idea del rendimiento de su producto.

• ¿Cómo va a manejar la carga en su servicio en la nube? ¿Cómo va a medir la experiencia del cliente de manera imparcial?
• ¿Cómo va a verificar la experiencia del cliente en la página de destino?
• ¿Cómo va a manejar el tiempo de inactividad del producto?
• ¿Cómo va a medir qué funciona y qué no?
• ¿Crees que los ingenieros guardan la documentación de los errores y los mapean entre las versiones del producto?
• ¿Crees que los ingenieros pueden ver los errores en su propio código?

¿Vas a tomar la palabra del equipo de desarrollo y producto y el equipo de ventas? Bien entonces. Lo que sea que funcione para su producto y empresa. Cuando pones tanto en el plato de tu equipo de productos, es menos probable que crezcas a partir de ahí. ¿Crees que el gerente de producto es una persona UX? El equipo de desarrollo es bueno para medir el rendimiento del producto wrt requisito del cliente o documento de especificación? ¿Crees que no hay sesgos en tu equipo cuando encuentras errores o mides el rendimiento o la calidad?

El control de calidad parece innecesario para usted porque está obligando a los equipos actuales con múltiples tareas para las cuales su producción puede o no generar resultados viables. Hay una razón, el departamento de pruebas trae resultados fuera del producto sesgado y el equipo de ventas.

Si el personal de pruebas fuera inútil en la jerarquía para el crecimiento del producto, todas las multinacionales del mundo se habrían deshecho de él.

Antes de intentar responder a esta pregunta, debe tener una discusión con su CTO si hay una, o quien sea la tecnología líder, o tal vez sea usted si es una startup. En cualquier caso, averiguaría cómo planea entregar su producto.

Si está implementando agile / scrum / kanban y desea confiar en sus entregas, es muy importante contar con un conjunto profundo de casos de prueba que verifiquen la calidad del software diariamente a través de la Integración Continua (CI). Esto significa que cada vez que su equipo de desarrollo está revisando su código, dichas pruebas se ejecutan produciendo un informe que mostrará la cobertura de la base de código y el número de pruebas exitosas / fallidas. Esto lo preparará para la entrega continua.

Ahora hay varios conjuntos de pruebas que se pueden escribir, pruebas unitarias, pruebas de integración, pruebas de caja negra, pruebas de caja blanca, pruebas de rendimiento. Algunas pruebas son escritas por el equipo de desarrollo, sin embargo, un equipo de control de calidad podría escribir otras pruebas, tales como escenarios de front-end, pruebas de API, pruebas de caja negra, etc.

Ahora, según su presupuesto, su estrategia podría ser tener a alguien local que sea muy detallado y trabaje en estrecha colaboración con el equipo de desarrollo que pueda desarrollar casos de prueba / marco, etc., y el trabajo real podría subcontratarse, ya que muchas de estas pruebas se escribirán una vez y mantenido a lo largo del tiempo. Por lo tanto, necesitaría calcular cuánto trabajo se subcontratará y cuánto se hará en la casa.

Puede hacer que el equipo de desarrollo cree algunos casos de prueba, sin embargo, si el equipo es pequeño y está enfocado en construir el producto, la mayoría de las veces no es una buena idea que los desarrolladores prueben su propio código desde la perspectiva del usuario final. El equipo de desarrollo puede crear pruebas unitarias, pruebas de rendimiento, pruebas de carga, pero las pruebas funcionales deben hacerse por separado de manera automatizada.

La conclusión es que necesita una estrategia que se alinee con la hoja de ruta de desarrollo y dónde desea que esté el control de calidad. Además, el control de calidad no debe considerarse una idea de último momento, debe ser parte de la estrategia tecnológica general.

Al final, ¿desea confiar en su equipo de desarrollo para probar si el producto final está listo para la producción o prefiere configurar un marco de control de calidad eficiente que ayudará al equipo de desarrollo a ofrecer calidad?

Para ahorrar dinero.

Puedo confiar en mis programadores para que hagan algo libre de errores, pero esa no es la ruta más rápida. Están tan cerca de su propio trabajo que quedan atrapados en los detalles. También dejaron que la pasión los cegara después de una noche trabajando en algo difícil.

Es mucho mejor conseguir algo funcional y luego pasarlo a otro par de ojos. Ese es tu control de calidad. Convierten los requisitos restantes en una lista de errores, que el ingeniero puede resolver rápidamente.

Menos tiempo de trabajo y una proporción se trasladó a personal con salarios más bajos.

NB: los errores no suelen ser culpa de un desarrollador. No siempre son algo que se ha puesto; normalmente son algo que aún no se ha puesto. Deje que QA encuentre esas brechas.

Es de suma importancia para la calidad general de sus productos que se realicen pruebas independientes. Además, el vicepresidente / director de control de calidad debe informar directamente a usted, el CEO. Usted es responsable de la calidad de los productos que está produciendo y, por lo tanto, debe confiar esta tarea crítica a un equipo de profesionales de control de calidad capacitados y altamente calificados.

La independencia de una organización de prueba calificada es necesaria para un ciclo de vida saludable del producto. El personal de control de calidad ve la vida de manera diferente y, por lo tanto, los problemas de manera diferente. Inicialmente están buscando demostrar que funciona: pruebas de verificación (como lo haría Dev y gestión de productos), pero rápidamente cambian a pruebas de validación, qué espera el cliente, qué puede salir mal, qué hará el incauto público, cómo podemos romperlo, qué tensiones podemos poner en el sistema, etc. Los gerentes de producto son una buena administración de productos y los desarrolladores son buenos en el desarrollo, ese es su enfoque, como debería ser. El uso de una organización de control de calidad sólida, con la fuerza del CEO detrás de ellos para establecer estándares de codificación, desarrollar métodos de prueba, ayudar a la gestión del producto a establecer criterios de prueba de verificación y ayudar al marketing a verificar sus materiales y reclamos, esa es la responsabilidad y función de un organización integral de control de calidad, y paga dividendos.

Puedo compartir con ustedes un par de ejemplos de mi experiencia específica como probador (hace 20 años) que los ojos independientes (no los desarrolladores o la administración de productos) encuentran problemas que otros se perderán. En un caso, (un raro error estético de detención del envío), el nombre del producto estaba mal escrito en el banner del programa y nadie (de la administración del producto, Dev, marketing o el personal ejecutivo lo vio). Otro ejemplo, encontré un error de bloqueo fatal que había eludido a Ingeniería (y QA estrechamente vinculado) para 10 versiones lanzadas. 10 versiones muy exitosas (el producto tenía la participación de mercado # 1 en 95%). Sin embargo, ocasionalmente, se produciría un bloqueo fatal completamente irreproducible, que perdería todos los datos de usuario no guardados. Yo, un probador novato, no acepté la sabiduría convencional e introduje pruebas de estresores y parámetros que nadie había pensado anteriormente. Una vez que lo hice, pude reproducir el bloqueo a voluntad y el programador principal se sorprendió de que el escenario del bloqueo fuera tan simple de reproducir y que nunca se hubiera encontrado en todas sus revisiones y pruebas.

Solo un par de ejemplos de cómo el pensamiento convencional conduce a pruebas convencionales. Considerando que, un equipo de pruebas de control de calidad dedicado y creativo conduce a mejores resultados de prueba y productos de mejor calidad, así como a proteger los activos de la empresa (protección de derechos de autor, etc.).

La respuesta corta: debe contratar a alguien en QA porque …

1. … Cree que la “calidad de la aplicación” debería ser una prioridad (por ejemplo, tiene objetivos de marca o ingresos en riesgo).
2. … Los gerentes de control de calidad poseen conjuntos de habilidades específicas . Del mismo modo que no aprovecha a su ingeniero para hacer la comercialización de su producto, el relleno para este rol especializado generalmente es solo una solución a muy corto plazo.

Respuesta más larga:
He estado discutiendo un problema similar con un amigo cercano que es cofundador de otra startup de Boston. Son una startup de 20 personas con un crecimiento impresionante. Actualmente tienen dos ingenieros, uno para iOS, otro para Android, y un gerente de producto. Como startup, querían mantener el recuento bajo e intentaban evitar cualquier inversión en QA utilizando una lógica similar a la que usted estableció en los detalles de la pregunta anterior.

Sin embargo, lo que encontraron fue que el ingeniero solo quería codificar y el “tipo de producto” solo quería centrarse en las nuevas características. Ambos comprensibles. Nadie fue el único responsable directo y exclusivo de la calidad de la aplicación que se reflejó en los comentarios de los usuarios / posibles clientes.

La solución para ellos fue dos partes; a) identificar quién posee QA, y b) proporcionarles algunos recursos de QA, que es donde entramos nosotros (Applause 360 ​​° App Quality ™). Esto les permitió pasar mucho menos tiempo en QA internamente sin necesidad de un FTE.

Disculpas si esto es demasiado atractivo para las ventas, pero estoy bastante entusiasmado con la simbiosis. Me complace compartir más información o expandir mi respuesta, solo comente, envíe un mensaje o envíeme un correo electrónico directamente ( [correo electrónico protegido] ).

Todavía contrataría a un equipo de control de calidad. Aunque desde una perspectiva de alto nivel no estoy en desacuerdo con su razonamiento (y los ingenieros deben escribir todas las pruebas unitarias), es necesario un buen equipo de control de calidad para respaldar a los ingenieros y PM.

La gran mayoría de los ingenieros y PM no tienen una mentalidad suficientemente conflictiva hacia cualquier trabajo, y mucho menos el suyo, para garantizar una alta calidad. Por la misma razón, no confiaría en ningún tipo de configuración de seguridad hasta que una empresa externa intentara y no lograra entrometerse.

En mi última puesta en marcha, los ingenieros sirvieron como QA, pero ese fue el grupo de ingenieros más fuerte con el que he trabajado: graduados de Stanford e Illinois, más de la mitad de los cuales tenían doctorados, trabajando en un producto extremadamente técnico.

Acabo de revisar algunos softwares para usar en mi propio negocio, creados por pequeñas empresas y nuevas empresas que obviamente no tienen control de calidad. El resultado es que acabo de solicitar un reembolso.

Los buenos QA / Testers por ahí estudian su oficio de una manera que los desarrolladores, gerentes o diseñadores no (o incluso desearían). Solo hay tanto tiempo que todos podemos pasar para convertirnos en expertos.

Si contrata un buen QA / Tester, se sentirá agradecido por los problemas que encuentre. La clave es encontrar buenos probadores, creo que la industria de las pruebas de software está obsesionada con un historial ineficiente de pruebas que ha llevado a las personas a pensar que las pruebas no son necesarias o que nadie puede hacerlas.

Aclaremos primero lo que quiere decir con QA. Cualquier proyecto no trivial siempre tiene componentes de verificación de diseño. Si está construyendo hardware, una segunda gran parte del esfuerzo se dedica a la prueba de fabricación. Estas dos son cosas muy diferentes (aunque con cierta superposición de metodología).

Asumiré por ahora que estás preguntando sobre la verificación del diseño. Si los recursos dedicados aquí tienen sentido depende en gran medida de si la calidad del producto realmente importa.

Lo digo en serio. Si tiene un widget indispensable, puede estar bien eliminar al 20% de sus clientes. Ahorre dinero, gástalo en mercadotecnia y aún se jubila anticipadamente con el 80% restante.

Sin embargo, si es importante que el producto funcione, entonces debe enfatizar la verificación del diseño. Aquí hay un ejemplo simple de por qué. Supongamos que está creando una aplicación de tres en raya para Android. ¿Suficientemente simple para permitir que el ingeniero de diseño y el tipo de producto hagan lo correcto?

De acuerdo, la aplicación se envía a Google Play. Resulta que no funciona en el Nexus 5, bloquea el teléfono en teléfonos Galaxy más antiguos, etc. Vaya.

El problema fundamental es que para cualquier producto no trivial, el espacio de prueba es enorme. Es posible que pueda enumerar los requisitos individuales (y, por lo tanto, derivar pruebas dirigidas), pero los asesinos ocurren en las uniones: productos cruzados de requisitos y secuencias.

La verificación del diseño es una disciplina propia. Ni su ingeniero de diseño ni el chico del producto pueden desempeñar este papel.

Si desea obtener más información, investigue técnicas de verificación de chips, por ejemplo, verificación aleatoria restringida. Cuando un conjunto de máscaras de litografía puede costar $ 5M, y cada recorrido del transbordador consume otra NRE de $ 1M, la tendencia es hacer las cosas bien la primera vez.

Dada la forma en que ha formulado la pregunta, le recomendaría encarecidamente que invierta en un personal dedicado de control de calidad. Si trata el aseguramiento de la calidad como un paso discreto en el ciclo de desarrollo, es mucho mejor que contrate profesionales para realizar ese paso. Los buenos ingenieros de control de calidad aportan creatividad y rigor al proceso de prueba que es difícil de encontrar en otras disciplinas.

Dicho esto, es posible prescindir de un control de calidad dedicado, pero requiere un enfoque completamente diferente del ciclo de vida del desarrollo. Requiere alejarse de grandes lanzamientos monolíticos en los que mil cambios pequeños se combinan a la vez. En su lugar, desea una entrega continua (o casi continua), donde cada verificación de código se valida inmediatamente mediante pruebas automáticas, y cuando pasa, se libera automáticamente. Esto es dificil de hacer.

Significa, en primer lugar, que las pruebas automatizadas (pruebas unitarias, pruebas de integración, pruebas de rendimiento, todo eso) deben ser una forma de vida. Deben ser confiables, integrales y bien mantenidos. Para aplicaciones web con pruebas basadas en navegador, esto es especialmente desafiante. También significa que existe un riesgo, sujeto a la exhaustividad y confiabilidad de esas pruebas automatizadas, de que los defectos entren en producción, por lo que necesita la agilidad operativa para retroceder o avanzar si eso sucede.

Algunos productos son más difíciles que otros para adaptarse a este paradigma, pero funciona, incluso para equipos de desarrollo medianos y grandes. Los beneficios son sustanciales; cada “lanzamiento” es efectivamente un registro de código único, por lo que los errores recientemente introducidos son mucho más fáciles de identificar. Las nuevas características se prueban y lanzan a medida que se desarrollan, en lugar de tener que esperar semanas o meses para el próximo ciclo de lanzamiento. La disciplina de acatar realmente la metodología de desarrollo de prueba primero mejorará el diseño y la arquitectura del código. Incluso en el caso de un desastre, donde las pruebas automatizadas pasan por alto un error crítico y llega a producción (y cabe señalar que esto también le sucede a las corporaciones con departamentos dedicados de control de calidad), la tubería está en su lugar para implementar arreglarlo tan pronto como esté escrito. O, si tiene que retroceder, está retrocediendo un solo cambio pequeño, en lugar de tener que retroceder semanas o meses de otras cosas.

En resumen, si tiene la fuerza de voluntad organizacional para instituir un verdadero modelo de entrega continua, realmente puede prescindir de un equipo de control de calidad dedicado. Si está obligado, por cualquier razón, a ciclos de lanzamiento discretos, entonces es mucho mejor que los ingenieros de control de calidad profesionales realicen las pruebas en lugar de dejarlas en manos de desarrolladores y gerentes de producto.

• Pusieron agua en el tanque de gasolina. El propietario o la fabricación del automóvil nunca hacen esto.
• Pasan cadenas donde un programa espera un entero. El desarrollador en su mayoría habría probado con diferentes enteros.
• Intentan abrir un archivo binario ejecutable en su nuevo editor de texto. ¡¡Ridículo!!
• Suben 1000 archivos de 100 GB cada uno simultáneamente a su almacenamiento en línea. Si, estan locos.
• Intentan nombres de usuario locos como:
• Intentan nombres de usuario con caracteres no ascii.
• Intenta varias otras cosas que una persona en su sano juicio nunca intentaría.