 |
 |
|
 ¿Qué entendemos por “prueba de software”?
En e-Quallity Corp. consideramos que la prueba de software:
Es un proceso que corre en paralelo al proceso de desarrollo de software, y que se realiza por el convencimiento de que todo sistema debe ser “revisado” con el objetivo de establecer el nivel de calidad requerido.
En ese proceso se ejecuta el sistema a probar (el SUT: System Under Testing) bajo condiciones específicas y se le aplica (eventualmente con apoyo de herramientas especializadas de tipo CAST: Computer Aided Software Testing) un conjunto de estímulos diseñados ingenierilmente (los test cases), con el objetivo de detectar insatisfacción de los requerimientos planteados; todas las actividades y sus resultados son documentados.
Este proceso debe llevarse a cabo de una manera sistemática, y debe respaldarse en métricas bien definidas.
Este proceso de prueba genera información muy valiosa acerca de la madurez del producto de software que permite tomar decisiones importantes como no comprar o pagar el SUT entregado por falta de calidad, o rehacer uno de los componentes por la misma razón. |
|
 ¿Por qué hacer prueba de software?
Hoy en día, para poder competir en este mercado globalizado y altamente competido de las tecnologías de información y comunicación, la calidad no representa un valor agregado, sino más bien un prerrequisito indispensable para permanecer en el mercado.
Aplicando prueba de software, se puede reducir el costo y el tiempo global del desarrollo, pues se detectan una buena cantidad de problemas en fases tempranas del proceso.
En ese contexto, algunos factores particulares que dan razón de ser a la prueba de software son:
- Liberar un producto inmaduro trae como consecuencia una labor penosa y costosa de soporte a usuarios insatisfechos, así como altos costos de mantenimiento.
- La insatisfacción del cliente trae como consecuencia pérdida de imagen de la empresa, así como una baja de la credibilidad en la misma.
- La mala calidad de un producto no tarda en verse reflejada en una baja en las ventas.
- En sistemas críticos la falla del sistema puede traer como consecuencia pérdidas de vidas humanas y/o monetarias, y repercusiones económicas (incluso penales) muy severas.
|
|
 ¿Cómo hacemos la prueba de software?
El proceso de prueba debiera comenzar en la fase misma de la definición de requerimientos y terminar con la finalización de la aplicación de los casos de prueba al sistema ejecutable. Esto es, la prueba de software representa un subproceso que permea prácticamente todo el proceso de desarrollo de software:
- Fase de Requerimientos: se verifica si se siguen estándares, y si los requerimientos son completos, consistentes, rastreables (traceable), probables (testable), y modulares.
Las entradas a esta fase de prueba son: estándar de requerimientos; documento(s) de requerimientos.
Las salidas son: recomendaciones para que el documento de requerimientos presente las características deseables mencionadas arriba; documento(s) con diseños preliminares de planes y de casos de prueba de aceptación (ver más abajo).
- Fase de Diseño: verificar si las propuestas de diseño satisfacen los requerimientos, si presentan características deseables, y si se siguieron los estándares de diseño. En particular, verificar si la arquitectura del sistema y de la base de datos son apropiadas, si los diseños tienen alta cohesión y bajo acoplamiento, y si la base de datos tiene la normalización adecuada (no redundancia ni problemas de integridad referencial).
Entradas: estándar de diseño; documento(s) de diseño; documento(s) de requerimientos.
Salidas: recomendaciones para que el documento de diseño presente las características deseables mencionadas arriba; documento(s) con refinamientos de los planes y casos de prueba de la fase anterior, mas diseños preliminares de casos de prueba de interacción.
- Fase de Construcción (programación): verificar si se siguen estándares, si los programas son consistentes con el diseño, y si el código es modular, además de cohesivo y bajo en acoplamiento; eventualmente, verificar el nivel y calidad de reuso.
Las entradas las suele proveer la organización desarrolladora/compradora del software; las salidas la organización de prueba.
|
|
 ¿Qué técnicas de prueba de software se suelen aplicar?
Durante la programación debieran llevarse a cabo de manera gradual varias fases de prueba al sistema:
Unit Testing: usualmente realizadas por el mismo desarrollador, en las que prueba constituyentes “atómicos” del sistema que él programó (funciones/objetos/componentes).
Integration Testing: en las que se verifica si el conjunto de componentes que conforma el sistema completo interactúa correctamente. Por cuestiones de objetividad y eficiencia, es recomendable que esta fase sea llevada a cabo una entidad distinta al grupo desarrollador.
Aceptance Testing: usualmente llevadas a cabo por el destinatario del software, en las que verifica si el sistema satisface los requerimientos. Por cuestiones de objetividad y eficiencia, es recomendable que esta fase sea llevada a cabo una entidad distinta al grupo desarrollador.
En cada una de estas fases podría aplicarse al menos uno de los siguientes tipos de prueba:
Black Box Testing: (de funcionalidad): basándose en los requerimientos, verificar si el sistema hace lo que debe, y no hace lo que no debe. (Las pruebas de stress y de volumen, enfocadas a verificar si el sistema soporta una cantidad mínima de usuarios, o puede almacenar una cierta cantidad de información mínima/máxima, pueden verse como casos especiales de este tipo de prueba).
Entradas: archivos ejecutables; documento(s) de requerimientos.
Salidas: documento(s) con defectos encontrados. Métricas de la aplicación de casos de prueba.
White Box Testing: (de código/diseño): basada en los requerimientos, en el diseño y en el código fuente.
Entradas: estándar de programación; archivos fuente; documento(s) de diseño.
Salidas: documento(s) con defectos encontrados. Estadísticas acerca del seguimiento al estándar, así como de algunas características del sistema, tales como el tamaño (LOCs, puntos de función, etc.), la complejidad (ciclomática, estructural, etc.), la modularidad (cohesión, acoplamiento, etc.), la legibilidad, etc.
Durante todo ese proceso se aplican las denominadas “pruebas progresivas”. Esas pruebas detectan defectos, a los que se da seguimiento para verificar que sean descartados o corregidos.
La verificación de que un error haya sido corregido y no “destapó” otros errores se realiza mediante lo que suele llamarse “pruebas regresivas”, consistentes en aplicar ya sea todas o sólo un subconjunto de las pruebas progresivas (implica la definición de algún(os) criterios de selección de casos de prueba).
e-Quallity brinda el servicio tanto de prueba in-house (realizado en nuestras instalaciones), como de outsourcing de prueba (renta de testers nuestros que se alojan en instalaciones del cliente y se integran temporalmente en su organización).
|
|
|
|
