QA Manual hacia la Automatización

Como implementar la automatización en los casos de prueba Manuales

En la era de la automatización, cada compañía está en camino de convertir sus casos de prueba manual en pruebas automatizadas para aumentar la eficiencia y hacer que el proceso sea rentable. Es relativamente fácil embarcarse en el viaje de automatización; simplemente seleccione los casos de prueba adecuados y determine su retorno de la inversión (ROI). Sin embargo, la automatización no eclipsa las pruebas manuales; de hecho, aumenta las pruebas manuales.

La automatización también necesita una estructura adecuada, planificación meticulosa, monitoreo y mantenimiento, al igual que las pruebas manuales. Ayuda en las pruebas de rutina y en la preparación de casos de prueba. La automatización comienza con la realización de una ronda de pruebas manuales, lo que significa que los casos de prueba manual ya deben existir y se ejecutan al menos una vez.

Aquí le mostramos cómo puede seleccionar los casos de prueba adecuados para las pruebas de automatización:

  • Identifique los parámetros en función de los cuales puede seleccionar los casos de prueba.
  • Las aplicaciones deben dividirse en módulos. Para cada módulo, los casos de prueba que necesitan ser automatizados son verificados y analizados.
  • Integre y combine casos de prueba para cada módulo.
  • Calcule el ROI logrado a través de pruebas de automatización .

Traducción de casos de prueba manuales en scripts de automatización

Paso 1: realizar y ejecutar

Este paso es esencial en dos escenarios:

  • Para comenzar la prueba
  • Para ejecutar una prueba determinada

Paso 2: Divida los casos de prueba manual

Los casos de prueba manual se pueden dividir en tres grupos:

1. Entrada de datos: aquí es donde ingresamos información como entrada para pruebas automatizadas.

2. Pasos de cambio de estado de automatización: estos métodos harán un cambio en su prueba automatizada. Puede incluir ir a otra página o hacer que un campo en particular sea distinto.

3 . Combinación: como su nombre lo indica, esta es una mezcla de los dos campos anteriores. Tomemos un ejemplo de una casilla de verificación: cuando se hace clic en él, hará que un campo en particular sea dinámico. Todo lo analizado, está ingresando la consideración «Válido» para el campo de casilla de verificación y además trae una condición de su AUT.

Paso 3: realizar pasos lógicos

Los pasos de entrada de datos son similares en automatización y pruebas manuales. Dado que es la máquina la que va a realizar los pasos, uno simplemente debe asegurarse de que la máquina entienda los campos referidos en la prueba automatizada. Es preferible usar un nombre lógico como se usa en el código. En la automatización, debemos agregar pasos para la acción y la verificación.

Paso 4: verificar y validar

Es muy importante verificar y validar el campo; sin esto, se pierde el propósito de la prueba. Debe usar puntos de control como declaraciones condicionales y bucles para construir la lógica.

Paso 5: prueba los requisitos

Aquí hay algunas preguntas que se deben considerar para probar los requisitos:

  • ¿Dónde deberías colocarlos?
  • Ya sea para hardcore o no?
  • ¿Cuáles son las preocupaciones de seguridad?
  • ¿Cuáles son las preocupaciones de reutilización?

Cuando vuelva a mirar los scripts de prueba manual, verá que tener automatización de prueba, nombre de usuario y contraseña son condiciones previas para comenzar la prueba.

Paso 6: evaluar los resultados de la prueba

En las pruebas manuales, puede mantener el resultado de cada paso en una columna de resultados real, mientras que, en la automatización, el resultado se almacena cuando se ejecuta.

Paso 7: Post-Operación

Cuando finaliza la prueba, no es necesario cerrar el programa en las pruebas manuales, pero para la automatización, uno tiene que limpiar ejecutando cada asociación que hizo, cerrando el programa y liberando la memoria.

Las pruebas de automatización actúan como una columna vertebral para las pruebas manuales. La automatización también aumenta la eficiencia, la efectividad y la cobertura de las pruebas. Como resultado,  una metodología efectiva de automatización de pruebas mejora el ROI .

Desafíos enfrentados en la transformación de los casos de prueba de manual a automatización:

  • La necesidad de automatización:  incluso si no puede cambiar una práctica establecida, puede cambiar una práctica para satisfacer la necesidad. Debido a esto, la automatización requiere la colaboración del equipo de gestión y desarrollo.
  • Automatizar una aplicación en su conjunto: Automatizar una aplicación por completo es una tarea difícil que requiere mucho tiempo, una planificación y supervisión adecuadas.
  • Mentalidad de manual a automatización: se deben determinar los criterios en los que los casos de prueba se pueden segregar en función de la demografía u otras categorías que el cliente tenga en mente, como la lógica empresarial, los factores de riesgo y más.
  • Diseño del marco: el diseño y el uso del marco adecuado es el factor más importante de las pruebas. En lugar de centrarnos en las secuencias de comandos, debemos prestar atención a cómo diseñar un marco que facilite las secuencias de comandos y el mantenimiento.
  • Conocimiento del equipo: el equipo debe estar bien versado y asumir plenamente la responsabilidad de la automatización, ya que esto mejorará la habilidad de cada recurso.

Varias   herramientas automatizadas de prueba de software juegan un papel muy vital para lograr el ROI deseado. Podemos elegir la automatización por fases y podemos seguir un modelo prototipo adecuado para la automatización. Es importante convertir los casos de prueba manuales en casos de prueba de automatización para aumentar la eficiencia y disminuir el costo. También ayuda a entregar el producto final requerido y sin errores a tiempo.

Guido Miranda mercado es ingeniero informatico y especialista en procesos Automaticos para QA y Desarrollo. Puedes seguirlo en Twitter en @guidomiranda o leer sus blog.

El largo camino hacia la seguridad el ciclo de vida del desarrollo (III)

Tu centro de expertise en España sobre Quality Engineering y Testing

En las anteriores entradas nos hemos referido a la seguridad en el desarrollo como parte de una actitud ante la seguridad y una serie de mecanismos a implementar en la metodología que predisponen a la adopción de un modelo seguro. No en vano cada uno de los puntos llevaba su correspondiente carga de seguridad asociada. Muchos de estos mecanismos pueden haber sido adoptados por el equipo de desarrollo, pero cabe plantear en primer lugar si se ha seguido una metodología organizada que permita asegurarse de la correcta implantación de todos ellos sin dejar ninguno en el tintero y en segundo lugar cual es la importancia de una buena seguridad en el desarrollo que ocupa al equipo en cada momento.

Ver la entrada original 670 palabras más

¿De qué tecnologías te has enamorado?

saliendo de tecnologias MS, Python, es un lenguaje que enamora a calquiera que haya usado C (o haya picado piedra en otros lenguajes)

Artículos y tendencias sobre soluciones tecnológicas

Llevo 16 años dedicada profesionalmente al mundo del desarrollo de software. No voy a descubriros lo mucho que han cambiado las tecnologías durante estos años ni la infinidad de lenguajes, librerías, frameworks que he/ hemos visto aparecer y en algunos casos desaparecer.

Pero hoy 14 de febrero creo que es el día perfecto para hablar de aquellas que he visto de forma más o menos directa  y que de alguna manera puedo decir que:  me han “enamorado”.

Ver la entrada original 619 palabras más

TPI NEXT®, estructurando los procesos de mejora

Tu centro de expertise en España sobre Quality Engineering y Testing

Cuando pensamos en una empresa que quiere mejorar sus procesos pruebas lo primero que se nos viene a la cabeza es la creación de un equipo de pruebas. Muchas veces estamos en lo cierto ya que, junto a la metodología, es el núcleo duro de nuestras actividades. Pero el éxito o fracaso de ese equipo depende de muchos otros factores. Aquí es donde entra en juego TPI NEXT®.

Ver la entrada original 603 palabras más

Quality Characteristics Tmap — Guido Miranda Mercado

CARACTERÍSTICAS DE CALIDAD SOFTWARE 1. Conectividad La facilidad con la que una interfaz se puede crear con otro sistema de información o en el sistema de información, y se puede cambiar. 2. Continuidad La certeza de que el procesamiento de datos continuará ininterrumpidamente, lo que significa que se puede reanudar en un plazo razonable de […]

a través de Quality Characteristics Tmap — Guido Miranda Mercad

Microsoft HoloLens: Holographic computing is here — itblogsogeti

Hace poco menos de un mes, tuve la oportunidad de participar en la Worldwide Partner Conference de Microsoft, que este año se celebró en Toronto del 11 al 14 de julio. De entre todas las ponencias a las que asistí, destacaría especialmente aquellas dedicadas a las Microsoft HoloLens, de las que os hablo a continuación.

a través de Microsoft HoloLens: Holographic computing is here — itblogsogeti

TESTER – EL DETECTIVE PRIVADO EN EL DESARROLLO DE SOFTWARE

Tu centro de expertise en España sobre Quality Engineering y Testing

En post anteriores, he hablado de las características que debe tener un buen tester, como ser analítico y curioso, ser un buen comunicador, tener la capacidad de ponerse en los zapatos del usuario,… Pero últimamente estoy empezando a pensar que la característica más importante que define a un buen tester es ser inquisitivo: indagar y preguntar con perseverancia hasta conseguir la información que se desea obtener para poder probar la aplicación y saber si tiene la calidad esperada. Algo así como un policía o un detective privado que busca pistas e interroga a los testigos para averiguar quién ha cometido el crimen, cómo y por qué.

Ver la entrada original 376 palabras más

INTRODUCCIÓN AL DESARROLLO DIRIGIDO POR COMPORTAMIENTO

BDD es la nueva tendencia en desarrollo agil

Artículos y tendencias sobre soluciones tecnológicas

El Desarrollo Dirigido por Comportamiento (Behavior-driven development o BDD) es una técnica de desarrollo ágil orientada al negocio y comportamiento de una aplicación. Su principal objetivo es preguntar qué debería hacer la aplicación antes y durante el proceso de desarrollo.

Ver la entrada original 779 palabras más