Las herramientas BDD como Cucumber se utilizan para habilitar la automatización de pruebas. Para cualquier proyecto de software, la construcción de una suite de automatización de pruebas requiere una combinación de habilidades
1) habilidades de automatización
Necesita personas que básicamente puedan realizar una tarea que se realizó manualmente y puedan automatizarla. Esto requiere una combinación de habilidad de programación y conocimiento de herramientas de prueba
2) Prueba de habilidades de diseño
Necesita personas que puedan diseñar buenos casos de prueba
En el modelo de cascada, estas 2 habilidades se extendieron por los silos. Hubo programadores que fueron buenos para programar cosas, pero no buenos para diseñar buenos casos de prueba. Luego hubo probadores que tenían capacitación y práctica en el diseño de casos de prueba, pero no saben cómo automatizar las pruebas. Esto condujo a una situación en la que los programadores programaron el código que implementaba la funcionalidad que se entregaba, y los evaluadores probaron manualmente este código para asegurarse de que cumpla con los requisitos. Bien, verdad? Funciona bien?
- Cómo valorar los beneficios de un software informático
- ¿Cuáles son las diferencias entre el sistema y el software y el programa en términos de análisis del sistema?
- ¿Es común en la industria del software usar la cobertura gráfica para sus pruebas de front-end funcionales?
- ¿Qué certificado debe tener cada desarrollador?
- Si pudiera volver a implementar la World Wide Web desde cero, incluidas todas las tecnologías y protocolos relevantes, ¿qué haría de manera diferente?
Bueno en realidad no. Piensa en lo que sucede cuando un proyecto crece y crece. Digamos que comienzas un proyecto con 5 desarrolladores y 5 QA. En un ciclo de cascada dado, 5 desarrolladores tienen suficiente ancho de banda para cumplir con los requisitos, y 5 QA tienen suficiente ancho de banda para probar el código que crearon los desarrolladores. ¡Multa!. Implementa, prueba, entrega, cliente satisfecho. Pero espere un minuto, ahora el cliente está tan contento con usted que quiere una nueva funcionalidad. Entonces, pasas otro ciclo de cascada agregando nuevas funcionalidades. Asumiendo que el ancho de banda de todos es el mismo, 5 desarrolladores generaron una nueva funcionalidad que es igual a la funcionalidad anterior en tamaño y alcance. Ahora, necesita 5 QA para probar la nueva funcionalidad y 5 QA para volver a probar la funcionalidad anterior. 3.er lanzamiento necesita 15 QA. Cuarta versión necesita 20 QA. 10 lanzamientos hacia abajo, necesitas 50 Qa. Por supuesto, un gerente no puede administrar 50 QA, por lo que necesita de 5 a 10 gerentes. En cada versión, desea asegurarse de no haber roto la funcionalidad anterior cuando implementó una nueva, ¿verdad? Entonces, debes probar todo de nuevo. Esta prueba de funcionalidad antigua se llama prueba de regresión , y la prueba de regresión es la razón por la que necesitamos automatización. Cada versión agrega más pruebas de regresión a la próxima versión. Esto significa que una organización de desarrollo de software tiene que seguir aumentando su capacidad de prueba en cada versión. ¡Agregar más personas no es una solución escalable!
Entonces, cuando la gente comienza a pensar en construir software de una manera ágil, el problema de las pruebas de regresión no es capaz de escalar. Dijeron que, en las pruebas de regresión, básicamente estás rehaciendo las pruebas que has hecho antes. Entonces, ¿por qué queremos que los humanos lo hagan? ¿Por qué no hacer que las computadoras lo hagan? Además, si una computadora lo está haciendo, ¿por qué no hacerlo todos los días en lugar de finalizar el lanzamiento? De esta manera, los desarrolladores recibirán comentarios inmediatos cuando rompan algo. Esto hará que sea más rápido arreglarlo. Esta solución al problema de las pruebas de regresión es lo que dio origen a la idea de la integración continua.
Entonces, ¿qué tiene que ver con el pepino? estoy llegando
Uno de los desafíos con la construcción de un conjunto integral de pruebas de regresión automatizadas es que para hacerlo bien, se necesitan personas que tengan las dos habilidades anteriores. Necesita personas que sean buenas para diseñar casos de prueba y automatizar esos casos de prueba. Eso no es fácil de hacer. Es muy fácil exigir que todos sus desarrolladores escriban buenas pruebas funcionales, pero no sucede. Es muy fácil ordenar que sus evaluadores aprendan a automatizar, pero eso tampoco funciona. Especialmente en industrias donde las pruebas funcionales requieren un profundo conocimiento del negocio, sus evaluadores podrían no ser programadores en absoluto. Por ejemplo, en una empresa anterior, estábamos creando software de contabilidad fiscal, y nuestros evaluadores funcionales eran más o menos personas que tenían un buen conocimiento de los principios de contabilidad. En realidad, generalmente eran personas que estaban cursando un título en contabilidad o estudiaban para su CPA. Estaban más cómodos con Excel que Java
Entonces, ¿cómo resuelve este problema de combinar diferentes conjuntos de habilidades? Aquí es donde entran las herramientas BDD . Las herramientas BDD le permiten generar pruebas a partir de especificaciones escritas por expertos empresariales. Básicamente, puede tomar personas que tengan un profundo conocimiento del negocio, hacer que escriban especificaciones detalladas que describan lo que debe hacer la aplicación. Luego, la herramienta genera un código que los desarrolladores deben aumentar para que el código real pase por la prueba.
OMI, BDD es importante. No es solo algo que los programadores aburridos inventaron porque no tienen nada más que hacer. Es una solución a los problemas sistémicos que enfrenta la industria. Claro, no necesita BDD, si su idea de la ingeniería es seguir haciendo las cosas de la manera estúpida agregando más y más trabajo en QA, y esperando que QA sean burros que siguen haciendo clic en los mismos botones una y otra vez hasta su muerte en su escritorio Eso no es ingeniería. Un gran aspecto de la ingeniería es desarrollar sus herramientas y procesos para reducir el trabajo repetitivo. Las herramientas de BDD trabajan para eso.