¿Cuáles son los diversos conjuntos de habilidades que debe tener un probador de automatización? Cosas Personales

Los siguientes puntos enumeran lo que un probador debe tener en cuenta al comenzar con las pruebas de automatización.

Averiguar qué casos de prueba necesitan ser automatizados

Cada aplicación, dependiendo de su complejidad, puede tener numerosos casos de prueba. Pero todos estos casos de prueba no se pueden automatizar.
Los casos de prueba que son de menor importancia o que se usan raramente en la aplicación pueden mantenerse a un lado y cubrirse como parte de las pruebas manuales.
Las pruebas que manejan la validación y la comparación de grandes listas de datos deben considerarse para la automatización.
Por ejemplo, el filtro de precios en aplicaciones de comercio electrónico muestra productos dentro del rango de precios mencionado. Como el gran volumen de productos puede estar bajo cualquier rango seleccionado, verificar el precio de todos y cada uno de los productos no es lógico. Por esta razón, la verificación de respuestas de filtro válidas debe automatizarse.
Los casos de prueba que requieren mucho tiempo y esfuerzo para ejecutarse también deben convertirse en scripts de automatización.

Usando la herramienta de automatización correcta

La herramienta de prueba de automatización que se utiliza en un proyecto decide qué tan estables y valiosos serían los próximos scripts.
Hay muchas herramientas de automatización diferentes disponibles en el mercado, y el número aumenta cada día. Cada una de estas herramientas posee un sabor propio y proporciona una clara ventaja sobre la otra. Pero a pesar de la disponibilidad de una amplia variedad de herramientas, el equipo de control de calidad debe elegir la que mejor se adapte a sus necesidades.
Si se selecciona aleatoriamente una herramienta de prueba de automatización, puede tener consecuencias desastrosas. Seleccionar impulsivamente una herramienta de prueba de automatización no solo puede crear obstáculos en intervalos cortos, sino que incluso puede llegar a ser un obstáculo para la automatización de aplicaciones en el futuro cercano.
Bajo cualquier circunstancia, la selección de la herramienta de automatización debe depender de la aplicación que necesita ser automatizada y la preferencia del equipo de control de calidad. Algunos de los criterios para la selección son:
Dependencia tecnológica : al seleccionar la herramienta de prueba de automatización, se debe tener en cuenta la tecnología y la plataforma de la aplicación. ¿Es una aplicación .Net o Java? Dichas preguntas deben ser respondidas primero, para conocer el alcance de la aplicación que debe ser cubierto.
Sistema operativo y plataforma : ¿se trata de una aplicación web, móvil o híbrida? Esta respuesta puede ayudar a reducir la herramienta adecuada para las pruebas de automatización. En el caso de aplicaciones móviles, dependiendo de la plataforma, Android, Windows o iOS, se debe seleccionar la herramienta.
Habilidad técnica en el equipo : si los miembros del equipo de control de calidad carecen de experiencia en programación, se debe usar una herramienta que sea fácil de usar y que no requiera mucha codificación para crear scripts. Bajo tales escenarios, los marcos de prueba basados en palabras clave serían la opción correcta.

Pruebas repetitivas

Usando herramientas de pruebas de automatización, las pruebas se pueden ejecutar sin la necesidad de mucha intervención manual. Entonces, para obtener el mayor beneficio, estas pruebas deben ejecutarse con frecuencia.
Esto no solo mantendrá la aplicación estable, sino que también puede incitar al equipo de control de calidad en una etapa temprana si se encuentran problemas importantes. Tales problemas detectados temprano son más fáciles y mucho más baratos de solucionar que en una etapa posterior, cuando la compilación se traslada a producción.
Como todas las pruebas automatizadas no se pueden construir de la noche a la mañana, se debe considerar como un proceso incremental. Por ejemplo, una vez que se crea un único script de prueba de automatización, debe ejecutarse al menos diariamente. Con cada día que pasa, a medida que se crean nuevos scripts, también deben agregarse al grupo de pruebas ejecutables.
Generalmente se accede a las aplicaciones web utilizando diferentes navegadores. Cada aplicación tiene una lista de navegadores favoritos. Como probar manualmente todas y cada una de las características de la aplicación en diferentes navegadores es una tarea engorrosa, tales escenarios deben automatizarse en diferentes navegadores, para validar la compatibilidad del navegador de la aplicación.

Utilización de recursos de prueba

El tiempo de cada recurso de prueba es precioso. Por lo tanto, las tareas de pruebas de automatización deben asignarse de tal manera que se creen secuencias de comandos efectivas y de calidad de manera eficiente en breves duraciones.
Si pocos miembros del equipo de control de calidad tienen un mejor conocimiento de programación, deberían participar en la creación de los scripts de prueba de automatización. Mientras que otros probadores pueden participar en la fabricación de los casos de prueba.
Una vez que se automatizan un par de casos de prueba, los miembros que escribieron los casos de prueba pueden revisar el código y contar con la ayuda de los otros miembros del equipo para comprender la lógica detrás del código.
A medida que aumenta el número de pruebas de automatización, también lo hará la transferencia de conocimiento, y gradualmente la mayoría del equipo de control de calidad tendrá una comprensión decente de la práctica de codificación a seguir al crear dichos scripts.

Crear datos de prueba de calidad

La mayoría de la automatización se ocupa de las entradas de datos de los usuarios. Para automatizar con éxito tales aplicaciones, es muy importante elegir el conjunto correcto de datos de prueba.
Los datos de prueba que se utilizan para automatizar diferentes escenarios deben parecerse mucho a los datos utilizados por los clientes después de cada lanzamiento o por usuarios ficticios durante las pruebas de aceptación del usuario.
Dichos datos de prueba deben solicitarse al cliente para agregar más valor a las pruebas automatizadas.
Si obtener tales datos del cliente no es una opción viable, los datos externos deben usarse de diferentes fuentes. Se pueden asignar diferentes entradas para cada campo en una hoja de Excel externa, que a su vez sería utilizada por el script de automatización.
Dicha práctica crearía datos bien estructurados y ayudaría a probar cada campo contra diferentes conjuntos de datos. Cuanto antes se creen dichos datos de prueba, mejor.

Prueba de automatización independiente de la interfaz de usuario

En casi todos los proyectos, uno u otro componente de la IU se ve afectado debido a los cambios realizados en cada compilación. Dichos cambios no solo hacen que el script de automatización sea inestable, sino que también requieren mantenimiento.
Si un proyecto tiene ciclos de lanzamiento cortos, los scripts de automatización dependientes de la interfaz de usuario pueden verse muy afectados, y su reparación puede requerir un amplio esfuerzo de control de calidad. La mejor opción es centrarse en los scripts de automatización que no dependen de la interfaz de usuario de la aplicación.
Probar las entradas de la base de datos y la interacción de la aplicación con el back-end a través de la automatización es una de esas formas. Si la aplicación usó alguna API, la respuesta se puede validar contra un conjunto de solicitudes.

Planificación de automatización adecuada

Cuando el equipo de control de calidad ha seleccionado la herramienta de automatización, deben comenzar a crear un plan de prueba para la automatización.
Aunque la automatización agrega mucho valor y mejora la eficiencia de las pruebas del proyecto, si no se planifica bien, las pruebas automatizadas no serían beneficiosas .
Los objetivos del proyecto deben tenerse en cuenta al planificar los scripts de automatización.
Como se muestra arriba, un gráfico de valor vs esfuerzo puede ser realmente útil para descubrir las pruebas que primero deben automatizarse.
El gráfico muestra dos curvas. La punta de la curva roja representa los scripts de automatización que tienen un alto valor y requieren menos esfuerzo para crear, y el final significa los scripts que tienen un bajo valor y un gran esfuerzo.
En el caso de la curva verde, su punto de partida muestra el guión que tiene menos valor y requiere menos esfuerzo, mientras que el final de la curva muestra las pruebas que requerirían un esfuerzo considerable para automatizar, pero serían de alto valor.
Una vez que se calculan el valor y el esfuerzo necesarios para crear scripts de pruebas de automatización, primero deben automatizarse los scripts de alto valor y bajo esfuerzo. Esto asegurará que las principales funcionalidades sean automatizadas y probadas a menudo desde una etapa temprana .

Gracias,
Vaibhav (Fundadores Helping Testers | Cursos de capacitación en pruebas de software en línea)