El proceso o metodología de pruebas que se utiliza por cada compañia dedicada al desarrollo de Software, consultoria o específicamente a Pruebas de SOftware puede variar un poco dependiendo del tipo de compañía y del servicio que se estará prestando, sin embargo de manera general TODOS deben cumplir de alguna manera con los siguientes puntos:
1) Planeación y Control.- Fase en la cual se definirá el alcance del proyecto, se definirá la estrategia a seguir y los criterios de entrada y salida que se consideraran. La planeación es una actividad generalmente al inicio de un proyecto, pero es importante darle seguimiento hasta la culminación del proyecto y por ello el "Control" nos ayudará a darnos cuenta que tan cerca o lejos estamos de lo planeado y que planes o estrategias nos ayudaran a mitigar cualquier riesgo, impedimento o retrase que se pudiera presentar.
2) Análisis y Diseño.- Fase para analizar con detalle los requerimientos, arquitectura, diseños, etc. Para con ello identificar las condiciones de prueba y diseñar los casos de prueba, así como identificar las necesidades especificas de Ambiente de pruebas y Datos requeridos para las mismas
3) Implementación y Ejecución.- Se desarrollan los casos de prueba definidos (Paso por paso y con los datos necesarios), se define en mejor orden para su ejecución dependiendo del tipo de configuración necesaria y alineada a las prioridades del proyecto. Después de ello se realizaran las ejecuciones de los casos de prueba, identificar los defectos de la aplicación y volver a probar loq ue sea requerido.
4) Evaluación de Criterios de Salida y Reporteo.- Corresponde a la fase o el momento en el que se revisaran los resultados obtenidos en las pruebas para tomar decisión de liberar (enviar al siguiente nivel de pruebas o producción, según sea el caso) o detener la fase para pruebas mas exhaustivas o nuevos ciclos de pruebas hasta cumplir con los Criterios de Salida. Generalmente se realiza un Resumen de las pruebas para ser presentado con todos los involucrados del proyecto.
5) Actividades para el cierre de Pruebas.- Ultima fase de las pruebas en un proyecto donde generalmente se empaquetara todo lo realizado dentro del proyecto y se analizaran las mejores practicas y cosas a mejorar para proyectos (o fases) futuras, así como los resultado generales de las pruebas.
Desmenuzaremos con detalle cada una de los puntos en entradas posteriores, si embargo es importante destacar que todas ellas son vitales y cualquier proyecto debe pasar por todos y cada uno de ellos, el nivel de formalidad de cada uno es el que pudiera variar debido a la metodología utilizada (Ágil o Tradicional), el tipo de proyecto en el que se esta trabajando. En las siguientes entradas revisaremos varios ejemplos específicos.
domingo, 25 de febrero de 2018
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:
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.
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.
- 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
===============================================================
lunes, 29 de septiembre de 2014
Los 7 principios de Testing
Aqui la lista de los 7 principios de Testing de acuerdo al libro de ISTQB.
1. Las pruebas muestran la presencia de defectos
Significa que las pruebas pueden demostrar que EXISTEN problemas, pero no que los problemas NO EXISTEN.
El objetivo principal de llevar a cabo una prueba es para detectar defectos. Trabajando bajo la premisa de que cada producto contiene defectos de algún tipo, una prueba que revela los errores es generalmente mejor que una que no lo hace. Todas las pruebas por lo tanto, deben ser diseñados para revelar tantos errores como sea posible.
2. Las pruebas exhaustivas son imposibles
Las pruebas exhaustivas tratan de cubrir todas las combinaciones posibles de datos en el software, a fin de garantizar que ninguna situación puede surgir, una vez probado el software se ha liberado. Excepto en aplicaciones muy simples, el número de combinaciones posibles de datos es demasiado alta, es más eficaz y eficiente que los ingenieros de pruebas se centren en las funcionalidades de acuerdo a riesgos y prioridades.
3. Pruebas tempranas.
Un producto (incluyendo los documentos, tales como la especificación del producto) se puede probar tan pronto como se ha creado. ISTQB recomienda probar un producto tan pronto como sea posible, corregir los errores más rápidamente posible. Los estudios han demostrado que los errores identificados al final del proceso de desarrollo por lo general cuestan más para resolver.
Por ejemplo: un error encontrado en las especificaciones puede ser bastante sencillo de solucionar. Sin embargo, si ese error se transfiere a la codificación de software, una vez descubierto el error puede ser muy costoso y consume tiempo.
4. Agrupamiento de Defectos
Los estudios sugieren que los problemas en un elemento de software tienden a agruparse en torno a un conjunto limitado de módulos o áreas. Una vez que estas áreas han sido identificadas, los administradores eficientes de prueba son capaces de enfocar las pruebas en las zonas sensibles, mientras que siguen buscando a los errores en los módulos de software restantes. Me recuerda al 80/20.
5. La paradoja del "Pesticida"
Al igual que el sobre uso de un pesticida, un conjunto de pruebas que se utilizan repetidamente en el disminuirá en su eficacia. Usando una variedad de pruebas y técnicas expondrá una serie de defectos a través de las diferentes áreas del producto.
6. La prueba es dependiente del contexto
Las mismas pruebas no se deben aplicar en todos los ámbitos. Distintos productos de software tienen diferentes requisitos, funciones y propósitos. Una prueba diseñada para realizarse en un sitio web, por ejemplo, puede ser menos eficaz cuando se aplica a una aplicación de intranet. Una prueba diseñada para una forma de pago con tarjeta de crédito puede ser innecesariamente rigurosa si se realiza en un foro de discusión.
En general, cuanto mayor es la probabilidad y el impacto de los daños causados por el software fallado, mayor es la inversión en la realización de pruebas de software.
7. La falacia de ausencia de errores
Declarar que una prueba no ha descubierto ningún error no es lo mismo que declarar que el software es “libre de errores”. Con el fin de garantizar que los procedimientos adecuados de software de prueba se lleva a cabo en todas las situaciones, los evaluadores deben asumir que todo el software contiene algunos (aunque disimulada) errores.
1. Las pruebas muestran la presencia de defectos
El objetivo principal de llevar a cabo una prueba es para detectar defectos. Trabajando bajo la premisa de que cada producto contiene defectos de algún tipo, una prueba que revela los errores es generalmente mejor que una que no lo hace. Todas las pruebas por lo tanto, deben ser diseñados para revelar tantos errores como sea posible.
2. Las pruebas exhaustivas son imposibles
Las pruebas exhaustivas tratan de cubrir todas las combinaciones posibles de datos en el software, a fin de garantizar que ninguna situación puede surgir, una vez probado el software se ha liberado. Excepto en aplicaciones muy simples, el número de combinaciones posibles de datos es demasiado alta, es más eficaz y eficiente que los ingenieros de pruebas se centren en las funcionalidades de acuerdo a riesgos y prioridades.
3. Pruebas tempranas.
Un producto (incluyendo los documentos, tales como la especificación del producto) se puede probar tan pronto como se ha creado. ISTQB recomienda probar un producto tan pronto como sea posible, corregir los errores más rápidamente posible. Los estudios han demostrado que los errores identificados al final del proceso de desarrollo por lo general cuestan más para resolver.
Por ejemplo: un error encontrado en las especificaciones puede ser bastante sencillo de solucionar. Sin embargo, si ese error se transfiere a la codificación de software, una vez descubierto el error puede ser muy costoso y consume tiempo.
4. Agrupamiento de Defectos
Los estudios sugieren que los problemas en un elemento de software tienden a agruparse en torno a un conjunto limitado de módulos o áreas. Una vez que estas áreas han sido identificadas, los administradores eficientes de prueba son capaces de enfocar las pruebas en las zonas sensibles, mientras que siguen buscando a los errores en los módulos de software restantes. Me recuerda al 80/20.
5. La paradoja del "Pesticida"
Al igual que el sobre uso de un pesticida, un conjunto de pruebas que se utilizan repetidamente en el disminuirá en su eficacia. Usando una variedad de pruebas y técnicas expondrá una serie de defectos a través de las diferentes áreas del producto.
6. La prueba es dependiente del contexto
Las mismas pruebas no se deben aplicar en todos los ámbitos. Distintos productos de software tienen diferentes requisitos, funciones y propósitos. Una prueba diseñada para realizarse en un sitio web, por ejemplo, puede ser menos eficaz cuando se aplica a una aplicación de intranet. Una prueba diseñada para una forma de pago con tarjeta de crédito puede ser innecesariamente rigurosa si se realiza en un foro de discusión.
En general, cuanto mayor es la probabilidad y el impacto de los daños causados por el software fallado, mayor es la inversión en la realización de pruebas de software.
7. La falacia de ausencia de errores
Declarar que una prueba no ha descubierto ningún error no es lo mismo que declarar que el software es “libre de errores”. Con el fin de garantizar que los procedimientos adecuados de software de prueba se lleva a cabo en todas las situaciones, los evaluadores deben asumir que todo el software contiene algunos (aunque disimulada) errores.
jueves, 18 de septiembre de 2014
10 razones para arreglar defectos tan pronto como se encuentran
Hace tiempo encontre una interesante infografia.
Concuerdo con las 10 razones listadas y tal vez se puedan agregar más, pero me parece bien para un listado de 10 razones.
Saludos!!
Fuente
Concuerdo con las 10 razones listadas y tal vez se puedan agregar más, pero me parece bien para un listado de 10 razones.
- Defectos no arreglados camuflagean otros defectos.
- Defectos no arreglados hacen pensar que la calidad no es importante.
- Discutir defectos no arreglados es una perdida de tiempo.
- Defectos no arreglados llevan a duplicar esfuerzo.
- Defectos no arreglados llevan a metricas no confiables.
- Defectos no arreglados distraen a todo el equipo.
- Defectos no arreglados provocan parches inmediatamente después de liberar.
- Defectos no arreglados llevan a estimaciones poco acertadas.
- Arreglar codigo con el que se esta familiarizado es más fácil que aquel ya olvidado (Que se trabajo hace mucho tiempo).
- Arreglar un defecto HOY cuesta menos que MAÑANA.
Saludos!!
Fuente
miércoles, 17 de septiembre de 2014
Bienvenida
Por la web encuentro muchos blogs de Software Testing, la mayoria en Ingles, asi que tratare de ir coleccionando informacion de preferencia en español dentro de este blog. Se que el idioma no es un problema en la industria pero no esta demás encontrarse con material en el idioma :)
Espero que sea de ayuda!
Espero que sea de ayuda!
Suscribirse a:
Entradas (Atom)