La calidad de los productos o servicios es ahora mismo uno de los requisitos primordiales que debe cumplir cualquier empresa. En un mercado tan competitivo no basta solo con producir y distribuir productos o servicios en masa, la cantidad de ventas dependerá de la aceptación por parte del cliente, y esta a su vez depende completamente de la calidad propuesta.
Pero cuando hablamos de desarrollo de software, el concepto de “calidad” se vuelve un poco complejo, esto debido a que no se puede comparar con la calidad de un producto tradicional ya que posee sus propias mediciones y formas únicas de determinar su valor.
Mientras que la calidad viene siendo la capacidad de un producto o servicio para satisfacer las necesidades de un usuario, cuando se trata de desarrollo de software el concepto deberá analizarse desde un punto de vista cualitativo.
Calidad de software:
En este punto hay al menos dos tipos de calidad que se pueden evaluar: la calidad de diseño la cual se refiere a los rasgos distintivos que los diseñadores especifican para un elemento, y la calidad de concordancia, la cual se enfoca en cómo las especificaciones se llevan a cabo durante la fabricación. La calidad de concordancia será alta cuando la implementación esté guiada por el diseño y esto dé como resultado un sistema que ofrezca el mejor rendimiento.
La calidad de software hace referencia a aquellas características que son propias de dicho programa y que se buscan controlar y asegurar. Aunque a diferencia de los productos tradicionales, el software no se degrada con el tiempo, pero sí necesita ser actualizado. Un producto como el software puede presentar errores o inicidencias, por ello permanece en constante desarrollo.
Certificación de software:
Vale la pena aclarar que un software nunca se certifica, lo que recibe un certificado de calidad son los procedimientos usados para su desarrollo. Cada uno de estos procedimientos debe ser correctos y seguir parámetros de normalización como ISO 9000, CMMI, Moprosoft, entre otros.
¿Qué es la normativa ISO 9000?
La normativa ISO 9000 es una de las más reconocidas en el medio, da cuenta de un sistema que garantiza la calidad en desde una perspectiva genérica por lo que se puede aplicar a cualquier empresa sin importar los servicios o productos que ofrezca.
ISO 9000 dispone de un certificador o auditor que evalúa los procesos internos a fin de determinar si cumple a cabalidad con la normativa o no. Si los resultados son positivos, se entrega la certificación que debe ser renovada cada cierto tiempo a través de entrevistas semianuales donde se garantiza que la concordancia de calidad se mantiene de acuerdo a este estándar.
Medición del software:
La medición sirve para asignar números a atributos reales, también puede realizarse por medio de símbolos, para ello solo requiere de un modelo de medición que comprenda un conjunto existente de normas. Cuando se trata de desarrollo de software, una medida representa un indicador cuantitativo que puede derivarse de la extensión, la dimensión, la capacidad, la cantidad, o el tamaño de algún atributo del software o de su proceso de producción.
La medición no es más que el resultado de la recolección de uno o más datos. Partiendo de ello, la métrica de software relaciona estas medidas individuales y consigue desarrollar métricas que dan como resultado diversos indicadores.
Se entiende por indicador a una métrica o a una combinación de ellas que brindan información acerca de los procedimientos para el desarrollo de software. Los indicadores facilitan datos que permiten a los ingenieros de software ajustar el proceso o el producto, a fin de que mejore su calidad.
Es netamente necesario medir y controlar la complejidad en el desarrollo de software, a fin de tener la facilidad de desarrollar medidas de diferentes atributos internos del software. Sin embargo, antes de generar y utilizar ciertas métricas del software es importante asegurarse de que estas sean capaces de ayudar en la evaluación de los modelos de análisis y diseño. Además deben brindar un indicativo de la complejidad del código fuente y de los diseños procedimentales, y, finalmente, deben hacer más sencillo el diseño de pruebas con mejores resultados.
Tipos de medida
Utilidad de la medida del software:
¿Qué tipos de pruebas se realizan para mejorar la calidad de un software?
Test unitarios
Los desarrolladores se encargan casi de forma exclusiva de los tests unitarios, su importancia radica en que sin ellos, los bugs o errores se multiplican sin control. Es por ello que este tipo de test es considerada la principal barrera contra los bugs en un sistema, además, son también la base del Test Hiperlink.
Entre sus ventajas se encuentran su capacidad de agilizar el proceso de cambiar partes del código y reportar los fallos con mayor rapidez, lo que ayuda en gran medida a los nuevos desarrolladores que recién se incorporen a un proyecto.
Algunas personas sostienen que un diseño perfecto o una buena planificación puede arreglar muchos más errores y bugs que los test unitarios, no obstante, esto no es del todo cierto. Aunque un software posea el diseño más avanzado, no se puede garantizar que funciona sin problemas sin ayuda de estos test o de test mucho más avanzados.
Test de integración
A fin de comprobar que el sistema verdaderamente está funcionando, es necesario utilizar test de integración. Este tipo de test se encargan de unir las partes del sistema y determinar si estas encajan sin incidencias. Junto con los test funcionales, conforman las bases para el behaviour driven development. Una de sus características principales es que no tienen en cuenta elementos fundamentales como la base de datos, las peticiones de red o los accesos, por ende no son suficientes por sí solos para comprobar si el software se comporta correctamente.
Las ventajas de los test de integración es que consiguen que el sistema sea confiable, pudiendo fiarnos incluso de las partes protegidas por otros test debido a que tendrán el comportamiento esperado al ser llamados por otros elementos. Además, estos test sirven como protección para equipos de desarrolladores de manera que el código de otros elementos no les ocasionen sorpresas desagradables.
El lenguaje Gherkin usado en este tipo de pruebas permite obtener una documentación más completa sobre cómo funciona el sistema, de este modo es posible hallar de forma más rápida y sencilla qué se encuentra cubierto por los test y qué no.
Test funcionales
Los test funcionales van más allá de los test de integración y consisten en hacer la comprobación del sistema tal y como un usuario la haría. Un buen ejemplo de ello es la automatización de interfaces gráficas. Cabe destacar que son el tipo de pruebas más lentas y las que más mantenimiento requieren.
No obstante, pueden ofrecer beneficios valiosos como proteger contra interfaces fallidas y reducir procesos a la hora de realizar pruebas manuales. Sirven sobre todo para configurarlos y ejecutarlos en todos los entornos donde se distribuye el software.
Su importancia radica en que sin este test, los desarrolladores tendrían que probar todas las interfaces de forma manual, lo cual no es demasiado eficiente.
Conoce más sobre nuestros servicios de Desarrollo de Software aquí.
Las pruebas automatizadas han ganado cada vez más popularidad en las empresas de desarrollo de software, así como en los proyectos en los que son incluidas, sin importar la industria de la compañía que recibe el servicio o la naturaleza de este. Como explicamos en una entrada de blog anterior, el auge de la Automatización de Pruebas se basa la gran cantidad de recursos que se ahorran los departamentos de Testing & QA, ya sea en la reducción de mano de obra, así como en la liberación de tiempo y esfuerzo de los Testers , quienes pueden reducir la operatividad para dedicarse a tareas de mayor valor agregado , como el probar funcionalidades nuevas o no cubiertas en la automatización.
Sin embargo, como toda disciplina, la Automatización de Pruebas conlleva una serie de buenas prácticas que han de tomarse seguirse muy de cerca, logrando así que se cumpla la promesa de optimización de los recursos. Entre esas buenas prácticas encontramos:
Correcta asignación de los procesos de automatización por grados
La gran parte del proceso de testing en cualquier proyecto se basa en las pruebas unitarias, luego estaría la prueba de los componentes, posteriormente la integración y finalizando con API, asignando menos esfuerzo en la interfaz de los usuarios, que sería la parte más operativa de la gestión.
Automatizando las secciones más operativas del proyecto dejamos de pasar por alto las facetas más calificadas y funcionales del proyecto, brindando así el mayor valor al usuario final.
Explicación de la pirámide de Mike Cohn:
Pruebas Unitarias: Se utilizan para comprobar el correcto funcionamiento de una porción reducida de código, por ejemplo, un método. Son el punto de partida para detectar fallos, si una prueba falla en este punto, lo más probable es que también fallen las pruebas de los subsiguientes niveles (integración, API, funcional etc.)
Pruebas de API, integración de componentes, servicios: Estas pruebas verifican que la comunicación e intercambio de datos, entre los diferentes módulos de la aplicación o con otras aplicaciones. Sirven para detectar fallos en la forma en la que los diferentes módulos de la aplicación actúan y se integran los unos con los otros.
Pruebas de interfaz gráfica: Requieren elevado tiempo de desarrollo y son lentos en su ejecución y con muchas dependencias con otros componentes. La interfaz gráfica es donde los cambios se dan más frecuentemente, por eso también estas pruebas suelen ser las más inestables, requiriendo actualización periódicamente. Sí, hay que automatizar las pruebas de GUI de las funcionalidades críticas, pero es mejor hacerlo después de haber automatizado los niveles más bajos de la aplicación.
Determinar qué pruebas GUI son fundamentales para el proyecto
No todo se puede ni se debe automatizar, hay que definir los casos de prueba que son candidatos a teniendo en cuenta cosas como validaciones, usabilidad, accesibilidad, etc.
¿Qué automatizar? Pruebas críticas, que no requieran intervención humana, que dé resultados que se puedan comprobar inequívocamente, y cuya complejidad para automatizar no sobrepase el valor que puede aportar.
El tema de la selección de las pruebas de interfaz a automatizar es un tema amplio en sí mismo, por lo que debemos enfocarnos en aquellas áreas críticas para la aplicación, que ya están cerradas y que no van a cambiar constantemente.
Involucrar a todo el equipo en el proceso de testing, así como PM y ajenos al proceso
Se debe incorporar a todo el equipo en la estrategia de automatización de pruebas. Si testing y desarrollo no están en sintonía la automatización fallará. Testing necesita de la colaboración de desarrollo en cuando a seguir ciertas prácticas en el desarrollo de la aplicación para favorecer la automatización de las pruebas.
Adicionalmente, la inclusión de diversos profesionales con conocimiento en el core del negocio del cliente permitirá encontrar detalles y puntos de mejora en el desarrollo, teniendo en cuenta que este será usado por miles de usuarios finales, que demostrarán su descontento con un aplicativo ineficiente.
Asignar recursos con las habilidades necesarias para realizar la automatización
La automatización hecha correctamente requiere más que simplemente grabar y reproducir las pruebas de UI con una herramienta. La automatización debe poder integrarse a nivel proceso de desarrollo para que llegue dar verdaderos beneficios.
Una buena práctica es tener roles separados para el tester funcional y quien automatiza pruebas, combinar estas dos tareas para ahorra recursos es la opción más común, pero termina teniendo el efecto opuesto ya estos roles que requieren habilidades diferentes. Desde hace un par de años algunas compañías como Microsoft, empezaron incorporar el perfil de “Software Development Engineer in Test” o SDET cuyas tareas van desde desarrollar y mantener script de pruebas automatizados (no sólo de interfaz de usuario sino también de seguridad, carga, performance, etc.) hasta implementar y mantener la infraestructura necesaria para integrar y correr esos test como integral parte del proceso de desarrollo.
Este perfil no se encarga en ningún momento de las pruebas funcionales, test plans o test cases, esas tareas quedan en manos de los testers manuales.
Mantener un equipo de testing manual
El objetivo de la automatización de pruebas no es eliminar el testing manual, ni suplantar a los testers. Lo que se automatizan son validaciones que los testers manuales previamente han detectado durante pruebas de regresión o smoke testing.
Es incorrecto pensar que las pruebas automatizadas van a encontrar bugs que los testers manuales hayan omitido. Hay que recordar que se trata de scripts que simplemente corren pasos y verifican resultado, pero el script no verificará nada para lo que no se lo haya programado.
Pasos para elaborar una sólida estrategia de Testing
Determinar el alcance de la Automatización de Pruebas: Todos los aspectos deben considerarse al analizar la viabilidad. También es esencial realizar un análisis de factibilidad en el paquete de casos de prueba manual que permite a los ingenieros de automatización diseñar los scripts de prueba.
Seleccionar la prueba a automatizar correcta: Las pruebas de automatización dependen en gran medida de las herramientas. Es por eso que encontrar la herramienta de prueba de automatización adecuada es una fase crítica para un ciclo de vida de prueba de automatización. Cuando busque una herramienta de automatización, debe tener en cuenta el presupuesto, las tecnologías que se utilizan en el proyecto, la familiaridad de la herramienta de su equipo con los recursos a bordo, la intuición, la flexibilidad y más.
Plan + Diseño + Estrategia de Testing: La siguiente es la fase de la metodología del ciclo de vida de las pruebas de automatización que define cómo abordar y lograr el objetivo de la automatización de pruebas. La selección de un marco de automatización de prueba es lo primero y más importante en la fase de Estrategia de prueba del Ciclo de vida de pruebas de automatización.
Una buena documentación facilita la ejecución: Una vez que instale el entorno de prueba, es el momento de ejecutar el script de prueba. Entonces, esta fase del ciclo de vida de las pruebas de automatización está dedicada a la ejecución de todos los scripts de prueba.
Reporte y análisis de resultados de testing: Después de realizar todos los tipos de pruebas, el equipo de pruebas analizó para identificar qué funcionalidad o componente particular experimenta un número relativo de informes de problemas.
Conclusión
Son muchas las variables que determinan la calidad de la automatización, por los que los responsables de llevar a cabo el desarrollo y/o pruebas de calidad necesitan asignar más recursos para garantizar la calidad del desarrollo.
Te invitamos a que visites nuestra página de Testing & QA para que conozcas más sobre nuestra metodología y calidad de servicio.
