Expositores: Paula Reyes y William Llanes Duración: 2 horas Resumen: Los puntos más resaltantes del taller serán: 1- El aporte de los equipos multidisciplinarios 2- La necesidad de complementación de perfiles 3- Evaluación y dimensionamiento de riesgos para la toma de decisiones 4- Cobit 5- Priorización de pruebas (como priorizar las pruebas en la liberación de una versión, cuando no se cuenta con mucho tiempo o próximos a la salida en producción)

1. TESTING DESDE UNA
PERSPECTIVA DE
NEGOCIOS Y RIESGOS
Paula Reyes
preyes@cpaferrere.com
@ReyesPauV
21 y 22 de mayo, 2018
www.testinguy.org
#testinguy |@testinguy
William Llanes
wllanes@cpaferrere.com
@llanesw

2. ACERCA DE:

3. ENFOQUE DE TESTING
El Testing brinda un servicio a un proyecto, tiene una Misión, ya sea en un proyecto de
investigación, adquisición, desarrollo, implementación, implantación, migración y/o
integración de software.
A su vez, estos proyectos pueden estar inmersos en el negocio financiero, en el sector
salud, sector público, comercial, entre otros, cada uno con sus elementos y
características distintivas.
Y por supuesto, nuestro día a día en el mundo del Testing se encuentra cargado de
nuevos desafíos y riesgos los cuales no podemos ignorar.
Estrategias de Testing completamente diferentes podrían ser
apropiadas para diferentes combinaciones de estos puntos

4. ENFOQUE DE TESTING
Es totalmente apropiado que en diferentes proyectos los equipos de
Testing puedan tener diferentes misiones.
Determinada “práctica” de Testing que es central al servicio de una misión,
puede ser irrelevante o contraproducente al servicio de otra.
“Caso Marshall”

5. ENFOQUE DE TESTING
El Testing funcional SIEMPRE busca validar el comportamiento de un
sistema de acuerdo a un determinado resultado esperado.
Dicho resultado esperado NO se define a partir del criterio del tester sino
que sigue los lineamientos del … (Negocio)
Las técnicas tradicionales de generación de casos permiten optimizar el
cubrimiento de las pruebas (eficiencia) pero NO no dan certezas sobre la
utilidad de las mismas (eficacia).

6. ENFOQUE DE TESTING
Un Ejemplo: aplicación que determina el tipo de triángulo (escaleno,
isósceles, equilátero) según la longitud de sus lados.
Entrada: tres números enteros
Salida: tipo de triángulo

7. ENFOQUE DE TESTING
Posibles casos de prueba según diferentes técnicas tradicionales:
● Clases de equivalencias:
○ Posibles entradas: valores iguales, valores diferentes, valores inválidos
○ Posibles salidas: escaleno, isósceles, equilátero, Error
● Valores borde:
○ 0, 1, MAX_LADO

8. ENFOQUE DE TESTING
CASO 1:
● Entradas: 0 - 3 - 4
● Salida esperada: ERROR (lado inválido)
CASO 2:
● Entradas: 2 - 0 - 3
● Salida esperada: ERROR (lado inválido)
CASO 3:
● Entradas: 3 - 3 - 0
● Salida esperada: ERROR (lado inválido)
CASO 4:
● Entradas: 0 - 0 - 0
● Salida esperada: ERROR (lado inválido)

9. ENFOQUE DE TESTING
CASO 5:
● Entradas: 2 - 3 - 4
● Salida esperada: ESCALENO
CASO 6:
● Entradas: 3 - 3 - 3
● Salida esperada: EQUILÁTERO
CASO 7:
● Entradas: 2 - 2 - 5
● Salida esperada: ERROR (lado inválido)
MORALEJA: Técnicas de generación de casos permiten optimizar el
cubrimiento pero NO dan certezas sobre utilidad de los mismos.
El conocimiento del NEGOCIO permite guiar el objetivos de las pruebas
priorizando aquellos aspectos de mayor RIESGO.

10. ALCANCE DE ESTE TALLER
Solo a través del juicio y la habilidad, ejercidos de
forma cooperativa a lo largo de todo el proyecto,
podemos hacer las cosas correctas en los
momentos adecuados para probar los productos de
nuestros clientes de manera efectiva.
Testing
Negocio Riesgo

11. ALCANCE DE ESTE TALLER
Testing
Negocio Riesgo
Una gran porcentaje de todo el trabajo que se realiza en
un proyecto de Testing tiene que ver con la mitigación
de Riesgos (incluso cuando no se tiene un enfoque de
Riesgos de forma consciente).
Entonces ¿Por qué no realizar nuestro propio análisis de
riesgos en cada proyecto?
¿Cómo la existencia de estos riesgos y las características
del negocio influyen en nuestras estrategias de pruebas?
¿Cómo la conformación de los equipos, los
procedimientos, herramientas y el arte de priorizar
pueden optimizar la mitigación de riesgos?
Estas cuestiones no solo terminan siendo determinantes en la calidad
del servicio que brindamos, sino en la calidad del software bajo prueba

12. PROPUESTA
Entender mejor estas 2
dimensiones, analizarlas,
estudiarlas, comprenderlas
Prepararnos de la mejor
manera para servir al
proyecto
Valor de cada prueba: el valor esencial de cualquier caso de prueba radica en su capacidad para
proporcionar información (es decir, para reducir la incertidumbre).
Evolución de las pruebas: los diferentes tipos de pruebas revelarán diferentes tipos de defectos:
las pruebas deben ser más difíciles o deben enfocarse en diferentes riesgos a medida que el
programa se vuelve más estable.

13. DISCLAIMER
El objetivo de las pruebas basadas en el riesgo no puede ser en la práctica:
un proyecto sin riesgos.
Lo que sí podemos obtener de las pruebas basadas en riesgos es llevar a cabo las pruebas con las
mejores prácticas en gestión de riesgos para lograr un resultado del proyecto que logre…
equilibrar los riesgos con la calidad, las características, el presupuesto y el cronograma.

14. DISCLAIMER
Alcance Tiempo Costo
Tiempo Costo
Alcance
Enfoque tradicional
Alcance fijo
Enfoque ágil
Alcance variable

15. RIESGO Y TESTING
Es la posibilidad de un resultado negativo o indeseable. Un riesgo es algo que aún no ha
ocurrido y puede que nunca ocurra; Es un problema potencial
En el futuro, un riesgo tiene alguna probabilidad entre 0% y 100%. Es una posibilidad, no una
certeza
Se debe considerar tanto la probabilidad de ocurrencia como su posible impacto
En Testing de software son aquellos posibles inconvenientes que podrían poner en peligro los
objetivos de las partes interesadas del proyecto en primer lugar y los posibles inconvenientes
que podrían poner en peligro el cumplimiento de los objetivos de Testing
Asociados al
Producto
(Software)
Asociados al
Proyecto

16. RIESGO Y TESTING
Asociados al
Producto
(Software)
Es la posibilidad de que el sistema pueda fallar en
satisfacer alguna necesidad o expectativa razonable del
cliente, los usuarios o stakeholders
• Si el software omite alguna función clave que se especificó o que el cliente esta
esperando obtener
• Si el software no es confiable y falla con frecuencia
• Si el software falla de manera que cause daños financieros o de otro tipo a un usuario
y/o la empresa para la que trabaja el usuario
• Si el sistema tiene inconvenientes no-funcionales, como puede ser seguridad,
confiabilidad, usabilidad, mantenibilidad, rendimiento, etc.
• Otros

17. RIESGO Y TESTING
Involucra la Planificación general del proyecto, la
incidencia de factores externos y otros equipos
• Atraso o problemas con la configuración de ambiente e impacto de releases
• Atraso o problemas con las tareas de desarrollo
• Atraso o problemas con las tareas de Testing
• Atraso en la corrección de errores
• No tener soporte en el seteo del sistema o la configuración de ambientes
• Otros
Asociados al
Proyecto

18. RIESGO Y TESTING
Centrémonos en Riesgos
asociados al Producto …
Asociados al
Proyecto
Asociados al
Producto
(Software)

19. FOCO EN RIESGOS
IDENTIFICACIÓN
Colección de Riesgos: Nuestra lista comienza con el primer
proyecto en el cual comenzamos el análisis, se nutre durante la
ejecución del mismo y las lecciones aprendidas y es la base para
nuestro siguiente proyecto, donde el ciclo se vuelve a repetir
ListadeRiesgos
Proyectos

20. FOCO EN RIESGOS Y EL NEGOCIO
EVALUACIÓN
De mi Colección de Riesgos:
¿qué es realmente importante para el negocio de mi cliente?
¿Qué probabilidad de ocurrencia tiene en este contexto?
¿Cuál sería el impacto si se materializa?
Probabilidad
Impacto
No los tendré en
cuenta para este
proyecto (o al menos
momentáneamente)
Me concentro en estos
riesgos, que parecen
más críticos para el
negocio de mi cliente

21. RIESGO, NEGOCIO Y TESTING
RESPUESTA
¿Qué podemos hacer desde nuestra posición de testers? ¿Cuál será
nuestra Misión?
• Prevención
Eliminar la amenaza eliminando la causa que puede provocarla
• Mitigación
Reducir la probabilidad o las consecuencias de sucesos adversos a un límite
aceptable antes del momento de activación. Es importante que los costos de
mitigación sean inferiores a la probabilidad del riesgo y sus consecuencias.
• Transferencia
Trasladar las consecuencias de un riesgo a una tercera parte junto con la
responsabilidad de la respuesta
• Aceptación
No requiere de ninguna acción, dejándose en manos del equipo de proyecto la
gestión del riesgo si este llegara a materializarse.

22. RIESGO, NEGOCIO Y TESTING
Un ejercicio para medir el umbral de tolerancia al riesgo….

23. RIESGO, NEGOCIO Y TESTING
Otra formas de gestionar los Riesgos tomando en cuenta el Product Backlog….
Tomar cada una de las
funcionalidades
evaluando el Riesgo
asociado en cada caso
RIESGOS
IMPORTANCIA
Entonces, visto este
escenario…
¿Cómo voy a priorizar
las funcionalidades a
probar y Riesgos a
minimizar?
Tomar primero las
funcionalidades de
mayor riesgo en
primera instancia.
Riesgo Alto
Baja Importancia
Riesgo Alto
Importancia alta
Riesgo Bajo
Baja Importancia Riesgo Bajo
Alta Importancia

24. RIESGO, NEGOCIO Y TESTING
ESTRATEGIA
• Prevención
• Mitigación
• Transferencia
• Aceptación
• Respecto a este Riesgo no puedo hacer nada por el momento
• El componente técnico de mi equipo debe ser mayor que el funcional
• El componente funcional de mi equipo debe ser mayor que el técnico
• Tomando una estrategia analítica, basada en modelos o siguiendo la
metodología de mi empresa puedo prevenir este riesgo
• Necesitamos que los usuarios realicen estas validaciones (transferencia)
• Debo basarme en regresiones y automatizar las pruebas para estas
funcionalidades
• Me tengo que basar en estos estándares o adoptar estas prácticas dado
que funcionarán mejor en estas circunstancias

25. ¿PREGUNTAS?
¡MUCHAS GRACIAS!
21 y 22 de mayo, 2018
www.testinguy.org
#testinguy |@testinguy
Paula Reyes
preyes@cpaferrere.com
@ReyesPauV
William Llanes
wllanes@cpaferrere.com
@llanesw
Matías González
ngonzalez@cpaferrere.com
Marcos Liebstreich
mliebstreich@cpaferrere.com