Cualquier usuario o desarrollador sabe, por experiencia propia, que los programas no son perfectos. Los programas tienen errores. Cuanto mejor sea el proceso de ingeniería del software y el proceso de control de calidad y pruebas que se utilice, menos errores tendrá. El software tiene una media de 0,150 errores por cada 1.000 líneas de código. Si tenemos en cuenta que un producto como OpenOffice.org 1.0 tiene aproximadamente 7 millones de líneas de código, la aritmética es sencilla.
Hoy en día cualquier proyecto de software integra dentro de su ciclo de desarrollo procesos de control de calidad y pruebas. No existe una única práctica unánimemente aceptada, ni el mundo académico ni empresarial para llevar a cabo estos procesos. Tampoco existe ningún método que se considere mejor que los otros. Cada proyecto de software utiliza la combinación de métodos que mejor se adapta a sus necesidades.
Los proyectos que no integran un control de calidad como parte de su ciclo de desarrollo a la larga tienen un coste más alto. Esto es debido a que cuanto más avanzado está el ciclo de desarrollo de un programa, más costoso resulta solucionar sus errores. Se requieren entonces un mayor número de horas de trabajo dedicadas a solucionar dichos errores y además sus repercusiones negativas serán más graves. Por esto, siempre que iniciemos el desarrollo de un nuevo proyecto deberíamos incluir un plan de gestión de calidad.
Para poder llevar a cabo un control de calidad, es imprescindible haber definido los requisitos del sistema de software que vamos a implementar, ya que son necesarios para disponer de una especificación del propósito del software. Los procesos de calidad verifican que el software cumple con los requisitos que definimos originalmente.
3.3.1. Términos comunes
Las técnicas y sistemas de control de calidad y pruebas tienen una terminología muy específica para referirse a conceptos singulares de este tipo de sistemas. A continuación veremos los conceptos y términos más habituales:
- Error (bug). Fallo en la codificación o diseño de un sistema que causa que el programa no funcione correctamente o falle.
- Alcance del código (code coverage). Proceso para determinar qué partes de un programa nunca son utilizadas o que nunca son probadas como parte del proceso de pruebas.
- Prueba de estrés (stress testing). Conjunto de pruebas que tienen como objetivo medir el rendimiento de un sistema bajo cargas elevadas de trabajo. Por ejemplo, si una determinada aplicación web es capaz de satisfacer con unos estándares de servicio aceptables un número concreto de usuarios simultáneos.
- Prueba de regresión (regression testing). Conjunto de pruebas que tienen como objetivo comprobar que la funcionalidad de la aplicación no ha sido dañada por cambios recientes que hemos realizado. Por ejemplo, si hemos añadido una nueva funcionalidad a un sistema o corregido un error, comprobar que estas modificaciones no han dañado al resto de funcionalidad existente del sistema.
- Prueba de usabilidad (usability testing). Conjunto de pruebas que tienen como objetivo medir la usabilidad de un sistema por parte de sus usuarios. En general, se centra en determinar si los usuarios de un sistema son capaces de conseguir sus objetivos con el sistema que es objeto de la prueba.
- Testeador (tester). Persona encargada de realizar un proceso de pruebas, bien manuales o automáticas, de un sistema y reportar sus posibles errores.
3.3.2. Principios de la comprobación del software
Cualquiera que sea la técnica o conjunto de técnicas que utilicemos para asegurar la calidad de nuestro software, existen un conjunto de principios que debemos tener siempre presentes. A continuación enumeramos los principales:
• Es imperativo disponer de unos requisitos que detallen el sistema.
Los procesos de calidad se basan en verificar que el software cumple con los requisitos del sistema. Sin unos requisitos que describan el sistema de forma clara y detallada, es imposible crear un proceso de calidad con unas mínimas garantías.
• Los procesos de calidad deben ser integrados en las primeras fases del proyecto.
Los procesos de control de calidad del sistema deben ser parte integral del mismo desde sus inicios. Realizar los procesos de pruebas cuando el proyecto se encuentra en una fase avanzada de su desarrollo o cerca de su fin es una mala práctica en ingeniería del software. Por ejemplo, en el ciclo final de desarrollo es muy costoso corregir errores de diseño. Cuanto antes detectemos un error en el ciclo, más económico será corregirlo.
• Quien desarrolle un sistema no debe ser quien prueba su funcionalidad.
La persona o grupo de personas que realizan el desarrollo de un sistema no deben ser en ningún caso las mismas que son responsables de realizar el control de pruebas. De la misma manera que sucede en otras disciplinas, como por ejemplo la escritura, donde los escritores no corrigen sus propios textos. Es importante recordar que a menudo se producen errores en la interpretación de la especificación del sistema y una persona que no ha estado involucrada con el desarrollo del sistema puede más fácilmente evaluar si su interpretación ha sido o no correcta. Es importante tomar en consideración todos estos principios básicos porque el incumplimiento de alguno de ellos se traduce en la imposibilidad de poder garantizar la corrección de los sistemas de control de calidad que aplicamos.
Aprender 2023: Mejora continua en el Control de Calidad y Pruebas
En la constante evolución de la tecnología, la importancia de las pruebas aprender 2023 se vuelve fundamental. La capacitación y actualización en las mejores prácticas y metodologías de control de calidad son esenciales para garantizar la excelencia en el desarrollo de software. Formarse en las últimas tendencias y enfoques de pruebas aprender 2023 puede marcar la diferencia en la calidad final del producto.
Fuente:
Ingeniería del software en entornos de SL
Marc Gibert Ginestà
entornos de SL
Álvaro Peña González
UOC Formación de Posgrado
Si quieres conocer otros artículos parecidos a Control de Calidad y Pruebas puedes visitar la categoría CALIDAD DE SOFTWARE.
Deja una respuesta