Un video interesante de las pruebas de software

Preguntas Frecuentes

Recorriendo el internet pude encontrar preguntas que a muchos de ustedes les va interesar ya que son sol principio para poder hacer un buen "testing" a todo el software que les asignen

¿ Que es el control de calidad del software ?

El control de calidad del software incluye desde el monitoreo de desarrollo de procesos haciendo respetar los estándares y procedimientos concordados asegurándose un buen seguimiento de programa y la detección y corrección de errores. El control de calidad del software esta orientado a la prevención.

¿ Que es prueba de software ?

La prueba de software involucra las operaciones del sistema bajo condiciones controladas y evaluando los resultados.

Las condiciones controladas pueden ser normales o anormales. La prueba puede intencionalmente esforzar al programa y producir errores en las respuestas para determinar si los sucesos ocurren cuando no tendrían que ocurrir o cuando los hechos no suceden cuando deberían suceder.

La prueba de software esta detectada a la detección.

La mayoría de las grandes organizaciones asumen la responsabilidad del control de calidad y prueba de software a tal medida que en la producción se incluyen desarrolladores de sistemas (analistas , programadores) y un grupo dedicado a la prueba de software para que estos grupos antes mencionados trabajen en conjunto cumpliendo el control de calidad (prevención) y la prueba de software (detección) logrando una tarea exitosa.

Fallos mas recientes causados por software con bugs en sistemas de computación :

• En enero del 2000 se registro la mayor cantidad de fallas de sistemas, en organizaciones europeas, de todos los tiempos al sufrir las consecuencias del efecto Y2K (Y2K bug).

Como por ejemplo el sistema de trenes se vio afectado al no reconocer la fecha 01-01-00 y los trenes no salieron o salieron a destiempo, de la misma manera se produjeron problemas de comunicación en correos electrónicos en aquellos sistemas que utilizaban agenda de pedidos o informes que se enviaban automáticamente en cada fecha.

• Otro problema fue causado en una escuela publica de los Estados Unidos donde alrededor de 100.000 estudiantes solicitaron la inscripción y el sistema no contemplaba el manejo de tal cantidad de inscritos causando errores en las tarjetas de reportes de los alumnos inclusive inscritos en otros años y en el sistema de registros de materias. Esta escuela decidió reinstalar el sistema viejo de hace 25 años hasta que los bugs del sistema hayan sido corregidos.

• En octubre de 1999 un modulo de la nave espacial para el estudio de Marte valuado en 125 Millones de dólares fue perdido en el espacio debido a un simple error de conversión de datos. Fue ciertamente determinado que el software de la nave utilizaba datos en el sistema métrico ingles , el error fue causado cuando se ejecutaban procesos concurrentes donde uno de ellos establecía comunicación para el descenso en el sistema métrico ingles y el otro proceso calculaba los parámetros de órbita con otro tipo de unidades, entonces estos dos procesos utilizaron el mismo procedimiento para la conversión de datos, aunque no se ha determinado que modulo del sistema causaron el bug.

• Un bug en le programa de soporte de una red comercial de alta velocidad afecto 70.000 negocios de clientes por el periodo de 8 idas en agosto de 1999, entre los afectados fue la empresa Electronic Trading System Futures Exchange , la cual tuvo que suspender sus tareas. Esto fue causado por el repentino paro del programa de soporte en este sistema Non Stop.

¿ Porque es tan difícil para el desarrollo de sistemas incluir seriamente un control de calidad y una buena prueba de errores ?

Resolver los problemas cuando se presentan es un proceso fácilmente determinado, pero prevenir problemas es una tarea muy minuciosa y muy difícil de determinar.

En la antigua china existía una familia de curadores , uno de los integrantes de esta familia siendo ya muy reconocido fue contratado por uno de los grandes Señores del territorio como su medico personal. Una noche mientras cenaban el Señor le pregunta al medico cual de sus otros familiares era tan poderoso como el, entonces el medico comento; Yo atiendo a personas con grandes males, casi moribundos llegan a mi con cierta fe, y algunas veces logro curarlos, y mi nombre es reconocido en casi todo el territorio. Mi hermano mayor cura las enfermedades cuando recién comienzan a hacer raíz en el cuerpo y su nombre es reconocido en los vecindarios, mi hermano menor cura enfermedades antes de que aparezcan y solo es conocido por la familia y su nombre no ha salido de la casa.

Es decir, arreglar o corregir un problema o bug después que sale a la luz es una tarea relativamente sencilla, ya que se conoce el foco del problema, el inconveniente esta en corregir un error que no esta visible o no ha sucedido todavía.

¿Cuales son las razones para que un programa contenga bugs?

• Poca o falta de comunicación entre diferentes aplicaciones.(Requerimientos de las aplicaciones.)

• Complejidad del software. Causa dificultad en la re utilización de código y generalmente requiere personas con experiencia en desarrollo de software modernos como por ejemplo en sistemas cliente servidor, aplicaciones distribuidas, comunicación de datos, manejo de enormes bases de datos relacionales y un gran manejo de técnicas orientadas a objetos. A veces estos conocimientos también pueden causar mas errores de los que corrigen.

• Errores de programación. Los programadores son uno de los principales factores en la causa de errores o bugs.

• Requerimiento de cambio en el sistema. El rediseño y la replanificación causan efectos en otros proyectos que trabajan en conjunto o a partir de resultados del sistema modificado.

Estos procesos cooperativos generan mas complejidad en las diferentes pruebas y en el control y generalmente el entusiasmo de los desarrolladores del sistema se ve afectado al tener que realizar actividades diferentes o no correspondientes a su labor.

Como por ejemplo el de los ingenieros al tener que hacer un análisis funcional a partir de su planificación, todo esto influye y atenta con la integridad del programa y genera riesgos de una gran cantidad de errores.

• Presiones de tiempos. Una buena planificación y un buen análisis con sus respectivos controles de calidad y prueba se ven afectados por un lapso corto de tiempo para que esto sea completo. La falta de tiempo generalmente conlleva a no considerar u omitir ciertas fases de prueba y control.

• El ego (aspecto psicológico del personal).A veces la situación y el contexto lleva a que la gente diga:

- No hay problema

- Es muy fácil.

- Puedo terminar esto en pocas horas.

-No habrá inconvenientes en adaptar ese viejo código.

en vez de decir:

-Eso es muy complejo.

-Nos llevara a cometer varios errores.

-No puedo estimar cuanto tiempo me llevara este trabajo.

-No se como readaptar ese código.

Son muchas las ocasiones en las que un ¨ No hay problema ¨ genera un bug.

• Pobre documentación del código. Es difícil poder modificar código cuya documentación es escasa o esta mal escrita.

En muchas organizaciones los directivos no incentivan a los programadores a realizar una buena documentación e incluso a no darle importancia a la entendibilidad del código, como también el hecho de incentivar demasiada seguridad en la documentación y escritura del código. Lo que fue difícil de escribir podría llegar a ser difícil de leer y aun mas complicado de modificarlo.

• Herramientas de desarrollo de software. Herramientas visuales , librerías de clases, compiladores, herramientas de escritura, etc., a menudo introducen código extra con pobre documentación lo cual genera un bug en el programa en cuestión.

¿ Cómo un nuevo software con control de calidad puede ser introducido en una organización existente ?

Depende del tamaño de la organización y de los riesgos involucrados.

Para grandes organizaciones con altos niveles de riesgos en términos de capital y vida evolutiva de la empresa un serio manejo de control de calidad es absolutamente necesario por lo que un nuevo software debe garantizar una muy buena seguridad y cumplir con lo formalizado.

En organizaciones donde los riesgos son menores la implementación con control de calidad puede ir disminuyendo su intensidad con el tiempo sin que la organización con el tiempo. Esta falta de procesos con control de calidad podría ser equilibrada con mayor productividad eliminando niveles de burocracia.

Para pequeños proyectos el control de calidad de procesos puede ser enfocado a partes especificas del sistema dependiendo del tipo de organización o de clientes, aunque es importante asegurar una adecuada comunicación entre desarrolladores y personal ocupado de la prueba de programa asegurando también

una retroalimentación del sistema optimizando la relación cliente empresa.

En todo los casos, lo mas valioso es el esfuerzo en la prueba de software y un control de calidad del sistema garantizando buena especificación y cumpliendo con las expectativas pero generalmente el desempeño y los requerimientos de la empresa principalmente el factor tiempo hacen que las pruebas de software y controles sean limitadas.

¿ Que es verificación y validación ?

La verificación típicamente incluye por parte de los desarrolladores la revisión de los planes, del código, de los requerimientos, de la documentación y las especificaciones y posteriormente una reunión con los usuarios para evaluar dichos documentos. Esto puede ser hecho con listas de chequeos, listas de problemas, walkthrough.

La validación típicamente incluye las pruebas del software y comienza después que la verificación este completa.

Este proceso de verificación y validación da lugar al termino ¨IV&V¨ Independent verification and validation.

¿Que es walkthrough ?

Es una reunión informal entre analistas y usuarios para la evaluación de propuestas informacionales, generalmente es requerida una pequeña preparación de documentos.

¿Que es la inspección ?

La inspección es una reunión formal luego del walkthrough, generalmente incluye personal de diferentes sectores esencialmente analistas, programadores, y personal de prueba (testers) donde acuerdan con los usuarios los métodos de seguridad prueba a llevar a cabo. A menudo en estas reuniones se incluye un

moderador el cual representa a la empresa y que da a conocer al usuario una lista de operaciones de métodos de prueba y controles de calidad en las cuales el usuario debe optar definiendo el mismo el nivel de calidad.

¿Que tipos de prueba de programa deben ser considerados ?

• Caja negra. No esta basada en el conocimiento del código o diseño interno, determina la funcionalidad del sistema.

•Caja blanca. Esta basada en la lógica interna de la aplicación y el código. Hace una cobertura de declaraciones del código, ramas, caminos y condiciones.

•Unidad de testeo o prueba. Es la escala mas pequeña de la prueba, esta basada en la funcionalidad de los módulos del programa, como funciones, procedimientos, módulos de clase, etc. En ciertos sistemas también se verifican o se prueban los drivers y el diseño de la arquitectura.

•Integración incremental. Cuando nuevas funciones son ingresadas al sistema se hace la prueba basándose en la funcionalidad, la dependencia con otros módulos y la integración con el programa completo.

•Prueba de integración. Se basa en las pruebas de conexiones y comunicaciones entre diferentes módulos. Es esencial en sistemas de cliente_servidor o red.

•Prueba funcional. La caja negra hace la prueba funcional de los requerimientos de la aplicación y generalmente es realizada por el programador, en cambio, la prueba funcional es realizada por los testers.

•Prueba de sistema. Es una prueba de caja negra incluyendo todos los componentes del sistema desde el hardware a la documentación.

•Prueba de fin a fin. Es similar a la prueba de sistema pero esta involucra la interacción con otros hardwares, bases de datos y redes.

•Prueba de sanidad. Determina si la nueva versión de un software esta bien realizada y si necesita un nuevo esfuerzo en la prueba de software. Por ejemplo la nueva versión de un programa cumple con casi todos los requisitos pero destruye la base de datos al leerla, por lo tanto se dice que este software no esta en una condición sana.

•Prueba de regresión. Es una nueva revisión en las pruebas del programa luego de que este haya sufrido algún cambio o por apuros de tiempo o la modificación fue en el ambiente en que se desenvuelve. Actualmente aparecieron herramientas automatizadas que hacen que este tipo de pruebas no lleve demasiado tiempo.

•Prueba de aceptación. Es la prueba final basada en las especificaciones del usuario o basada en el uso del programa por el usuario final luego de un periodo de tiempo.

•Prueba de carga. Esta basada en las aplicaciones bajo cargas pesadas, generalmente usadas en sitios web y en servidores con gran cantidad de datos donde se determina en cuales puntos existen degradaciones del sistema.

•Prueba de estrés. Es una prueba de carga y perfomance basada en la funcionalidad del sistema bajo cargas pesadas , un gran numero de repeticiones, manejo de grandes datos y demasiadas preguntas a bases de

datos grandes.

•Prueba de perfomance. Es una de las pruebas finales y sirve para definir los requerimientos y la calidad del software, en base a las pruebas de carga y estrés. Incluye entrevistas con el usuario y programador.

•Prueba de instalación y desinstalación. Determina la eficiencia de los procesos que instalan y desinstalan las aplicaciones del programa.

•Prueba de recuperacion. Es la prueba que evalúa que tan bien se recupera el sistema luego de bloqueos , fallas del hardware u otros problemas catastróficos.

•Prueba de seguridad. Evalúa que tan bien el sistema se protege contra accesos, internos o externos, no autorizados, esta prueba requiere sofisticadas tecnicas y herramientas.

•Prueba de compatibilidad. Evalúa el desempeño del software en diferentes hardwares , sistemas operativos , redes, etc.

•Prueba de exploración. Es una prueba informal del software que no esta basada en ningún plan o caja de prueba y a menudo los testers aprenden del programa al explorar todas las aplicaciones posibles.

•Prueba de anuncio. Es similar a la prueba de exploración pero los testers deben tener suficiente noción sobre el funcionamiento del programa antes de comenzar esta prueba. Incluye reunión con analistas y programadores.

•Prueba de usuario. Determina si el usuario se desenvuelve satisfactoriamente con el programa.

•Prueba de comparación. En esta prueba se comparan los pro y los contra del programa con los programas creados con la competencia.

•Prueba alfa. Es la prueba cuando la aplicación esta cerca de la entrega al usuario. Se hacen pequeños cambios generalmente en el diseño de interfaces. Esta prueba es hecha por usuarios.

•Prueba beta. Es la búsqueda de bugs en el programa completo.

Generalmente es hecha por usuarios.

•Prueba de mutación. Esta prueba esta basada en la introducción deliberada de diferentes códigos externos al programa (bugs) para reexaminar si estos bugs pueden ser detectados. Requiere gran disponibilidad de recursos de computación.

¿Cuales son los cinco problemas mas comunes en el desarrollo de procesos. ?

•Pobre definición de requerimientos. Es normal que se comience a trabajar en base a requerimientos que estan en bruto, si no hay una buena prueba de requerimientos con el usuario se crearan problemas.

•Planificación irreal. Planifica sobre supuestos para acortar el tiempo de desarrollo, los problemas serán inevitables.

•Pruebas inadecuadas. Es imprescindible asegurarse que el programa funciona antes de la entrega al usuario.

•Falta de comunicación. Si desarrolladores de programas, clientes o usuarios y directivos del proyecto tienen una mala o escasa comunicación los problemas estarán garantizados.

•Carencia de rasgos. Definir nuevos rasgos una vez que el programa se haya terminado es muy común y genera problemas. Se deben definir las características del programa.

¿Cuales son las cinco soluciones para los problemas de desarrollo?

•Requerimientos sólidos. Deben ser claros, completos, detallados, probables, posibles, cohesivos y coherentes. Son imprescindibles los prototipos para que se cumplan estas condiciones.

•Planificación real. Se debe ser sincero y dedicar el tiempo adecuado a la planificación. Esto agilizara el diseño, la prueba y dará tiempo a posibles cambios.

•Pruebas adecuadas. Las pruebas deben ser tempranas y adecuadas durante el desarrollo pudiendo establecer puntos de prueba (checkpoints) en caso de cambios, y pruebas finales una vez concluido el programa.

•Comunicación continua. Con la tecnología existente hoy en dia, un buen profesional debe poder utilizar todas las herramientas posibles, desde teléfonos celulares, e-mail, hasta reuniones formales e informales en los diferentes ámbitos que conciernan al desarrollo del software.

•Seguimiento de rasgos. Es deseable realizar una buena preparación de las características a seguir por el programa. Interfaces, salidas, equipos etc. Una buena prototipación de las entradas y salidas es lo ideal para defenderse de posibles cambios y potenciales problemas.

¿Cómo realizar un buen código?

Un Buen código es aquel que funciona sin bugs, además debe ser legible y mantenible, se debe ajustar a los estandares de la organización para que todos los desarrolladores del sistema manejen y entiendan las mismas herramientas y mecanismos en la codificación.

A continuación definiremos reglas que la mayoría de las organizaciones consideran importantes para evitar problemas en la mayoría de los lenguajes de programación mas usados como el C, C++.

•Minimizar el uso de variables globales.

•Nombres descriptivos de funciones, variables, módulos, objetos y métodos.

•Minimizar el tamaño de funciones, métodos y procedimientos. Acercamiento al caso ideal de no exceder las 50 líneas.

•Descripciones deben ser cortas y claras para no confundir la lectura del código.

• Organización de los métodos, una buena disposición del código hará que futuros cambios sean posibles.

•Uso generoso de espacios en blanco.

•Es importante que cada línea de código no supere los 70 caracteres.

•Una sentencia por línea.

•Es fundamental que el grupo de desarrolladores respete el mismo estilo de codificación.

•Toda aplicación debe ser documentada no importa lo pequeña sea dicha aplicación.

¿Cómo pueden las nuevas herramientas automatizadas de prueba simplificar el proceso de detección de errores ?

Una de las herramientas automatizadas que a logrado ser muy popular en el entorno del diseño de software, por su simplicidad y, además, por el ultimo gran disgusto en cuestion a problemas de software, el efecto Y2K, es la herramienta RECORD-PLAYBACK, al ejecutar dicha aplicacion antes de hacer correr el programa a probar, se activa la opción récord, el tester navega por las diferentes aplicaciones del software, menús, cuadros de dialogo, plantillas, tablas, botones, y los resultados son grabados en forma de texto para un reporte, y en el lenguaje de la herramienta en un archivo de grabado, cuando nuevas aplicaciones son agregadas al software o son modificadas las aplicaciones actuales, la opción playback de la herramienta navega automáticamente por el programa y luego emite un reporte de resultados y operaciones aun no testeadas.

Otras herramientas automatizadas existentes en el mercado son:

•Analizador de código. Es una especie de depurador externo que examina además de las sentencias, los caminos e hilos del programa.

•Analizador de cobertura. Solamente prueba las ramas y caminos de todas las funciones que trabajan, internamente o externamente, con el programa.

•Analizador de memoria. Evalúa si las aplicaciones no exceden los limites de memoria en los peores casos, o situaciones criticas.

•Perfomance de carga. En sistemas cliente servidor, esfuerza al programa para que trabaje con cargas pesadas y en situaciones extremas.

•Analizador de sitios WEB. Examina los enlaces y las aplicaciones en los diferentes nodos y en el servidor.

•Reporte de bugs. Trabaja en conjunto con analizadores de código y de cobertura, haciendo un reporte de las partes de códigos no examinadas o confusas.

•Reporte de configuración. Hace un reporte de los requerimientos del programa en cuestión a hardware y los parámetros mínimos que se deben cumplir para que el software pueda trabajar al máximo.

•Reporte de desempeño. Hace un reporte del nivel de desempeño, aplicación por aplicación  del programa en el hardware instalado.

INTRODUCCION AL SOFTWARE TESTING

El Software testing o como se conoce en español las pruebas de software se aplican como una etapa más del proceso de desarrollo de software, su objetivo es asegurar que el software cumpla con las especificaciones requeridas y eliminar los posibles defectos que este pudiera tener. En un principio la mayoría de  empresas de desarrollo contaban con una etapa de pruebas demasiado informal, en la actualidad el software testing se ha convertido en una de las etapas más críticas del ciclo de vida del desarrollo de software y esto ha causado el origen de diversas metodologías. 

En la actualidad el software testing se hace más complicado ya que debe hacer frente a una gran cantidad de metodologías de desarrollo, lenguajes de programación, sistemas operativos, hardware etc.

 

Es por esto que el testing debe apoyarse en metodologías generales que revisan los aspectos más fundamentales que debe considerar todo proceso de pruebas. Debido a esta complejidad actualmente se cuentan con una gran cantidad de software diseñado exclusivamente para la etapa de pruebas, incluyendo la gestión del proceso de software testing, la administración y seguimiento de errores, la administración de los casos de prueba, automatización de pruebas etc.

Luego de culminadas las etapas de análisis, diseño y desarrollo se inicia la etapa de pruebas, en esta etapa lo recomendable es que el software se mantenga en un ambiente aislado o separado del ambiente de desarrollo o de producción, lo ideal es preparar un ambiente de pruebas lo más parecido a los ambientes que existen en producción para asegurar su correcto funcionamiento en esa futura etapa, se debe considerar adquirir un equipo de pruebas especializado “software tester” o analista de pruebas, con experiencia, estas personas tienen una formación que les permite detectar una gran cantidad de errores en tiempos mínimos, así como una metodología especifica que les permite hacer el trabajo de manera correcta, algunas empresas más informales utilizan a los futuros usuarios del sistema como testers situación que puede traer una serie de problemas debido a la poca experiencia que pueden tener los usuarios en la detección de errores, además se obvian pruebas importantes como las pruebas de Esfuerzo o “Stress testing”, también se dejan de lado las pruebas unitarias o pruebas modulares, las que deberían asegurar que cada modulo del sistema trabaje correctamente de manera independiente, otro error muy conocido en empresas de software es el uso de los mismos desarrolladores como analistas de pruebas, es muy difícil probar con objetividad un software si nosotros mismos lo hemos desarrollado, un técnico o analista programador empezara a probar con la idea preconcebida de que su hijito trabaja a la perfección e inconscientemente evitara realizar pruebas mas exhaustivas considerando que las mismas podrían ser absurdas o innecesarias, lo bueno es que poco a poco estas ideas van quedando descartadas y se van alineando conceptos hacia un software testing profesional.

Para mayor información consulte aquí.

Ing. Gustavo Rojas Llanos