domingo, 29 de enero de 2012

Algunas de las razones para implementar las pruebas en su empresa


Hay muchas razones para desplegar un equipo de pruebas de software en una empresa. Varias empresas aún no son conscientes de la importancia de las pruebas de software. Sin embargo, la mayoría de los procesos de desarrollo ofrece actividades de verificación y validación, incluso en procesos ágiles.

Cuando el software se entrega al cliente sin pruebas, puede causar varios problemas para la compañía que desarrolló, además de daños en el cliente. Como hay varios tipos de pruebas de software, hay empresas que prefieren adoptar las pruebas unitarias, realizadas por el programador y otras empresas inviertan en las pruebas funcionales, desarrollado y implementado por un equipo de prueba especializado.

Seguigo se presentan algunas de las razones para implementar las pruebas en su empresa:
  1. Cuando un producto no se prueba, hay una gran chance de tener defectos en este producto, así este producto no satisface las necesidades del cliente.
  2. Cuando el cliente no está satisfecho con el producto no va a contratar a la compañía otra vez.
  3. Cuando no se produce un producto con calidad, la compañía se queda con una imagen negativa, por lo que requiere una mayor inversión en marketing.
  4. Si se encuentran errores por parte del cliente, el costo para corregir estos errores es mucho mayor que cuando el sistema está todavía en desarrollo.
  5. Cuando no hay un equipo para probar el sistema, el gestor requiere de los programadores un sistema de calidad, pero eso es difícil porque no siempre pueden ver sus propios errores.
  6. Con las pruebas, usted puede tener una mayor seguridad de que el sistema no tiene errores graves, que, cuando hay, puede causar gran daño al cliente.
  7. Con las pruebas, los nuevos clientes estarán interesados ​​en sus sistemas debido a las recomendaciones.
  8. Con las pruebas, los programadores, aunque no parece, están más satisfechos y motivados con elogios para el sistema por el cliente, ya que no encuentra muchos errores.
  9. Con las pruebas, minimiza la necesidad de contestar el teléfono para ayudar a los usuarios a utilizar el sistema, luego hay uno costo más bajo de mano de obra para el servicio de asistencia.
  10. Cuando hay un equipo de prueba para probar el sistema, todo el mundo gana: el dueño de la empresa (menos gasto en marketing y más prestigio para la empresa), el cliente (satisfacción y confianza en el sistema), los usuarios (puede usar un sistema útil y correcto), los programadores (la motivación para la creación de sistemas de calidad) y probadores (más puestos de trabajo).

Artículo 4 es uno de los puntos más importantes a tener en cuenta, porque cuando un sistema se entrega al cliente sin ser controlado por el equipo de pruebas, se trasladará a la etapa de "mantenimiento" y en esta etapa, el equipo que desarrolló el sistema ya ha sido asignado para un nuevo proyecto. Como no es posible predecir la demanda para correción del sistema, es probable que sea una sobrecarga de tareas para los desarrolladores. De este modo, el nuevo proyecto se hace más lento, ya que parte del equipo tendrá que ser asignado de nuevo al proyecto anterior. Además, si el equipo que desarrolló el sistema no trabaja más en la empresa, entonces el costo para arreglar los defectos será aún mayor, como un programador que nunca ha visto que el sistema tendrá dificultades en la corrección de errores del sistema, sólo se necesita más tiempo y por lo tanto más coste para la empresa.


Por lo tanto, es importante pensar dos veces antes de decidir no poner un equipo de pruebas en su empresa para poner a prueba todos los sistemas desarrollados. Las razones abundan en este momento para crear un equipo de pruebas. Si su empresa ya cuenta con un equipo de prueba, ellos deben ser valorados, así como el futuro de la empresa puede depender de este equipo.

Como decidir si las pruebas deben ser automatizadas?

Antes de usar cualquier herramienta a automatizar sus pruebas, es necesario analizar varios factores que definirán el éxito o el fracaso de sus pruebas. Algunas herramientas pueden no ser suficientes para representar a todas las pruebas, en este caso no tiene sentido usarlos.
Además, el software que se está probando puede ser actualizado constantemente, donde sus componentes son modificados, así los casos de prueba automática también tendrán que ser cambiados, de lo contrario no se volverán a ejecutar.


Los siguientes son algunos de los factores [1] que pueden ayudar a decidir si las pruebas deben ser automatizadas o no.


1. Frecuencia de aplicación: Es importante tener en cuenta la cantidad de veces que desea ejecutar las pruebas, aunque sólo sea una vez, la ejecución manual puede ser suficiente.
 

2. Generación de código reutilizable: el código para probar un caso de prueba se puede reutilizar fácilmente en otro caso de prueba, entonces esto puede ser una buena razón para usar cualquier herramienta de automatización.
 

3. Relevancia de la prueba: si una función se utiliza con más frecuencia que otras, a veces vale la pena la creación automática de casos de prueba para que, por ejemplo, casos de prueba para ingresar a la aplicación.
 

4. Esfuerzo por automatizar, hay que tener en cuenta si vale la pena el esfuerzo para automatizar un script de prueba teniendo en cuenta la cantidad de veces que este script se puede ejecutar y si hay casos de prueba reutilizable.
 

5. Las herramientas de automatización: para cada tipo de sistema que se prueba se pueden utilizar diferentes herramientas para automatizar las pruebas. Esto debe ser considerado cuidadosamente antes de decidir qué herramienta se utiliza.
 

6. Difícil de ejecutar la prueba de forma manual, a veces unos casos de prueba se deben realizar a fondo para un conjunto de diferentes usuarios, en este caso no es factible llevar a cabo los usuarios de prueba múltiple. Por lo tanto, la automatización es necesario.
 

Por lo tanto, estos y otros factores pueden ser considerados en el momento de decidir si las pruebas serán automáticas o manuales. Pero siempre es bueno recordar que el propósito principal de un caso de prueba (automática o no) es encontrar errores en el sistema.
 

[1] J. C., Oliveira, C. C., Gouveia, R. P., Son. A way of Improving Test Automation Cost-Effectiveness. Artículo publicado en CAST'06, Indianápolis, EE.UU., 2006.
 

SUGERENCIA:. La revista Testing Experience de Deciembre/2010 esta disponible en este blog en "revistas digitales gratis". Ella es acerca de las herramientas de pruebas de software, vale la pena un vistazo. :)


Testing Experience - The Magazine for Professional Testers
Testing Experience - 12ª Ed. Dez/2010

Herramientas para Pruebas de Software

Todas las herramientas abajo son de código abierto. Esta lista fue creada a partir de una encuesta llevada a cabo en grupos de discusión de pruebas, donde los participantes listaran las herramientas más utilizadas en las compañías donde trabajan.

Pruebas Funcionales para Aplicaciones WEB:
  •      Selenium - http://seleniumhq.org
  •      Watir - http://wtr.rubyforge.org
  •      BadBoy - http://www.badboy.com.au
  •      actiWATE - http://www.actiwate.com
  •      Canoo WebTest - http://WEBtest.canoo.com
  •      Apodora - http://www.apodora.org

Pruebas de Desempeño
  •      JMeter - http://jakarta.apache.org/jmeter
Gerencia de Casos de Prueba
  •      TestLink - http://www.teamst.org
  •      TestMaster - http://testmaster.sourceforge.net
Gestión de Defectos
  •      Bugzilla - http://www.bugzilla.org
  •      Mantis - http://www.mantisbt.org
  •      Redmine - http://www.redmine.org
  •      JIRA - http://www.atlassian.com/software/jira

La importancia de las pruebas de regresión

Las pruebas de regresión se realizan generalmente después de la corrección de un defecto o después de la adición de nuevas funcionalidades. Su objetivo es asegurar que ningún defecto se añadió al sistema después de la modificación. No sirve para nada hacer pruebas en un sistema, pero después de modificaciones no hacer de nuevo las mismas pruebas, eso no va asegurar que el sistema no tiene defectos.

Llamamos prueba de regresión, porque tenemos que hacer nuevas pruebas donde se han probado antes. Por lo general, este tipo de pruebas se realiza a través de herramientas de automatización de pruebas, pues muchas veces hay falta de tiempo para ejecutar casos de prueba ya ejecutadas, así las pruebas de regresión se deja a un segundo plano. Sin embargo, este es un grave defecto que los equipos están poniendo. Las pruebas de regresión, a veces se puede encontrar más defectos que en la primera prueba, esto es debido al tester tener más familiaridad con el sistema y al vuelver a ejecutar los casos de prueba es posible detectar otros tipos de defectos donde en la primera ejecución fue inadvertido.

Para que las pruebas de regresión sean ejecutadas de manera rápida, es necesario que el líder de calidad tenga ciencia de la necesidad de este tipo de prueba, para que pueda planear la ejecución de pruebas de regresión y haciendo un aumento del tiempo de la actividad de la prueba.

El plan de casos de prueba de regresión puede ser de tres tipos:
  • Los casos de prueba que cubren toda la funcionalidad del sistema.
  • Los casos de prueba sólo para las características que han sido modificados.
  • Nuevos casos de prueba para las características que se vieron afectadas probablemente por el cambio.
Las pruebas de regresión es una forma efectiva de reducir la cantidad de defectos que se pueden encontrar en un sistema.

El Papel del Probador de Software

El probador de software es responsable de las actividades dentro del proceso de desarrollo para asegurar la calidad del sistema en desarrollo. La actividad de las pruebas por lo general comienza desde el momento en que hay un documento de especificacione del sistema. Con el documento de especificación se puede realizar la inspección de la especificación, utilizando uno checklist, lo que garante que el documento es consistente.

Entonces, el proceso de elaboración del Plan de Prueba es seguido por la revisión del plan, que es hecho por otro miembro del equipo. Después de que el sistema está en funcionamiento, las pruebas se realizan de forma manual o automáticamente, donde se registran los resultados en un informe de error, que indica que las pruebas se han aprobado o no. Este informe de errores se pasa al programador del sistema, para que se corrijan los defectos en el sistema. Después de corregir los defectos, los planes de prueba son ejecutados de nuevo para comprobar si los defectos se han corregido o se han añadido nuevos errores en el sistema.

Cuando el sistema pasa en todas las pruebas, él puede ser enviado a la producción. No siempre el Plan  de Prueba cubre el 100% de las funcionalidades del sistema, por eso hay técnicas, secuencias de comandos y herramientas que ayudan en la preparación de los planes de prueba. Cuanto  mayor es la calidad del Plan de Prueba, mayor será la calidad del sistema en prueba.

El probador por lo general tiene actividades relacionadas con pruebas de caja negra, es decir, pruebas funcionales, donde el probador no tiene acceso al código del sistema. El programador es responsable de pruebas de caja blanca, que las pruebas se llevan a cabo utilizando el código del sistema .

Checklist de Control de Calidad

General
  • Revisar la ortografía de los mensajes y los campos.
  • Verifique si los campos de opción "radio button" no se puede marcar dos opciones al mismo tiempo.
  • Comprobar el layout del sistema, trate de mantener su aspecto lo más cerca posible con el prototipo. También se debe comprobar si los campos y las tablas se alinean con respecto a otros campos.

Buscar y Filtrar

  • Verificar la lógica de los mensajes. Ejemplo: campo de filtro para el período comprendido entre los años ____ a ____ poner el _2000_a _1500_ años deben recibir el mensaje "El último año debe ser mayor que la inicial" y en el caso de poner el año _1500_a _2000_ el mensaje no debería aparecer.
  • Haz combinaciones de filtros y comprobar que los resultados se incluyen en los filtros seleccionados.
  • Compruebe el orden de la lista (ver especificaciones).
  • Compruebe el orden de los campos de "combo box" (ver especificaciones).
  • Comprobar si los campos están activados o desactivados como se especifica.
  • Preste atención a los errores de JavaScript.
  • Rellene los campos de texto con caracteres especiales y / o caracteres no válidos.
  • Si usted no puede llenarse con caracteres no válidos desde el teclado, intente ctrl + v y pasta con el mouse.
  • Compruebe si el botón Limpiar está limpiando todos los campos correctamente.
  • Los campos de texto debe ser posible buscar una subcadena. Ejemplo: Para buscar a una empleada llamada Ana Paula Muniz, si escribo en el campo de consulta "Ana" debe mostrar todos los empleados que tienen la palabra Ana, y Ana María o Luciana, etc.
  • Compruebe las especificaciones que debe venir campos ya rellenados.
Catastro
  • Rellene los campos de texto con caracteres especiales y / o caracteres no válidos.
  • Si usted no puede llenarse con caracteres no válidos desde el teclado, intente ctrl + v y pasta con el mouse.
  • Comprobar si los campos están activados o desactivados como se especifica.
  • Al confirmar la operación de registro, verificar que apareció un mensaje que indica que el tema fue registrado.

Mostrar

  • En la pantalla, hay que estar muy atento a la coherencia de los datos, un tipo que fue inscrito en el registro debe necesariamente aparecer en la pantalla con su respecitiva máscara.
  • Usted debe ser consciente cual el valor que debe aparecer en el caso de un campo no ser llenó. A veces, el campo se queda vacío y a veces un caractere debe aparecer.
  • Compruebe que en la pantalla esté todos los datos modificados se muestran correctamente, incluso esté atento a las máscaras.

Actualización

  • Este debe ser el caso de pruebas más riguroso y se debe hacer con más cuidado.
  • Compruebe que los campos actualizados se han hecho. Esta comprobación debe hacerse tanto en la pantalla de actualización como en la exhibición.
  • Compruebe si la pantalla de actualización todos los campos fuerán cargados correctamente.
  • Ejecute el flujo del actualización más de una vez para asegurarse de que no hay datos que se mantienen en la sesión.
  • Compruebe los campos actualizados que son parte de un pop-up. Porque con frecuencia los cambios que se realizan en el pop-up se pierden cuando se cierra la ventana.
  • Compruebe que los datos registrados en el pop-up están correctos.
  • Cuando hay una tabla donde usted puede introducir los datos y retírelos antes de registrarse, haz una prueba de carga para ver si los datos se mantienen y se eliminan correctamente.
  • Al confirmar la operación de actualización, compruebe si hay un mensaje de que el tema se ha actualizado.
Borrar

  • Intenta eliminar un registro, en el alerta de confirmación clic en Cancelar y luego verificar que el registro no se ha eliminado.
  • Tratando de eliminar un registro, en el alerta de confirmación clic en Aceptar y luego compruebe si el registro ha sido borrado.
  • Realice una búsqueda y compruebe si la exclusión se llevó deveras.
  • Compruebe si hay un mensaje sobre el tema que se ha eliminado.

Relatos

  • Tener mucha atención sobre los datos que hacen parte del relato, al hacer un filtro de datos, debese comprobar que sólo aquellos datos seleccionados son parte del informe.
  • Verificar que el layout del informe es idéntico al prototipo.
  • Revise la ortografía de los informes.
  • Compruebe problemas de agrupación de las columnas cuando los datos se repiten en la misma columna, esta información debe estar presente en el prototipo o en la especificación.

Casos de Prueba Fundamentales I

Hay varios tipos de casos de prueba fundamental que no pueden dejar de ser parte del Plan de Prueba:
 
i. Layout: Al principio de cada plan de prueba, tiene que hacerse casos de prueba específicos para cada pagina del sistema.

ii. Los campos obligatorios: los casos de prueba que verifique si los campos están siendo tratados adecuadamente. Por ejemplo: Asegúrese de dejar en blanco un campo obligatorio y si aparece el mensaje.

iii. Máscara:
Asegúrese de que los campos se están llenando con sus máscaras. Por ejemplo: El campo fecha debe ser llenado con la máscara NN/NN/NNNN.

iv. Valores posibles: Asegúrese de que los campos están siendo validados en el caso de recibir valores no permitidos. Por ejemplo, los campos numéricos no deben aceptar los caracteres especiales y / o letras.

v. Los valores nulos: Comprobar si un campo sólo puede aceptar valor distinto de cero si se acepta menor o igual a cero.

vi. Límites: Compruebe el máximo y el mínimo valor permitido para cierto campo. Prueba si se inserta un valor fuera del límite y si el mensaje adecuado se aparece.

vii. La verificación de los caracteres especiales: Asegúrese de que los campos de texto aceptan caracteres especiales.

viii. La validación de los campos (fecha): Compruebe si la fecha introducida es válida.

ix. Los eventos del mouse: las pruebas de conducta para copiar y pegar texto con el mouse y verifique que estos campos están siendo validados correctamente.

x. Los espacios en blanco: un campo obligatorio, rellenar con espacios en blanco y compruebe si el sistema detecta que el campo sigue vacío.

xi. Ortografía:
Asegúrese de que cualquier texto en el sistema no hay errores de ortografía, incluso los mensajes de alerta.

lunes, 23 de enero de 2012

Los 10 Principios de las Pruebas de Software

Por lo general muchos de los principios de las pruebas de software parecer obvio, pero en realidad sabemos que son muy útiles en el momento de la prueba, que crea una barrera de la conciencia en el tester, que se hará más crítico en el desarrollo de casos de prueba y al ejecutar la prueba.

Principio 1: Una parte importante de una definición de caso de prueba es un resultado esperado.

Si el resultado esperado no se hay definición previa, los resultados con error pueden ser considerados correctos. Debido al fenómeno de que "los ojos ven lo que quieren ver." Hay un deseo inconsciente de ver el resultado correcto. Una manera de probar esto es hacer un análisis detallado de todos los puntos de venta en busca de un hechizo perfecto, antes de comprobar los resultados esperados por el programa.

Principio 2: Un programador debe evitar tratar de pruebar su propio programa.

Por lo general, una persona no le gusta encontrar errores en su propio trabajo o el programa. Si el programador ha cometido un error cuando hizo el código, es natural que no debe encontrar este error en el momento de la prueba. Pero en el caso de depura la realización es más eficiente cuando se hace por el programador.

Principio 3: Los casos de prueba no deben ser grandes y exhaustivos.

Un buen plan de pruebas tiene casos de prueba que son ejecutados fácilmente por el tester, que no se ejecutan de una manera ambigua. Para ello, los casos de prueba tienen que estar bien escrito y objetivo, pero también debe tener la menor cantidad de pasos.

Principio 4: Analizar a fondo los resultados de cada prueba.

Es la gente normal no detectar ciertos errores, incluso cuando estos errores pueden ser claramente observados en uno checklist o plan de prueba.

Principio 5: Los casos de prueba deben ser escritos con las entradas que no son válidos y inesperados, así como entradas válidas y esperadas.

Principio 6: Examinar un programa para ver si hace lo que se propone es sólo la mitad de la batalla, la otra mitad es comprobar si el programa hace lo que se propone.

Este es un corolario del principio anterior. Los programas deben ser probados debido a problemas secundarios indeseables. Por ejemplo, un programa de nómina que realiza pagos bueno es malo cuando se produce la nómina para los empleados que no existen.

Principio 7: Evite los casos de prueba desechables a menos que el programa también está disponible.

Muchas veces, el tester ejecuta los casos de prueba aleatoriamiente y cuando se necesita para volver a probar que el programa de nuevo tiene que dedicar tiempo a crear nuevos casos de prueba. Un problema es que por lo general la nueva prueba no es tan rigurosa como la prueba inicial. Por lo tanto, si una nueva característica para provocar un fallo, es probable que no serán detectados. Mediante el almacenamiento de los casos de prueba en un documento y volver a correr de nuevo en cada iteración se conoce como prueba de regresión.

Principio 8: Nunca tome una prueba de asumir que no hay errores serán encontrados.

Esto es un error que los diseñadores crear y probar por lo general es un signo de mal uso de la definición de la prueba. La definición correcta es que la prueba es un proceso de ejecución de un programa con la intención de encontrar errores.

Principio 9: La probabilidad de encontrar más errores en una sección de un programa es proporcional a la cantidad de errores que ya se encuentraran en esa sección.

A pesar de hacer poco sentido, esto ocurre con más frecuencia. Por ejemplo, un programa consta de dos módulos A y B, donde «A» 5 se han encontrado errores y "B" sólo se encontró un error. La probabilidad de encontrar más errores en la 'A' para una segunda ronda de la prueba es mayor que la probabilidad de encontrar más errores en el 'B', porque, como en 'A' tuvo más errores que en el 'B' para corregir los errores " A ', existe la posibilidad de nuevos errores. Otra hipótesis es que los errores ocurren en grupos, es decir, un error desencadena otro, y también algunos sectores son más propensos a los errores que otros.

Principio 10: Hacer prueba es una actividad muy creativa y intelectualmente desafiante.

Es probablemente cierto que la creatividad necesaria para poner a prueba un programa de grandes es mayor que la creatividad necesaria para crear ese programa. Sabemos que es imposible tener 100% de los errores. Hay muchos métodos para crear casos de prueba, pero estos métodos todavía necesita mucha creatividad.

Por lo tanto, al analizar todos los principios que podemos extraer de los tres principios fundamentales que son:
  1.     La prueba es un proceso de ejecución de un programa con la intención de encontrar errores.
  2.     Una buena prueba es la que tiene una alta probabilidad de encontrar un error desconocido.
  3.     Un caso de prueba excelente es el que encuentra un error no se descubre.

Referencia:

MYERS, G. J. Las Artes de pruebas de software - 2da. ed. John Wiley & Sons, Inc., EE.UU., 2004, cap. 2 pag. 14-20.

Buenas prácticas para hacer un Plan de Prueba

Prueba de software es una área que ha crecido de manera impresionante en la Engeniería de Software, ya que reduce los costes con la manutención del sistema y evita que se ocurrán problemas futuros en el sistema, esto mejora la calidad del sistema producido [1].

Las pruebas de caja negra, cuando se realiza de forma manual, requiere la elaboración de un plan de prueba, que puede ser visto en el artículo anterior. Todavía, la calidade de estos planes de prueba es la única garantia de que las pruebas realizadas serán realmente eficientes y que ván a detectar lo máximo de errores posibles en un sistema. Desta forma, tiene sido hecho un estudio para mejorar la calidad de los casos de prueba. En seguida se puede notar algunos puntos importantes que deben tenerse en cuenta al preparar el plan de prueba.
  • Un buen plan de prueba tiene casos de prueba que són fácilmente realizados por el probador, los cuales no son ejecutados de maneira ambigua. Para eso, los casos de prueba tienem que ser bien escritos y objetivos.
  • Otro punto importante para un buen plan de pruebas es que los casos de prueba sean eficientes, en otras palabras, que alcanzen la mayor cobertura posible y que encontren el mayor número de errores .
  • Para se lograr más calidade en los casos de prueba es necesario que hagan reuniones entre los diseñadores de prueba, con el fin de identificar y clasificar los casos de prueba más importantes que deben siempre hacer parte de los planes.
  • Otra práctica importante es realizar revisiones en los planes de prueba producidos, con la finalidade de detectar fallas de compreensión o irrelevancia en los casos de prueba.
  • Un buen caso de prueba es aquel que es objetivo, en otras palabras, aquel que tiene en su procedimiento pasos referientes a una sola funcionalidad. Cuando el caso de prueba es objetivo, los probadores pueden centrarse mejor en la idea principal de la prueba.
  • Un caso de prueba debe ser también autosuficiente, en el debe estar contenido toda la información necesaria para ejecutarlo, es decir, que debe tener una descripción muy detallada acerca de la condición previa  del sistema para que el testign sea realizado.
  • Es importante evitar casos de prueba exhaustivos, con un número muy grande de pasos. Las pruebas grandes, que tomán mucho tiempo tienden a causar dispersión en el probador, y asi él termina perdiendo el foco principal de la prueba.
  • Casos de prueba que describen situaciones más cerca de las acciones de los usuarios finales son más eficientes, ya que tienen más posibilidades de encuentrarse defectos más graves.
Otra cuestión importante es mantener el equipo de pruebas siempre informados sobre el avance de los proyectos, principalmente con relación del cambio de requisitos. Pues, todas las veces que hay una nueva version del documiento de especificacion del sistema, hay que tener cambios en el plan de prueba de aquel caso de uso particular.

Por lo tanto, se puede concluir que aplicando buenas prácticas en el momiento de hacer un plan de prueba es posible obtener una mejora significativa en la ejecución de las pruebas, pues los casos de prueba se han vuelto más coerentes y tienen informaciones completas para ayudar en la ejecución por los probadores.

Referencia:
[1] Pressman, R. S. Engenharia de Software. 5 ed., McGraw-Hill, 2002.
[2] Olegpario, P. L, Bandeira, L. R. P. Boas práticas adotadas em um Projeto de Design de Testes – Um relato de experiência. Artigo publicado no II EBTS, Recife, 2007.

sábado, 18 de diciembre de 2010

Como hacer un Plan de Pruebas


El Plan de Pruebas es mucho necesario para realizar las prueblas manuales en software, como por ejemplo, en las prueblas funcionales. Los planes son creados a partir de los documentos de especificación del sistema para uno determinado caso de uso, como: reglas de negocio, guía de interfaz, modelo de base de datos. El plan de pruebas es importante en el momento de la ejecución de las pruebas, pues el probador puede realizar una lista de pasos de forma práctica, sin la necesidad de verificar todos los documentos de especificación en el momento de la ejecución, lo que permite que él se quede con el foco apenas en la ejecución.


Ultra lo que es especificado por el cliente, el plan de pruebas también contempla procedimientos que prueban la eficiencia y la correctude del programa. Normalmente el plan de pruebas es compuesto por un conjunto de Casos de Prueba, pero hay también las secciones de Localización y de Objeto de Prueba, las cuales son detalladas a seguir.

Las secciones de Localización del plan de pruebas sirven para definir en cual pantalla del software iba ser ejecutado una parte de los casos de prueba, los cuales hacen parte de aquella localización. La Localización puede ser escribida de la seguiente forma: Consultar Empleados > Mantener Empleados.

Una Localización puede contener 1 (uno) o más Objetos de Prueba, donde estos pueden ser definidos como la idea global de un conjunto de Casos de Prueba. Por ejemplo, en la localización en el ejemplo anterior, Mantener Empleados, un posible Objeto de Prueba sería Adicionar Empleados en el Sistema. Otro objeto de prueba para esta misma localización podría ser Actualización de Empleados en el Sistema.
El Objeto de Prueba puede contener 1 (uno) o más Casos de Prueba, es en los casos de prueba donde están inseridos los procedimientos necesarios para la ejecución de una determinada prueba en el sistema.
Un Caso de Prueba es compuesto por una descripción, por una precondición, por los procedimientos y por el resultado esperado, los cuales serán definidos abajo.
  • En la descripción está descrita la idea especifica do caso de prueba;
  • La precondición es un requisito para el comportamiento del sistema antes de la ejecución del caso de prueba;
  • En el procedimiento están los pasos para la ejecución del caso de prueba, este procedimiento no debe salir del foco descrito en la descripción del caso de prueba;
  • O resultado esperado describe como el sistema deberá comportarse después de la ejecución del procedimiento del caso de prueba.

Principales tipos de Pruebas de Software


Las pruebas de software son una manera de garantir una mayor calidad en un software. Con eso existen muchas maneras de se testear un programa, o sea, existen pruebas de más bajo nível y pruebas de más alto nível, los cuales podemos clasificar en prueba de caja blanca (white-box testing) y prueba de caja negra (black-box testing), respectivamente.


Las pruebas de caja branca son realizadas directamente en el código y normalmente son hechos por el programador del software, un ejemplo de este tipo de prueba es la prueba de unidad (unit testing). Sin embargo, las pruebas de caja negra son hechos de manera funcional, donde el probador no tiene contacto directo con el código del programa, así lo programa es tenido como una caja negra donde al pasar valores de entrada para esta caja y ella retorna valores de salida. Muchas veces estes tipos de pruebas son hechos por un equipo específica de probadores, los cuales utilizan la especificación de requisitos del cliente para crear un plan de casos de prueba.

Las pruebas de caja negra más comunes son la prueba funcional y la prueba de aceptación, que son semejantes, la principal diferencia es que la segunda pruebla es ejecutada directamente por el cliente, lo cual decide si acepta o no el programa. Hay también las pueblas mescladas, que pueden ser tanto caja blanca como caja negra, estas pruebas son de regresión, de integración y de cobertura.

En la imagen abajo hay la clasificación de algunos tipos de pruebas de software.
Las pruebas de regresión debén ser realizadas siempre que tener alteraciones considerables en el programa, pues en cada alteración el programador puede inserir errores en el programa que antes no existían. Así, es necesario re-ejecutar nuevamente los principales casos de prueba del plan de prueba creado para aquellas funcionalidades alteradas.

Hay también una prueba muy importante que es la prueba de cobertura. Esta prueba tiene el objetivo de verificar si el plan de prueba ejecutado, sea una prueba de unidad o un plan de prueba funcional, está cubriendo 100% del código del programa desarrollado. Hay herramientas que apoyan en la ejecución de estas pruebas, como por ejemplo, un plugin para Eclipse IDE, el Emma Coverage, disponible para Junit.

Con el entendimiento más profundo acerca de cada tipo de prueba es posible obtener maneras más prácticas hacer pruebas en un programa y así garantir una mayor calidad del software.

Referencia:

WILLIAMS, M., SUCCI, G. e MARCHESI, L. Traditional and Agile Software Engineering. Ch 8 - Black Box Testing. Ed. Addison-Wesley, 2003

Introducción a la Prueba de Software

El interés por la actividad de pruebar un software sube a la medida que la falta de las prueblas influencian directamente en el costo final de la producción de un sofware. Con eso, las exigencias por softwares con mayor confiabilidad hay motivado la creación de métodos y prácticas para el desarrollo de los softwares, para que ellos atinjan los padrones de calidad esperados. Muchos pesquisidores hay investigado los diferentes criterios de pruebas, buscando obtener una estrategia de prueba con bajo costo de aplicación, pero al mismo tiempo con gran capacidad en desvendar defectos.


Las pruebas pueden ser automáticos o manuales y ellos pueden ser clasificados en diferentes tipos: caja negra (black-box testing), caja blanca (white-box testing), prueba de unidad (Unit Testing), prueba de aceptación, puebra de integridad, puebra de desempeño, puebras funcionales, puebra de interface, pruebra de usuario etc.


Para las puebras manuales existen muchas técnicas y padrones que deben ser seguidos para que se logre una mejor calidad. Para las pruebas automáticas existen muchas herramientas que apoyan en la automación.

El objetivo de este guía és compartir con otras personas sobre sus experiencias en aspectos teóricos y prácticos relativos a la actividad de prueba de software con la intención de mejorar el desarrollo de las pruebas.