Analizamos en detalle cómo realizar pruebas manuales cuando es mejor que las pruebas automatizadas, qué deben hacer los probadores y cómo pueden desarrollar sus carreras desde junior hasta líder de prueba. La guía fue preparada conjuntamente con el jefe del departamento de pruebas de Agima Darina Gordeeva.
Hola Me llamo Darina Gordeeva. He estado trabajando en la empresa AGIMA como jefe del departamento durante casi 3 años. En el campo de las pruebas y el aseguramiento de la calidad durante más de 6 años. Durante este tiempo, pasó de ser junior a jefe de departamento, probando hierro, así como aplicaciones móviles y web, automatizando y configurando procesos de control de calidad. Hoy les contaré sobre las características, capacidades y problemas ocultos de las pruebas manuales.
Recuerde que cualquier lector que haya usado la palabra promocional Habr puede obtener un descuento de 10,000 rublos para su curso favorito, mientras que los más diligentes y atentos pueden obtener un descuento de 25,000 rublos resolviendo acertijos de materiales preparados conjuntamente con la agencia Agima:
Eficiencia, flexibilidad, posibilidad de improvisación y otras ventajas.
Hoy en día hay muchos marcos de prueba que admiten casi todos los idiomas existentes. Parece que puedes tomar y automatizar. Pero incluso ahora, las pruebas manuales son importantes.
Una de las explicaciones de su necesidad es que con las pruebas manuales de lo funcional, podemos obtener información sobre el estado del producto que estamos analizando mucho más rápido, sobre la calidad del desarrollo. Además, durante la automatización, los casos prediseñados a menudo tienen que cambiarse y actualizarse, y lleva tiempo escribir autotests.
Al mismo tiempo, durante el proceso de desarrollo, puede recibir comentarios del cliente cuando ve alguna función en el producto terminado que decide cambiar antes del lanzamiento, y si ya ha preparado pruebas de software para el mismo, tendrá que volver a escribirlas. La actualización de casos, las pruebas automáticas y la verificación de ellos requerirán un tiempo valioso que podría usarse para actualizar esta función.
Todo esto significa que el objetivo principal de las pruebas manuales es primero asegurarse de que la funcionalidad declarada sea funcional, no tenga errores y proporcione los resultados planificados esperados. Sin ellos, no puede estar seguro de poder trabajar. Esto es especialmente cierto para funciones para la implementación de las cuales el desarrollo posterior está vinculado. En este caso, el alboroto con la creación de pruebas automáticas para estas características se convierte en un factor de bloqueo para todo el desarrollo del producto, cambiando los plazos y alterando los plazos. El momento en que llegue el momento de automatizar los casos llegará tarde o temprano, pero no intente llevarlo artificialmente en busca de la excepción total del trabajo manual.
Además, en las primeras etapas del desarrollo de aplicaciones, la automatización puede ser bastante costosa. Necesitará un especialista con calificaciones específicas (y posiblemente más de uno). Mantener las pruebas actualizadas constantemente requiere recursos hasta el lanzamiento de la función. Y los meses de inactividad dedicados a lamer una prueba automática afectarán la motivación del equipo.
Si desea agregar regularmente nuevas funcionalidades y mantenerse al día con las acciones de los competidores, antes de crear pruebas automáticas siempre verifique las capacidades del producto manualmente. Solo porque las pruebas manuales aceleran sus procesos.
Esto es especialmente cierto para el desarrollo móvil. La mayoría de estos proyectos ahora se están desarrollando en carreras cortas, lo que significa que las características se están implementando a un ritmo acelerado. En tales condiciones, las pruebas manuales le permiten dar retroalimentación al equipo lo más rápido posible: para informar la presencia de errores, o para complacerlo con el hecho de que todo está bien y puede seguir adelante. Puede realizar una serie de pruebas automáticas más adelante, cubriendo grandes matrices de código con su ayuda. Las pruebas manuales ayudarán a preparar los casos para esta prueba.
Las pruebas automáticas no le permiten verificar si es conveniente utilizar las nuevas funciones de la aplicación: las pruebas de usabilidad siempre se realizan manualmente.
Skillbox recomienda: El curso en línea Fullstack es un desarrollador móvil .
En las pruebas manuales, puede improvisar, creando combinaciones locas de acciones que nunca se le ocurren al usuario, pero que puede cometer accidentalmente. Esto le permite crear nuevos casos.
También aparecen nuevos casos porque el probador constantemente se hace la pregunta "¿y si?". Por lo tanto, encuentra formas originales de interactuar con la aplicación, incluso si no estaban en los escenarios base.
Problemas de prueba manual y sus soluciones.
La mayor desventaja de las pruebas manuales es el factor humano. Por supuesto, afecta todo lo que sucede en el equipo, tanto el trabajo de los participantes como los eventos que ocurren en el lado del cliente. En el caso del control de calidad, la razón por la cual el evaluador está débilmente inmerso en el proceso y pierde un error potencial puede ser cualquier cosa: falta de experiencia, problemas familiares o dolor de cabeza.
Dos probadores pueden probar el mismo escenario de diferentes maneras. ¿Qué hacer al respecto? Es importante que se espere que cada resultado inesperado o diferente se registre como un caso. Para que cualquier probador pueda probarlo haciendo el mismo conjunto de acciones. Pero esto puede no ser suficiente, si el caso no es lo suficientemente detallado y el probador no comprende la descripción. Por supuesto, es imposible garantizar la exclusión absoluta del factor humano, pero puede intentar minimizar la probabilidad de los problemas que causa.
Esto también afecta negativamente los términos de entrega de características en los costos de producción y mano de obra: después de todo, ahora los casos "difíciles" inventados por los probadores en el proceso se agregan a casos básicos y regresiones realizadas periódicamente.
La situación se ve agravada por la probabilidad de que algunos de los errores encontrados aún no tengan una descripción estricta porque las razones de su aparición aún no están claras. ¿Cómo lidiar con tales reevaluaciones? O encuentre la fuente del error y elimínelo, o, aún automatice el paso de casos problemáticos, en este caso, la transición a las pruebas de software se justificará tanto en términos de tiempo como financieramente. (No, esto no contradice lo anterior, porque tales situaciones surgen ya en el curso del desarrollo activo y en este momento, en cualquier caso, implementará procesos de prueba automáticos).
En cualquier caso, la aparición de los primeros casos que necesitan pruebas de regresión o el lanzamiento de la segunda versión de la aplicación y la escala del equipo correspondiente a estos eventos es el momento en que la automatización se vuelve relevante (pero no excluye la prueba manual de nuevas características). En esta etapa, la automatización ya comenzará a ahorrar tiempo: el propio desarrollador, incluso antes de la transferencia al departamento de control de calidad, puede ejecutar las pruebas de regresión de la nueva función para asegurarse de que no rompa la funcionalidad existente, y el probador no tendrá que pasar por los casos básicos que se aburrieron nuevamente. Otra ventaja de implementar las pruebas automáticas en esta etapa es que puede ejecutarlas de acuerdo con un cronograma específico: todas las noches, los días del final de los sprints o al publicar nuevas compilaciones de la aplicación.
Al mismo tiempo, uno no debe olvidar algunas cosas:
- crear casos y escribir autotests llevará tiempo: colóquelo en sprints;
- asegúrese de que el caso de autotest esté bien escrito y detallado y describa un posible problema o escenario existente en su totalidad;
- compruebe si la prueba automática funciona correctamente y si realmente comprueba lo que se necesita y lo hace de forma cualitativa.
Resumimos: las pruebas manuales brindan una gran ventaja en los costos de velocidad y mano de obra en las primeras etapas, y a medida que la aplicación crece y aparece una gran cantidad de pruebas de regresión, entra en la categoría de "pruebas operativas" de nuevas características dentro de un sprint separado. Será relevante y, si es necesario, verifique con urgencia cómo responderá la aplicación a los cambios en el sistema operativo o la actualización del entorno.
Etapas de prueba: qué, cuándo y cómo
Si observa el proceso de desarrollo en su conjunto y las pruebas como una de sus partes, con una planificación adecuada siempre comprenderá qué y cuándo estará listo. Esto le permitirá planificar mejor el tiempo de ciertas acciones, ya que algunos eventos siguen lógicamente a otros y tiene la oportunidad de organizarlos en cadenas según sus expectativas.
El probador aparece en el proceso de creación de la aplicación en las primeras etapas. Aquí el cliente tiene una cierta idea, los analistas de negocios recogen de este requisito, y los evaluadores ya en este momento comienzan a trabajar, verificando estos requisitos.
¿Cómo va esto? Hacen preguntas sobre la funcionalidad prevista. Están tratando de imaginar cómo se verá la aplicación cuando se implemente. Si hablamos de una nueva característica en un producto existente, ellos descubren cómo interactuará con la funcionalidad existente. Después de que los desarrolladores evaluaron la complejidad de las ideas del cliente y determinaron cuánto tiempo se requiere para su implementación.
Después de eso, comienza la fase de diseño. Aquí se hace necesario comprender cómo se llevarán a cabo las transiciones entre pantallas, ciertos campos a validar, cómo la aplicación o su función separada generalmente interactuarán con el usuario final. En el caso de las características, es importante comprender cómo se incluirán en la arquitectura de una aplicación existente.
En la etapa de diseño , cuando se crea un mapa de transiciones entre pantallas, el probador aclara el comportamiento de los elementos individuales en los que consisten y qué efectos visuales acompañarán ciertas acciones del usuario. Además, el probador valida la integridad de los diseños y confirma que muestran todo lo necesario para implementar la funcionalidad deseada. También será útil verificar independientemente los diseños para el cumplimiento de las pautas.
Skillbox recomienda: curso en línea Diseño de aplicaciones móviles
Con el comienzo del desarrollo, los especialistas en control de calidad comienzan inmediatamente a escribir casos de prueba. En diferentes etapas de desarrollo, pueden tener un nivel de detalle diferente, pero al final es deseable garantizar la máxima cobertura de todos los casos de productos, de modo que, una vez recibido el ensamblaje, pueda comenzar a probar de inmediato.
El primer paso de la prueba en sí es la prueba de humo: una evaluación de que la aplicación o su nueva parte generalmente está lista para la verificación. Una prueba de humo es una prueba de si una aplicación o una función específica se inicia en principio.
Una prueba de humo es una forma rápida de ver si incluso podemos comenzar las pruebas funcionales. El término proviene de los creadores de placas de circuito y microcircuitos, que primero tenían que asegurarse de que el nuevo circuito no se quemara, de ahí el nombre: ahumado / no ahumado.
Esta es una forma rápida de asegurarnos de que realmente hemos superado la tarea y de que puede llevarse a cabo en el trabajo y no enviarse de vuelta a los programadores.
Usando el formulario de autorización como ejemplo, fumar es una evaluación de si puede iniciar sesión, sin especificar si los datos ingresados en los campos son válidos, si funcionan características adicionales como recordatorios de contraseña y otras cosas. Si pudimos iniciar sesión en principio, podemos proceder a una verificación más profunda y profunda de este módulo: tomar casos negativos, valores límite, evaluar el cumplimiento de las reglas de validación establecidas.
La siguiente etapa es realizar pruebas de regresión. En modo manual o automático, se lleva a cabo el conjunto principal de pruebas planificadas previamente.
La prueba de regresión es buena porque le permite encontrar errores incluso en aquellos lugares donde todo estaba en orden antes. Esto se debe al hecho de que la regresión es una evaluación de la funcionalidad en un conjunto estándar de casos durante la implementación de cada nuevo módulo y cada cambio de aplicación. De hecho, cuando los desarrolladores agregan nuevas funcionalidades, la versión actual puede dañarse o una nueva característica puede entrar en conflicto con las existentes.
Por ejemplo, agregar nuevas pantallas y, por lo tanto, cambiar la navegación, puede interrumpir el funcionamiento del menú, o al menos mostrarlo. Por otro lado, la refactorización global del código de la aplicación puede traer sorpresas desagradables; después de eso, también es necesario realizar pruebas de regresión.
Se pueden ocasionar problemas al actualizar la biblioteca utilizada por la aplicación y cambiar el entorno en el que funciona. Cuanto más a menudo actualice la aplicación, más importantes serán las comprobaciones de regresión. No se limite a una verificación única, realizada cuando la función ya está implementada; verifique todos los cambios. La automatización de las pruebas de regresión lo ayudará aquí, simplemente porque las pruebas de regresión manual de una nueva función que se creó en solo una semana pueden tomar dos, o incluso más, y el departamento de pruebas simplemente se atascará en esto.
Por supuesto, se realiza una verificación completa cuando el candidato de lanzamiento con una o más características está listo para lanzarse a producción, pero aún es necesario aplicar ciertos casos relevantes en ciertas etapas de desarrollo.
Todo termina con la prueba de la asamblea final : candidato de lanzamiento. Esto incluye verificar la versión beta por probadores internos, pruebas comerciales: evaluar el producto resultante por parte del cliente y recibir comentarios de él, así como invitar a un determinado grupo de usuarios a familiarizarse con la versión alfa previa al lanzamiento de la aplicación o sus nuevas características. Después de eso, la aplicación está lista para implementarse en producción.
Pero el trabajo del especialista en control de calidad no termina ahí : tendrá que probar las actualizaciones de la aplicación y su compatibilidad con versiones anteriores, compilar casos para verificar las innovaciones y, si es necesario, automatizar el paso de estos escenarios.
Paralelamente, los evaluadores participan en un análisis adicional de las estadísticas recopiladas por los analistas, monitoreando el comportamiento de la aplicación y cómo los usuarios interactúan con ella. Esto permite no solo ver el uso en vivo de los resultados de su trabajo, sino también, a veces, descubrir nuevos escenarios y errores desconocidos que hacen que la aplicación se bloquee.
Tiempo de Rebus: adivine y un descuento del diez por ciento en cualquier curso de Skillbox lo está esperando en este momento o muestre perseverancia y recopile respuestas a todos los rechazos: estos descuentos se suman entre sí (pero sin otros descuentos en los cursos de Skillbox).
Sin embargo, no debe retrasarse demasiado: la promoción funciona hasta el 30 de agosto de 2018. Recuerde que el tema del enigma es un móvil, y las palabras en inglés pueden interferir con el ruso aquí, ¡así que tenga cuidado! Envíe una solicitud para el curso, y cuando el gerente se comunique con usted, entréguele un mensaje, encriptado en un acertijo (¡o algunos!).
Formalización de la prueba: plan de prueba, formato de informes de errores, informes
Para prepararse para las pruebas funcionales, un ingeniero de control de calidad elabora un plan de prueba. Esta es la documentación que necesitará al probar el producto, una lista de acciones que deberá realizar. El plan de prueba indica el momento de la prueba, describe el producto o una tarea específica, con el fin de determinar exactamente lo que debe verificarse. Todos los casos de prueba principales se describen en detalle. Enumera los tipos de pruebas necesarias: funcionales y, por ejemplo, de estrés. Se describe el procedimiento para automatizar ciertos casos y las etapas en las que se automatizarán.
El plan de prueba termina con una descripción del formato del informe: debe explicar por adelantado de qué forma se proporcionará el resultado. El formato de informe más común es una lista de casos de prueba con el estado de su aprobación. Sabiendo cómo los casos cubren todo el volumen de requisitos y después de leer el informe, podemos concluir sobre el estado actual del desarrollo de la aplicación. Para hacer esto, será suficiente ver cuántos de ellos se completaron con éxito en uno u otro ensamblaje.
El visto bueno final, que indica que el producto está listo, es el estado "todos los requisitos están cubiertos por casos, todos los casos se completaron con éxito".
Además, el plan de prueba formaliza el formato del informe de error. Esto puede ser una lista de errores, una lista de tareas en el rastreador.
La tarea del probador es proporcionar la información más completa sobre la calidad del producto a todos los miembros del equipo.
Lo que necesita saber y poder convertirse en un probador
En primer lugar, el probador debe ser capaz de pensar y estar atento y asiduo. La experiencia es importante: le permite acumular ciertos logros y consolidar el conocimiento de los procesos de prueba, convirtiéndolos en habilidades.
Un especialista en pruebas manuales no tiene que poder escribir código y tener un conocimiento profundo de la arquitectura. Esto no le impide comprobar la funcionalidad y comprender los principios de interacción entre la aplicación y el servidor a nivel de la aplicación.
Un especialista en pruebas automatizadas es una profesión separada, con un conjunto de conocimientos completamente diferente. — , , , , , , . “ ”. , , .
, , . , — -. — , , — , . -. - . , .
( , ) , , . — , -.
- — , , , .
-, , — — . , .
— -. , , — , , .
- — -. , , , , , DevOps, , .
— , “Fullstack- ”. , . !
Skillbox recomienda: