sábado, 17 de octubre de 2015

Ciclo de Vida de un Defecto de Software

Dentro de las pruebas de Testing uno de los objetivos comunes es detectar defectos en las aplicaciones, tipicamente las incidencias que vemos mientras probamos las aplicaciones las reportamos (Diferencia entre lo esperado y el resultado real) y es necesario darles seguimiento oportuno hasta que se confirme su solución.


Además el reporte de estas incidencias persiguen ciertos objetivos especificos como pueden ser:
  • Ayudar a los desarrolladores a detectar en donde se encuentra el defecto.
  • Proporciona a los lideres una visión de la calidad del sistema y el progreso de las pruebas.
  • Ayudar a mejorar el proceso de desarrollo y de pruebas.
A continuación vemos el clico clasico de las incidencias y basicamente buscamos que como minimo el reporte de una incidencia contenga lo siguiente:
  • Fecha en la que se esta detectando el problema.
  • Nombre de la persona que lo detectó.
  • Objetivo, severidad y Prioridad de la incidencia.
  • Descripción (Pasos a seguir para reproducir la prueba, resultados esperados VS Reales).



Cada compañia o departamento pudiera tener su propia versión del ciclo de vida dependiendo del sistema utilizado para el seguimiento de ellas, desde papel y lapiz hasta una herramienta como HP ALM, Bugzilla, TFS, JIRA, etc.


Reportado.- Corresponde al primer Estatus una vez que hayamos creado el reporte de la incidencia.
Rechazado.- Cuando después de ser revisado por el Comité encargado o por el equipo de desarrollo se determina que el reporte no es válido. Ya sea que falta detalle en el reporte o que lo reportado no corresponde a un defecto en la aplicación sino en otra cosa.
Abierto.- Cuando después de ser revisado se reconoce como un defecto de la aplicación o falla en base de datos, ambiente, etc. En fin algo que necesita la atención del equipo de desarrollo o alguien más para su corrección.
Diferido.- Cuando después de ser analizado por parte del equipo de desarrollo se determina que no se será arreglado. Las razones pueden ser varias, por ejemplo que el costo de arreglar el defecto sea mucho comparado con el impacto que el defecto tiene en el sistema.
Asignado.- Una vez que se analizo el defecto se asigna a la persona indicada para su reparación.
Arreglado.- La persona asignada a reparar el defecto hizo los cambios necesarios para su resolución, normalente después de este paso regresa a quien lo reporto o al equipo de Testing encargado de la aplicación.
Reabierto.- Es cuando el equipo de Testing o quien reporto el defecto originalmente prueba la solución pero el defecto se sigue presentando de la misma forma que se reporto originalmente o con cierta variación pero que sigue pasando en el sistema.
Cerrado.- Este estatus significa que quien reporto el defecto originalmente o el equipo de Testing han verificado que el defecto ya no se presenta dentro del sistema. Si el defecto reaparece en una versión más adelante se procede a re-abrir el defecto.


A continuación el ejemplo de bugzilla:
https://landfill.bugzilla.org


El mapeo que podemos hacer de estos que trae bugzilla (Estos son los que encontramos en la pagina de prueba de bugzilla, sin embargo son editables por el administrador, asi que pueden diferir)


Unconfirmed = Reportado
Confirmed = Abierto
In_Progress = Asignado
Resolved & Fixed = Arreglado
Resolved & Invalid = Rechazado
Resolved & Wontfix = Diferido
Resolved & Duplicate = Rechadado
Resolved & Worksforme = Rechazado
Verified = Cerrado
Confirmed = Reabierto (Ya que de verified nos permite regresar a Confirmed).

Como mencione anteriormente en otras herramientas pudieran existir otros Estatus, pero cualquiera se puede mapear a este ciclo generico mencionado por lo que teniendo claro este podemos adaptarnos facilmente a cualquier herramienta.

martes, 11 de agosto de 2015

Niveles de Prueba

Los niveles de Prueba considerados por ISTQB son 4:


1.- Pruebas de Componente

Comprueban el funcionamiento de módulos de software, programas, objetos, clases, etc. Por separado.
Pueden utilizarse “stubs”, controladores y simuladores.
Por lo general, los defectos se corrigen en el momento en que se detectan, sin gestionarlos formalmente.

Las pruebas unitarias caen típicamente en este nivel por lo que es común que el equipo de desarrollo se encargue de ellas.

  
2.-  Pruebas de Integración.

Prueban las interfaces entre los componentes, las interacciones con distintas partes de un mismo sistema (como el sistema operativo, el sistema de archivos y el hardware), y las interfaces entre varios sistemas.
Es muy útil conocer la arquitectura del sistema para diseñar pruebas de integración eficientes.
Las pruebas se deben de enfocar solo en la integración entre sí, no en la funcionalidad.
Las pruebas No Funcionales (por ejemplo, de Rendimiento) pueden ser validadas en este nivel de pruebas

Dependiendo de la naturaleza de la aplicación y la complejidad para probar las integraciones en este nivel de pruebas suelen participar tanto el área de desarrollo como el área de pruebas

 
 3.- Pruebas de Sistema

Deben de estar enfocadas a detectar fallas en el objetivo principal del sistema.
Se pueden incluir las pruebas basadas en riesgos o en requerimientos, procesos de negocio, casos de uso u otras descripciones de alto nivel.
En estas pruebas se deben incluir pruebas Funcionales y No funcionales.
Típicamente realizadas por el área de pruebas.



En la siguiente imagen vemos 3 engranes, digamos que corresponden al funcionamiento interno de un reloj.
Basado en esta imagen las pruebas de Componente corresponden a las hechas para verificar que cada uno de los 3 engranes mostrados esta correctamente construido, las pruebas de Integración corresponden a verificar que estos 3 engranes funcionan juntos, en este caso tal vez confirmar que pueden girar sin problema al estar juntos.  Las pruebas de Sistema tendran que ver con verificar que el Reloj es el que funciona para dar la hora, no atrasarse o adelantarse, etc, etc.


4.- Pruebas de Aceptación.

El objetivo principal es verificar la idoneidad de uso del sistema por parte de los usuarios finales/comerciales.
Los criterios de aceptación deben establecerse en el momento en que las partes aceptan contraer dicho contrato.
Pruebas alfa: se llevan a cabo en la organización de desarrollo, pero no las realiza el equipo de desarrollo.
Pruebas beta: también conocidas como “pruebas de campo”, las realizan los clientes en sus propias instalaciones.

Por su naturaleza son normalmente ejecutadas por el usuario final aunque cabe señalar que en muchas ocasiones con cierto apoyo o guía de parte del área de pruebas.

lunes, 4 de mayo de 2015

Test Scenario Vs Test Case Vs Test Script

Test Scenario Vs Test Case Vs Test Script


Parece ser que este tema no es del todo claro, esto es basicamente una traducción del articulo que pongo como referencia al final.


Requerimiento:



==================================================================
Escenario de Prueba:
Por definición un Escenario de prueba es la clasificación a alto nivel de los requerimientos a probar dependiendo de una funcionalidad o un modulo. Por cada Escenario se espera que haya al menos un Caso de Prueba, sin embargo un caso normalmente significara que solo se esta probando el "Happy Path".

Por ejemplo:



En este ejemplo se identificaron 2 requerimientos y se definieron 4 casos de prueba para uno y 6 para otro.
==================================================================
Caso de Prueba
Un caso de prueba es el procedimiento a seguir paso a paso para los diferentes caminos validos e invalidos de un Escenario de prueba. Un caso de prueba con una fuincionalidad valida es conocido como Caso de prueba positivo y un Caso de prueba con funcionalidad invalida es llamando Caso de prueba negativo. Un Escenario de prueba puede tener uno o mas Casos de prueba asociados a el.
Un Caso de Prueba contiene:
Identificador del escenario al que esta asociado
Identificador del Caso de Prueba
Nombre del Caso de prueba (Usualmente el objetivo de la prueba)
Descripción del Caso de prueba
Precondiciones
Pasos a seguir
Resultado esperado
Resultado Actual
Estatus
Comentarios
Por ejemplo: Escenario ID UC0001





==================================================================
Script de Prueba:
Aqui viene la parte dificil de explicar. Para la mayoria significa un Caso de prueba automatizado pero no lo es del todo cierto.
Digamos que es un caso de prueba fabricado con datos de prueba, es decir, que un solo caso de prueba se puede hacer con diferentes datos lo cual lleva a diferentes Scripts de prueba de un solo Caso de Prueba, por lo tanto pueden ser:
Manual: Son casos de pruebas manuales que se pueden probar con diferentes datos de prueba.

Automatizado: Casos de prueba programados para ser ejecutados con diferentes casos de prueba y ejuecutados por una herramienta (ALM - UFT, Sellenium, etc)>

Ejemplo de Script de Prueba Manual




Ejemplo de Script de Prueba Automatizado








===============================================================