Hemos preparado para usted una traducción de un artículo de Dmitry Yarygin, ingeniero de control de calidad con experiencia en los principales proyectos del mundo durante más de 8 años, profesor del curso de ingeniero de control de calidad móvil en OTUS. ¿Es interesante desarrollar en esta dirección? Lo invitamos a tomar una "Introducción a la automatización de pruebas de aplicaciones móviles en Selenium y Appium" intensivas de dos días.

Pruebas de calidad. ¿Quién es responsable de esto? Durante muchos años, la única respuesta a esta pregunta estaba en mi cabeza. ¡Por supuesto, un ingeniero de control de calidad! Después de todo, yo mismo pertenezco a los ingenieros de control de calidad.

Sé con certeza lo importante que es probar la calidad de un producto de software que se planea lanzar al mercado. Sin embargo, noté algunos patrones que ocurren durante las pruebas. Me hicieron pensar en el proceso de prueba en su conjunto y en cómo podría mejorarse.

¿Deben los desarrolladores probar su código?

Gracias por preguntar Si es un desarrollador, entonces conoce todas las sutilezas y dificultades en su código, o al menos sabe más sobre su código que un ingeniero de control de calidad. Conoce su código a lo largo y ancho y comprende dónde puede surgir el problema.

Si sabe dónde podría estar el área problemática, informe al ingeniero de control de calidad. Sí, él mismo lo encontrará en algún momento específico, pero aún conoce mejor la arquitectura de la aplicación. Los evaluadores estarán agradecidos si les dice dónde esperar problemas.

Somos ingenieros de control de calidad, nos centraremos en ello y lo cubriremos con pruebas para que esté menos preocupado. Cualquier información adicional que los desarrolladores puedan proporcionar es claramente beneficiosa.

Las pruebas unitarias son definitivamente algo que los desarrolladores deberían hacer, esta es su área de responsabilidad. Las pruebas unitarias ayudarán a evitar errores innecesarios e informes innecesarios sobre ellos. Es mejor evitar el error antes de que el código llegue al equipo de prueba, ¿verdad?

Algunas palabras sobre probar su propio código. Creo que los desarrolladores deberían al menos hacer pruebas de humo de su código. No se necesitan pruebas exhaustivas. Simplemente verifique que el código funcione en algún conjunto de datos de entrada y déselo al equipo de prueba para que ya trabajen en él.

Si el código no funciona ya en esta etapa, ¿por qué entregarlo al control de calidad? Recibirá docenas de mensajes de error a pesar de que ya sabe que hay problemas; esto solo ralentizará el proceso de desarrollo.

Perdimos el error. ¿Son los probadores los culpables?

Si y no Cada vez que se detecta un error, especialmente en producción, usted y su equipo tienen algo que discutir. Hay varias razones por las que el error apareció solo en esta etapa:

1. El lugar donde apareció el error nunca fue una prioridad para los evaluadores. Muy a menudo, nadie pensó en el error que apareció en la producción. Este es el resultado de una falta de comunicación entre desarrolladores y evaluadores. No se llegó a un entendimiento mutuo sobre la importancia de verificar un área. Ejemplos clásicos de esta negligencia son los problemas de rendimiento y seguridad. Si sabe que estas áreas son críticas para su aplicación, avísele al equipo.
2. QA no tiene el conocimiento necesario en el área probada. Este también es un problema común. Los desarrolladores escribieron la función y asumieron automáticamente que QA comprende cómo funciona desde y hacia. Bueno, hacer suposiciones nunca ha sido una buena estrategia para analizar la calidad de un proyecto serio. Si ve algún aspecto importante, asegúrese de que el ingeniero principal de control de calidad y su equipo también lo vean y lo entiendan. No hay forma de evitar este paso.
3. A los desarrolladores realmente no les importa. Todos somos humanos. Y todos tenemos una vida fuera del trabajo. Algunos desarrolladores trabajan arduamente para crear un producto de alta calidad, hablan con los evaluadores, les informan sobre posibles problemas y cosas por el estilo. Y hay desarrolladores a los que no les importa. No usan este producto todos los días y no entienden su importancia. Para ellos, esta es solo una tarea paralela que debe completarse y olvidarse de ella. En pocas palabras, no les importa que el producto final sea de calidad inadecuada.
4. A los ingenieros de control de calidad no les importa. Aquí está la otra cara de la moneda. No todos los evaluadores se preocupan por el proyecto. Algunos solo necesitan terminar la prueba, hacer un informe hermoso y olvidarse de él. La cobertura de prueba de alta calidad no les molesta, no quieren comunicarse con los desarrolladores. Puede hablar sobre errores, pero es posible que dichos evaluadores simplemente no los encuentren importantes o incluso se registren.
5. Los probadores no están lo suficientemente calificados. Otro problema puede estar en el hecho de que los evaluadores simplemente no están lo suficientemente calificados para probar su aplicación. Por ejemplo, debe realizar pruebas de penetración, y todo lo que está a su disposición es un equipo de evaluadores que solo pueden realizar pruebas manuales. En este caso, simplemente no sabrán cómo acercarse a él. Aquí debe confiar en los desarrolladores o seleccionar más
   Ingenieros calificados de control de calidad que sabrán exactamente cómo probar esta área en particular.
6. Falta de investigación de usuarios. Los desarrolladores saben cómo crear una aplicación, y los ingenieros de control de calidad cómo romperla. ¿Qué hay de los usuarios? Los usuarios son personas reales que usarán su aplicación en el mundo real. No lo van a romper. Es solo que todos son diferentes y tienen objetivos diferentes, pero todos quieren lograrlos usando su aplicación. Los ingenieros de control de calidad pueden acostumbrarse al error y darse cuenta de que ocurre con poca frecuencia, por lo tanto, no importa mucho. El usuario no lo tolerará. Si su aplicación falla, el siguiente paso es eliminarla y luego buscar una alternativa. Esa es la realidad. Investigar una audiencia de usuarios y / o tener un grupo de usuarios de prueba son dos cosas estratégicamente importantes.
7. Mala organización del proceso de comunicación. Idealmente, necesita un proceso simple para clasificar errores que le permita evaluar los errores del control de calidad (o al menos clasificarlos correctamente) y pasarlos a los desarrolladores para que comprendan su carga de trabajo. Cuando hay algún malentendido, el probador y el desarrollador siempre deben poder acercarse y resolver este problema en unos pocos minutos u horas. Si este proceso no se establece y ambas partes no tienen prisa por buscar la causa del malentendido, entonces no saldrá nada bueno. Ambas partes imitarán actividades, pero en realidad ambos estarán en un callejón sin salida y esperarán a que alguien más pueda venir y resolver mágicamente la situación. Este es fundamentalmente el enfoque equivocado.
8. No hay suficientes evaluadores. Una aplicación puede ser compleja y puede requerir pruebas en múltiples plataformas y navegadores. Solo unos pocos ingenieros de control de calidad para esta tarea pueden no ser suficientes. Considere contratar a más personas o redistribuir los recursos que tiene de tal manera que aumente el énfasis en las pruebas.
9. Los desarrolladores están sobrecargados. A su alrededor pueden ser especialistas ideales y altamente calificados, pero trabajan en constante estrés y nadie puede ayudarlos. Sí, están bajo presión y simplemente no tienen tiempo para hablar con el equipo de control de calidad. Este es un problema muy común y esta es una de las principales razones por las que el software es de baja calidad.
10. La calidad no está en el centro de atención. Considere este escenario también. Aquí y allá había un par de errores menores. Ninguno de ellos es crítico. Sin embargo, a los usuarios no les gusta la aplicación. Las críticas son malas. UX está por debajo del promedio. Y por que Sí, porque nadie pensó en crear un producto de calidad. Los desarrolladores hicieron su trabajo, los probadores hicieron el suyo, pero nadie siguió el proceso de control de calidad. El desarrollo de aplicaciones debe combinar equipos, convirtiéndolos en un todo. Si el colectivo no tiene ese estado de ánimo, a nadie le importa la calidad.

Conclusión

Hoy en día, las aplicaciones son cada vez más difíciles. Si desea encontrar a quién culpar por el fracaso del proyecto, es fácil. La culpa puede ser ingenieros de control de calidad, desarrolladores y ejecutivos. O todos juntos. La pregunta principal es ¿por qué debemos buscar a los culpables en lugar de asumir la responsabilidad de la calidad del proyecto? Cualquiera que no se haya dado cuenta de la importancia de probar una función específica puede estar en el lugar del culpable.

La única pregunta debería ser: "¿Estamos haciendo un producto realmente bueno?" . Si la respuesta a esta pregunta es sí, entonces no debe haber ninguna duda de que todos los equipos están haciendo una gran cosa.

Nadie tendrá la culpa y todos estarán felices, ¡porque el aseguramiento de la calidad es una tarea común!