automation - software - mailchimp personalized name
¿Cuándo debe comenzar la automatización? (12)
Quiero comenzar a implementar la automatización. Simplemente no sé si esto sería un buen uso de los recursos. La aplicación está creciendo a un ritmo exponencial, pero no sé en qué punto la automatización beneficia las pruebas.
¿Me puede dar razones de cuándo automatizaría aunque tenga comprobadores manuales?
Haga que las pruebas sean más eficientes, incluso si tiene probadores manuales, si ellos (o usted) pueden implementar pruebas automatizadas, se pueden explorar muchos más casos. Escribir sus propias pruebas automatizadas también puede darle una idea de su propio código.
Imagine que el tamaño del programa y el número de pruebas aumentan linealmente con el tiempo, y que desea realizar pruebas continuas (diarias) de integración y regresión. En ese caso, el primer día probará una cosa, el segundo día probará dos, el tercer día probará tres, etc.
El esfuerzo de prueba total para las pruebas manuales aumentará con el cuadrado del tamaño del programa: debido a una nueva prueba y una nueva prueba.
Si no automatizas, entonces no harás pruebas de regresión regulares y completas.
La automatización es casi siempre una buena manera de realizar pruebas. Las pruebas manuales aún son importantes, pero son mucho más propensas a errores, y si el proceso de prueba manual comienza a tardar días o semanas en completarse, se hace difícil implementar actualizaciones a gran velocidad. Por lo general, es más fácil configurar la automatización al comienzo de un proyecto, porque tendrá menos cosas que automatizar, y una vez que tenga su marco de automatización en su lugar, debería ser fácil expandirse a medida que su proyecto crezca.
Intentar automatizar las pruebas en un proyecto ya implementado en su totalidad probablemente requerirá más trabajo que la automatización desde el principio, por lo que le recomendaría que se sumerja lo antes posible.
La repetición de pruebas es dolorosa y propensa a errores con las pruebas manuales, y si la aplicación se está modificando, las pruebas deben repetirse.
Mi razón para automatizar las pruebas es que esto significa que puedo recibir comentarios constantes, repetibles y oportunos de que lo que acabo de hacer es correcto.
Las pruebas manuales también tienen su lugar, pero es difícil estar tan convencido de que está cubriendo todo correctamente, y ciertamente no lo hace tan rápido como las pruebas automatizadas.
Por ejemplo, parte de uno de mis proyectos es un algoritmo de optimización que utiliza algunas heurísticas para recorrer el espacio de búsqueda en busca de buenas soluciones. Actualmente hay aproximadamente 40 heurísticas diferentes que se pueden usar individualmente o en varias combinaciones, y cada reunión con un cliente parece implicar agregar una nueva heurística o ampliar una existente. Necesito estar absolutamente seguro de que nada de este trabajo para un cliente causará una regresión para otro cliente, lo que implica ejecutar el algoritmo en unos pocos cientos de casos diferentes y verificar que el resultado sea (no peor que) lo que solía ser.
Sería impráctico pedirle a un verificador manual que ejecute todos estos casos de prueba cargando la GUI, abriendo el archivo de entrada y haciendo clic en "ejecutar", al menos no lo suficiente como para ser un mecanismo de retroalimentación útil. Las pruebas se ejecutan típicamente decenas de veces al día para las pruebas cortas y todas las noches para las pruebas de peso pesado. Con un proceso manual, los comentarios completos probablemente tomarían un par de días, y corregir un error introducido hace un par de días es mucho más difícil que corregir un error introducido en la última media hora.
También sería muy difícil garantizar que las comprobaciones "oculares" de los resultados sean tan buenas como solían ser, por lo que las verificaciones de resultados deben ser automáticas. Pero si va a automatizar eso, también puede automatizar todo. No es dificil.
Otra ventaja de las pruebas automáticas, a partir de la experiencia de trabajar con un proyecto sin ninguna, es que si tiene pruebas manuales que no están ampliamente documentadas, entonces cuando el proyecto permanece inactivo (aparentemente en "modo de mantenimiento") durante un año y luego reinicia el desarrollo activo, nadie puede recordar absolutamente cómo hacer las pruebas o cuáles fueron los resultados esperados, y terminas introduciendo un montón de regresiones tontas que tardan años en establecerse. Por otro lado, si va a documentar sus pruebas con suficiente detalle para que puedan ser recogidas un año después, básicamente ya las ha automatizado: solo necesita hacer que la documentación sea ejecutable.
En mi experiencia, necesitas comenzar a probar aproximadamente 2 horas antes del punto en el que de repente te das cuenta de que deberías haber empezado a probar hace 2 horas :)
Usted automatiza porque presionar "ir" y esperar 10 minutos para los resultados significa que su probador puede hacer otro trabajo útil durante esos 10 minutos en lugar de cuidar a la aplicación.
Tenga en cuenta que una prueba automatizada puede ejecutarse todas las noches mientras duerme. Sus evaluadores pueden utilizar sus horas de trabajo para escribir nuevas pruebas útiles en lugar de ejecutar las mismas pruebas una y otra vez.
La razón principal es que cuando cambió algo poco antes del envío, con pruebas automáticas no dudará en ejecutar las pruebas aunque "el cambio fue simple y no debería haber roto nada", y luego respira un suspiro de alivio cuando las pruebas automatizadas detectan el error que usted había introducido y que estaba a punto de enviar.
las pruebas automáticas también pueden comparar e identificar problemas con la interfaz de usuario ... que manualmente ni siquiera se podía hacer clic en eso rápidamente :)
Creo que depende de las personas que trabajan en la empresa. Algunas personas aman la automatización, a otras les gusta menos. Si su empresa no lo tiene ahora, intentar implementarlo podría ser difícil.
Prefiero la automatización, debido a las horas (ya mencionado) y porque la mayor parte del tiempo sabes lo que vas a obtener con eso.
Debería tener ambos, pero ir sin automatización y prueba será muy difícil a medida que el producto crezca.
¿Me puede dar razones de cuándo automatizaría aunque tenga comprobadores manuales?
Automatizaría todo lo que se puede automatizar. ¿Cuál es el valor agregado de usar un cerebro humano para algo que una máquina puede hacer de manera repetible? ¿Y el desarrollo personal? Prefiero usar cerebros humanos para algo que puedan hacer mejor que las máquinas: pensar.
Debe automatizar lo más pronto posible. Muchos estudios han demostrado que cuanto más tarde se encuentre un defecto en el ciclo de desarrollo, más costoso será repararlo. La automatización generalmente hace posible encontrar defectos lo antes posible (suponiendo que ejecute esas pruebas automatizadas tan pronto como sea posible).
Cuanto antes comience a escribir pruebas automatizadas, antes sus desarrolladores podrán comenzar a ejecutar esas pruebas automatizadas y / o pueden ejecutarse en un entorno de integración continua. Y una vez que eso sucede, se encuentran los defectos antes, lo que ahorra dinero a la empresa y hace felices a los desarrolladores porque les permite lanzar un código de mayor calidad. También les da confianza para hacer cambios porque pueden ver rápidamente si causa una regresión.
Además, hace que sus ingenieros de calidad sean una parte mucho más importante del proceso en general, en lugar de sentir que su esfuerzo es algo agregado al final una vez que la mayoría del trabajo ya se ha realizado.
Hay algunas reglas generales antes de comenzar la automatización, como asegurarse de que su aplicación sea lo suficientemente estable, en segundo lugar intente iniciar la automatización con, por ejemplo, crear un script de prueba de humo, que toca solo partes importantes (solo partes críticas de la funcionalidad) inicialmente. Por ejemplo, si se trata de una aplicación bancaria, inicialmente solo automatice eso si el usuario puede iniciar sesión y verificar el saldo de su cuenta, etc. y nada más o menos. De esta forma, intente aumentar el repositorio de scripts a medida que la aplicación se vuelve más estable con el tiempo. Pero lo más importante es que se pregunte cuál es exactamente el propósito que desea resolver con la automatización.
El siguiente enlace también puede ayudar:
Requisitos previos para comenzar las pruebas de automatización
- todas las empresas deberían automatizar sus testcases.
- Automatice los casos de prueba de regresión.
- Siga la metodología BDD y POM.
- El código debe ser reutilizable.
- el código siempre debe ser independiente de la máquina.
- el método de informe debe ser lo suficientemente fácil para que los propietarios del proyecto puedan conocerlo fácilmente.
- integrar CI a través de JENKINS / cron.
- La automatización requiere el costo del hardware y el tiempo de automatización.