+54 911 66509220

Noticias

Noticias
12 Ene 2018

Argentesting 2da Edición – Lo que aprendí de Rapid Software Testing con Michael Bolton

/
Creado por
/
Comentarios0

Argentesting 2da Edición – Lo que aprendí de Rapid Software Testing con Michael Bolton. Charla ofrecida por Gonzalo Mancebo el 23 de Octubre del 2017, primer día de las jornadas organizadas en la UTN Sede Medrano, Buenos Aires, Argentina.

Como testers tenemos ciertos conceptos fuertemente incorporados sobre qué significa ser un tester, qué tareas deben desempeñarse y cómo hacerlas.
Resulta fácil entonces que nos formemos una imagen de cómo debe ser un tester. Pero qué sucedería si alguien nos dijera que existe una alternativa a lo que conocemos, toda una nueva metodología a nuestro alcance que trae consigo nuevos conceptos. Les proponemos vaciar el vaso y compartirles una perspectiva personal sobre qué me sucedió cuando el Rapid Software Testing se presentó como una nueva metodología disponible, cargada de nuevos y disruptivos conceptos.

Por Gonzalo Mancebo.

Consultor Senior y Coordinador en Testing y SQA para proyectos de misión crítica de mediano y gran porte de GeneXus Consulting. Especializado en gestión de equipos de testing, estrategias de prueba y automatización aplicada al testing. Docente de Testing en distintas Fundaciones en Uruguay. Estudiante avanzado de Licenciatura en Sistemas de la Universidad ORT Uruguay. ISTQB Certified Tester, Analista GeneXus y GXtest.

Argentesting

Argentesting – Contenido de la Presentación

¿Qué es el Rapid Software Testing?

Argentesting

Como una metodología de testing, el RST cubre los siguientes aspectos:

Conjunto de habilidades (mayoritariamente tácitas).
Conjunto de heurísticas.
Llevar adelante el proceso de testing y lograr su objetivo.
Habilidad de contar la historia.

 

Considera los siguientes puntos:

Nuevo concepto de testing.
Modelos, Cobertura, Oráculos…
Cómo hacer mi trabajo visible.

 

Contexto

1. Leer las especificaciones
2. Identificar los items específicos a ser chequeados
3. Preparar los casos de prueba
4. Ejecutar los casos de prueba

 

Verdadero Contexto

1. Leer las especificaciones
2. Este … ¡No hay especificaciones!
3. ¡Oh! No, si acá está, a ver…
4. ¡Nooo! Esto es viejo y no se entiende..
5. Ya sé, mejor le pregunto a alguien…
6. Nadie tiene idea de cómo debería funcionar.
7. ¿Qué hago, no tengo nada para testear?

 

Nuevo concepto de Testing

El testing es…
Evaluar un producto aprendiendo de él a través de la exploración y la experimentación.

Nuevo concepto de Testing
Los testers no son QA
Nosotros debemos brindar información sobre el estado de un producto y los riesgos asociados para que los interesados tomen decisiones informadas.

Problema: Cualquier cosa sobre el producto que amenace su valor.

Calidad: Es el valor del producto para alguna persona que importe.

Tester y QA son distintos roles.

 

Testing no es sobre Casos de Prueba

Observar:
Operar el producto para observar su comportamiento

Evaluar:
Ejecutar pruebas
Evaluar resultados

Reportar:
Reportar las fallas
Checking!
Forma parte del testing pero no es testing

 

Modelos
La importancia de los modelos

Un modelo es una idea, actividad u objeto
Ideas en la mente, personas, demostraciones o programas

Que representa otro idea, actividad u objeto
Como algo complejo que necesito estudiar

Un buen modelo es aquel que ayuda a entender o manipular aquello que representa

 

Preguntas guiadas por riesgo

¿Cómo probaría y cuántas pruebas?
El sistema debe operar en el rango de -25 a 50 grados

¿Qué es el sistema?
¿Qué pasa con el sistema operando fuera de ese rango?
¿A qué tipo de grados se refiere?
¿Porqué opera a ese rango y no en otro?

Testing es sobre hacer las preguntas correctas, en base a riesgos para encontrar y comunicar problemas.

 

1. Modelar la realidad a probar.
2. Determinar la cobertura.
3. Determinar oráculos.
4. Determinar procedimientos.
5. Configurar, Operar y Observar el sistema.
6. Evaluar resultados.
7. Aplicar heurística de finalización de actividades.
8. Reportar resultados.

 

Cobertura
Que tan profundamente examinamos el producto con respecto a sus modelos.

En RST una forma de modelas la cobertura es a través de los Elementos del producto.

1. Estructura.
2. Función.
3. Data.
4. Interfaces.
5. Plataforma.
6. Operaciones.
7. Tiempo.

 

Modeos + Cobertura
Uso de Mapas Mentales

 

Oráculos
Los oráculos no son perfectos y los testers no somos jueces.
No es necesario decidir a ciencia cierta si algo es un bug, sino que debemos asegurarnos de encontrar una razón justificada de que puede existir una amenaza al valor del producto para alguien que importa.
Por eso es importante encontrar buenos oráculos que permitan brindar credibilidad.

 

Testing en tres historias.

Una historia sobre el estado del producto
Sobre qué hace, cómo falla y cómo puede fallar de forma que importe al cliente.

Una historia sobre cómo lo testeamos.
Cómo lo operamos y lo observamos.
Cómo reconocimos problemas.
Qué se ha probado y qué no se ha probado todavía.

Una historia sobre qué tan bueno fue el producto.
El riesgo de testear o no testear.
Qué hizo el testing más rápido o lento.
Cuán testeable el producto es.
Qué necesitas o recomiendas.

Conclusión
Cada proyecto ocurre bajo condiciones de incertidumbre y presión de tiempo.

 

 

 

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

* Copy This Password *

* Type Or Paste Password Here *

17.002 Spam Comments Blocked so far by Spam Free Wordpress

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>