Si estás leyendo este artículo, entiendo que vienes de leer la primera parte, donde os hablé sobre los conceptos generales del software testing. Si no has leído ese artículo, te recomiendo encarecidamente que lo hagas, ya que algunas cosas de las que voy a hablar a continuación, están relacionadas con la primera parte.
Dejé fuera del anterior artículo los conceptos de los que trato aquí, por motivos de comodidad narrativa y porque no quería sobrecargar el artículo de conceptos. Espero que encuentres en éste la claridad necesaria para ver cómo desmontamos Legos ¡Vamos a ello! 🙂
1.1 Modelo en cascada (Waterfall)
Cuando John Ford creó el modelo de producción en línea, también creó el modelo de desarrollo en cascada (bueno, no fue así exactamente, pero podría haberlo sido perfectamente 😅). En realidad, fue Wiston W. Royce el primero que formuló el término, haciendo hincapié en que las pruebas se deberían hacer una vez concluido el desarrollo del producto.
En la fase de prueba, un producto, ya diseñado y codificado, se prueba exhaustivamente antes del lanzamiento. Sin embargo, la práctica muestra que los errores y defectos de software detectados en esta etapa pueden ser demasiado caros de corregir, ya que el coste de un defecto tiende a aumentar a lo largo del proceso de desarrollo de software.
¿Qué se quiere decir con esto? Si se da un error en las especificaciones, detectarlo temprano en la etapa de planificación no causaría pérdidas significativas. Sin embargo, el daño crece exponencialmente a lo largo de las etapas posteriores del proceso. Si se detecta un error de este tipo en la etapa de diseño, se tendrá que volver a trabajar en los diseños. Pero si no se detecta el error antes de que se construya el producto, es posible que se tengan realizar cambios importantes en el diseño y en el código fuente. Esto requerirá una cantidad significativa de esfuerzo e inversión.
Por lo tanto, es mejor probar cada parte mientras el producto aún se está construyendo. Aquí es donde la metodología AGILE resulta interesante.
1.2 Pruebas AGILE
AGILE divide el proceso de desarrollo en partes más pequeñas, iteraciones y sprints. Esto permite que sea el propio equipo el que evalúa lo que hay que hacer en el proceso y corrija las fallas y los errores inmediatamente después de que ocurran.
El objetivo principal del proceso es ofrecer nuevas funciones de software de forma rápida y con la mejor calidad. Por lo tanto, este enfoque es menos costoso: corregir los errores al principio del proceso de desarrollo, antes de que aumenten los problemas, es significativamente más económico y requiere menos esfuerzo. Además, la comunicación eficiente dentro del equipo y la participación de todas las partes acelera el proceso y permite tomar decisiones más adecuadas.
El foco de prueba AGILE se trata más de construir una práctica de control de calidad en lugar de tener un equipo de control de calidad.
1.3 Pruebas en DevOps
Para aquellos que tienen experiencia Agile, DevOps se convierte gradualmente en una práctica común. Esta nueva metodología de desarrollo de software requiere un alto nivel de coordinación entre varias funciones de la cadena de entrega, a saber, desarrollo, control de calidad y operaciones.
DevOps a menudo se conoce como una extensión de Agile que cierra la brecha entre el desarrollo con el control de calidad y las operaciones. Sin embargo, a diferencia de Agile, DevOps incluye el concepto de desarrollo continuo donde el código, escrito y comprometido con el control de versiones, se construirá, implementará, probará e instalará en el entorno de producción que está listo para ser consumido por el usuario final. DevOps pone un gran énfasis en la automatización y las herramientas de integración continua que permiten la entrega de aplicaciones y servicios a alta velocidad.
El hecho de que las pruebas se realicen en cada etapa del modelo DevOps cambia el rol de los evaluadores y la idea general de las pruebas. Por lo tanto, para poder llevar a cabo actividades de prueba de manera efectiva, ahora se espera que los evaluadores tengan habilidades técnicas e incluso conocimientos de programación, por eso serán los integrantes del equipo de desarrollo.
– Black box Testing
Este método recibe su nombre, “caja negra”, porque el ingeniero de control de calidad se enfoca en las entradas y las salidas esperadas sin saber cómo funciona internamente la aplicación (software). El propósito de este método es verificar la funcionalidad del software asegurándose de que funcione correctamente y cumpla con las demandas del usuario. Este método se puede aplicar a cualquier nivel de prueba, pero se usa principalmente para pruebas de aceptación del sistema y del usuario, de las que hablamos en el artículo anterior.
A diferencia de las pruebas de caja negra, este método requiere un conocimiento profundo del código, ya que implica probar alguna parte estructural de la aplicación. Por lo tanto, generalmente, los desarrolladores directamente involucrados en la escritura del código son los responsables de este tipo de pruebas. El propósito de las pruebas de caja blanca es mejorar la seguridad, el flujo de entradas/salidas a través de la aplicación y mejorar el diseño y la usabilidad. Este método se utiliza principalmente en los niveles de pruebas unitarias y de integración.
Este método es una combinación de los dos anteriores, ya que implica probar tanto las partes funcionales como las estructurales de la aplicación. Con este método, un tester experimentado tiene un conocimiento parcial de la estructura interna de la aplicación y, en base a este conocimiento, puede diseñar casos de prueba mientras sigue probando desde la perspectiva de la caja negra. Este método es principalmente aplicable al nivel de prueba de integración.
Este es un método de prueba informal ya que se realiza sin planificación ni documentación. Al realizar pruebas de manera informal y aleatoria sin ningún resultado esperado formal, el tester improvisa los pasos y los ejecuta arbitrariamente. Aunque los errores encontrados con este método son más difíciles de reproducir dada la ausencia de casos de prueba, este enfoque ayuda a encontrar defectos importantes rápidamente, algo que no se puede hacer con métodos formales.
Para acelerar y mejorar la calidad de las pruebas de software y mejorar su calidad, es importante adoptar una automatización de pruebas.
La automatización de pruebas es fundamental, ya que alivia la carga de administrar todas las necesidades de las pruebas, lo que permite dedicar más tiempo y esfuerzo a la creación de casos de prueba (test cases). La tendencia de automatización de pruebas está respaldada por la adopción cada vez mayor de metodologías ágiles, que promueven tanto la automatización de pruebas como las prácticas de integración continua.
El proceso de automatización de pruebas normalmente se lleva a cabo en varios pasos consecutivos:
La automatización se puede aplicar a casi todos los tipos de pruebas, en todos los niveles. Como resultado, la automatización minimiza el esfuerzo humano requerido para ejecutar las pruebas de manera eficiente, reduce el tiempo de comercialización y el costo de los errores porque las pruebas se realizan hasta 10 veces más rápido en comparación con el proceso de prueba manual.
La prueba de regresión es la práctica de verificar el comportamiento del software después de las actualizaciones para garantizar que los cambios no hayan afectado las funciones, la estabilidad y la integridad general del sistema existente. Las pruebas de regresión se pueden aplicar a todos los niveles y con todo tipo de procedimientos de prueba, pero la forma más común es ejecutar pruebas de regresión según los casos de uso. El flujo de trabajo de control de calidad de regresión se puede automatizar para evitar pruebas manuales repetitivas después de cada actualización. Existen múltiples técnicas de prueba de regresión:
CONCLUSIÓN
Espero que, con la explicación de los conceptos en este artículo, se haya completado lo que se exponía en el artículo anterior. He tratado de exponerlos de una manera simple y sin caer en ciertos debates siempre presentes en la sociedad de QA. La verdadera intención de estos dos artículos, además de acercar a los no iniciados a los procesos de QA, es también sentar las bases para formular lo que puede ser el QA en un futuro no muy lejano, que es de lo que se va a ocupar el tercer y último artículo. El futuro del software testing.
Espero haber acertado en la selección de conceptos y que sigas con ganas de descubrir la tercera parte de este artículo: Atrévete a conocer qué es QA (III): el futuro del Testing | ENCAMINA
Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continuas navegando, estás dando tu consentimiento para aceptar las cookies y también nuestra política de cookies (esperemos que no te empaches con tanta cookie 😊)
