Documento en español. La presentación "Metodologías de Testing Manual" está orientada a introducir a los pasantes al testing manual, la forma de pensar de un tester, la historia y referentes del testing de software, los distintos tipos de tests más comúnes usados en desarrollo de software y el enfoque del modelo heurístico de pruebas. Completo con anexo Bibliografíco y video introductorio.

1. Testing:
Metodologías,
Standards y
Referentes

2. Lo que vamos a ver en esta presentación:
› Video introductorio “Steve McQueen: Consulting Software Tester”
› Brevísima Historia del Testing
› Standards de calidad: Familia del ISO 25000
› Referentes del testing
› Metodologías de testing: Términos generales de Tipos de pruebas
COFFEE BREAK
› Metodologías de testing: ¿Qué es la heurística?
› Metodologías de testing: Técnicas generales de prueba
› Demostración de casos de pruebas standard
› Severidad de los bugs
› Cómo reportar un bug en JIRA
› Anexo Bibliográfico

3. HOLA!
Soy Giselle Llamas.
Estoy acá porque me encanta el testing, la creatividad
y las nuevas tecnologías.
Podés encontrarme en Twitter como @itsShimo
Y en Linkedin como:
https://www.linkedin.com/in/gisellellamas/

4. Video presentación.
Steve McQueen, “Consulting Software
Tester” por James Bach (traducción al
español por Giselle Llamas y edición por
Martín Ojeda).
https://goo.gl/k1VMNg

5. Brevísima Historia del Testing:
La separación del debugging y del testing fue marcada en 1957 por el
pionero de la computación Charles L. Baker, distinguiendo los mismos en
su review del libro "Digital Computer Programming" de Dan
McCracken. Esta review fue publicada en el diario/serial "Mathematical
Tables and Other Aids to Computation" que era publicada en su
momento por la American Mathematical Society.

6. La progresión Histórica del Testing
› Hasta 1956 – Orientado al debugging del código fuente: cuando
testing no tenía una clara diferencia con el proceso de debugging.
› 1957–1978 – Orientado a la Demostración: en este período se
demostraba que el software satisfacía esencialmente los
requerimientos.
› 1979–1982 – Orientado a la Destrucción de los sistemas: cuando el
testing estaba orientado a encontrar errores en el código o en la
ejecución misma del programa.
› 1983–1987 – Orientado a la Evaluación del Software: en este
período la intención de las prácticas de testing se amplía para que,
durante el ciclo de vida del software el mismo se aplica para
evaluar y medir su calidad.
› 1988–2000 – Orientado a la Prevención de Bugs: desde el
comienzo de este período se ve al testing como una actividad
orientada también a la prevención, las pruebas no sólo sirven para
demostrar que el software satisface a su especificación, sino que
también se detectan fallas en el diseño o ejecución, y se previenen.

7. Familia del
ISO 2500
ISO de Calidad de productos de Software.
http://iso25000.com/index.php/en/iso-25000-standards
La serie de standards ISO/IEC 2500, tambièn conocidas como SQuaRE (System
and Software Quality Requirements and Evaluation) apuntan a crear un
framework para la evaluación de la calidad de productos de software. La series
de standards ISO/IEC 25000 consiste de cinco divisiones:

9. Vamos a ver un poco más de cerca lo que se refiere al modelo de calidad de producto:

10. >Referentes del
>TESTING

11. Cem Kaner Cem Kaner es un profesor de la carrera de Ingeniería de Software en el
Instituto de Tecnología de Florida, y el director del Centro de Educación e
Investigación en Software Testing de Florida Tech (CSTER) desde el 2004.
Fuera de este ámbito acadèmico es mejor conocido por ser un defensor de
la usabilidad de software y el testing de software.
Previo a su profesorado, Kaner trabajó en la industria del software
empezando en 1983 en Silicon Valley como "un tester, programador, escritor
acerca de tecnología, manager de desarrollo de software, director de
desarrollo de producto y un consultor independiente de desarrollo de
software". En 1988, él y sus coautores Jack Falk y Hung Quoc Nguyen
publicaron lo que se convirtió (en ese momento), el libro best-seller en
software testing, simplemente titulado "Testing Computer Software".
Kaner recibió un Bachiller de la universidad de Brock en 1974 especializado
en matemáticas y filosofìa. Siguió su carrera al conseguir un doctorado en
Psicología experimental de la Universidad McMaster (las dos universidades
de Ontario, Canadá) en 1984, con una disertación en el área de la Psicofìsica
(una rama de la psicología que estudia la relación entre los estímulos y las
sensaciones y percepciones que estos producen). Luego se recibió con un
grado terciario de la división de derecho de la Golden Gate University (San
Francisco) en 1994, con un interés primario en la leyes que afectan el área de
calidad de software.
En el 2004 co-fundó la asociación sin fines de lucro "Association for
Software Testing".
https://www.associationforsoftwaretesting.org/

12. James Bach Empezó en el negocio de desarrollo de software como un programador, pero se encontró que
los problemas relacionados con la mejora y el análisis del software le resultaban mucho más
interesantes que los de producción del mismo. Se dedica a la calidad de software desde 1987 y
la mayoría de su experiencia se basa en trabajar con compañías de Silicon Valley como ser
Apple Computer y Borland, por lo que las técnicas que ha construido a través de su carrera son
diseñadas para usarlas bajo condiciones de horarios comprimidos, alta incidencia de cambio,
tecnología basada en componentes y especificaciones pobres.
Es el miembro fundador de la "Context-Driven School of Software Testing", un enfoque de
testing particular que prioriza la parte humana, el enfoque analítico basado en el contexto y la
flexibilidad ante la no-predictibilidad de los proyectos de software.
Es el creador de la metodología "Rapid Software Testing", y uno de los progenitores del testing
exploratorio y calificado de software.
Debido a su extensa experiencia en calidad de software, fue uno de los testigos principales en
el caso legal dado entre los años 2000-2001, entre el gobierno de los Estados Unidos y la
Microsoft Corporation. Se planteaba que juntar Internet Explorer en un mismo paquete del
Sistema Operativo Windows fue la principal razón del éxito de Microsoft en la guerra de los
navegadores (Browser War) en los fines de la década de 1990, donde competía contra Netscape
Navigator, ya que cada usuario de Windows contaba con una copia del Internet Explorer.
En el trasfondo de este caso se encontraban temas tales como si Microsoft había alterado o
manipulado sus application programming interfaces (APIs) para favorecer al Internet Explorer
por sobre navegadores de otros fabricantes, la conducta de Microsoft al establecer acuerdos de
licencias restrictivos con los manufacturadores de equipos originales (OEMs), y las intenciones
que perseguían las conductas de Microsoft.

13. >Metodologías de
>TESTING

14. Metodologías de testing:
Términos generales de Tipos de pruebas
Unit Testing (Testing unitario)
El testing unitario es el testing de una unidad individual o un grupo de
unidades relacionadas. Es generalmente hecho por el programador
para probar que esa unidad que el/ella ha implementado está
produciendo el output esperado contra un input en particular.
Integration Testing (Testing de integración)
El testing de integración es testing hecho en un grupo de
componentes que se combinan para producir un output. También la
interacción entre software y hardware es testeada en el testing de
integración si los componentes de software y hardware tienen alguna
relación entre sí.

15. System Testing (Testing de sistema/compatibilidad)
El testing de sistema es testing creado para asegurarse de que poniendo el
software en distintos ambientes (por ejemplo, sistemas operativos), este
todavía funciona. El testing de sistema es hecho con la completa
implementación del sistema operativo y su ambiente complementario
(especificaciones, memoria, etc.).
Stress Testing
El stress testing se define como una serie de pruebas creadas para evaluar la
respuesta del sistema debajo de condiciones desfavorables, o sea conducido
fuera de los límites de las especificaciones.
Performance Testing
Performance testing es el testing creado para verificar la velocidad y
efectividad de la aplicación y para asegurarse de que está generando
resultados dentro de un tiempo específico que se adapta a los requerimientos
de la performance del mismo.
⌨
⌫
⏎

16. Functional Testing (Testing Funcional)
El testing funcional es una actividad de verificación que se asegura que el software
es funcional dentro de los límites de cómo se ha resuelto la problemática a mano.
Cuando se hace este tipo de testing se usa cualquier ambiente de prueba que se
pueda encontrar en ese momento, no tiene que necesariamente ser del tipo que se
va a usar en producción, mientras sea usable para las pruebas actuales que se
ejecutarán en el mismo. Por ende, el testing funcional verifica que el producto
funciona como estima el developer que funciona la solución implementada en el
mismo.
Acceptance Testing (Testing de aceptaciòn)
Esta es una actividad de validación, los tests de aceptación verifican que el
producto efectivamente funciona como una solución al problema que le han indicado
en los requerimientos, inclusive si los supera con creces o es inferior a los
requerimientos solicitados. Esto puede ser hecho codo a codo con el usuario, cliente
o Product Owner, por ejemplo, haciendo con el programa las tareas que estaba
diseñado para hacer, por lo que se usan pruebas que cubren los escenarios típicos
dentro de los cuales esperamos que se use el software, y debe ser corrido en un
ambiente lo más parecido a producción posible, y en un hardware que sea lo más
parecido a lo que el cliente va a usar.
🔖
⎂
⎃
⏎

17. Usability Testing (Testing de Usabilidad)
El testing de usabilidad se ejecuta desde de la perspectiva del cliente, para evaluar
cuán user-friendly es la GUI (Graphic User Interface), cuán rápido puede aprender el
cliente a usarla, luego de usarla, cuán bien puede manejar la misma, cuán agradable
es el diseño de la misma, etc. Estas pruebas forman parte de la muy importante
parte del testing que se dedica a lo relacionado con la experiencia de usuario.
Regression Testing (Testing de regresión)
Se denominan pruebas de regresión a cualquier tipo de pruebas de software que
intentan descubrir errores o divergencias funcionales con respecto al
comportamiento esperado del software, causados por un cambio en el código.
Se evalúa el correcto funcionamiento del software desarrollado frente a evoluciones
o cambios funcionales. El propósito de estas pruebas es asegurar que los casos de
prueba que ya habían sido probados y fueron exitosos permanezcan así.
🔏
🔃
⎘
⎗

18. Mi sugerencia es que no nos quedemos con esto y veamos también cómo se
puede utilizar el método heurístico propuesto por James Bach en las pruebas
que diseñamos, para tener una base sobre la cual siempre utilizar nuestro propio
criterio. Pero para empezar, qué es la Heurística?
Se denomina heurística a la capacidad de un sistema para
realizar de forma inmediata innovaciones positivas para sus
fines. La capacidad heurística es un rasgo característico de los
humanos, desde cuyo punto de vista puede describirse como
el arte y la ciencia del descubrimiento y de la invención o de
resolver problemas mediante la creatividad y el pensamiento
lateral o pensamiento divergente.
>Hacia un modelo de pruebas
>HEURÍSTICO

20. >Hacia un modelo de pruebas
>HEURÌSTICO
Resolver con criterio:
La popularización del concepto heurístico se debe al matemático George Pólya, con su libro
“Cómo resolverlo” (How to solve it). Habiendo estudiado tantas pruebas matemáticas desde su
juventud, quería saber cómo los matemáticos llegan a ellas. El libro contiene la clase de recetas
heurísticas que trataba de enseñar a sus alumnos de matemáticas. Cuatro ejemplos extraídos
de él ilustran el concepto mejor que ninguna definición:
* Si no conseguís entender un problema, dibujá un esquema del mismo.
* Si no encontrás la solución, hacé como si ya la tuvieras para poder ver qué se puede deducir
de ella (razonando a la inversa).
* Si el problema es abstracto, probá examinando un ejemplo concreto.
* Intentá abordar primero un problema más general (es la “paradoja del inventor”: la meta más
ambiciosa es la que tiene más posibilidades de éxito).

21. >Técnicas generales de
PRUEBA
Una técnica de prueba es un enfoque heurístico para crear pruebas.
Hay muchas pruebas interesantes, pero esta presentación incluye
nueve de ellas.
Por "técnicas generales", se entiende que la técnica es simple y
suficientemente universal como para aplicarla a una variedad amplia
de contextos. Muchas técnicas específicas son basadas en una o más
de estas nueve, y una variedad sin fin de técnicas específicas de
pruebas pueden ser construidas combinando una o más de estas
técnicas con ideas de cobertura dentro de las otras listas que
pertenecen al enfoque heurístico (más detalles en la sección de
Bibliografía).

22. TEST DE FUNCIONES
Probar qué puede hacer el programa.
Place your screenshot here
❖ Identificar cosas que el producto
puede hacer (funciones y sub-
funciones).
❖ Determinar cómo sabrías si una
función fuese capaz de funcionar.
❖ Probar cada una de las funciones,
una a la vez.
❖ Ver que cada función hace lo que
se supone que haga y no lo que no
se supone que haga.

23. TEST DE DOMINIO
Divide y conquistarás los datos.
Place your screenshot here
❖ Buscar cualquier dato procesado por el
producto, buscar outputs además de
inputs.
❖ Decidir cuáles datos en particular se van
a usar para probar el producto.
Considerar cosas como valores lìmite,
típicos valores, valores convenientes,
valores inválidos, o los que mejor
representan esa clase de valores que
usa el programa de base.
❖ Considerar combinaciones de datos que
vale la pena testear juntas.

24. TEST DE STRESS
Sobrecargá el producto.
Place your screenshot here
❖ Buscá los subsistemas y las funciones que son
vulnerables a ser sobrecargadas o a "romperse" en
la presencia de datos complicados o recursos
recortados en el día a día del programa (memoria,
etc.).
❖ Identificá datos y recursos relacionados a esos
subsistemas y funciones.
❖ Seleccioná o generá datos complejos o condiciones
que recortarán los recursos que tiene el programa a
mano, como por ejemplo, datos extremadamente
largos, estructuras de datos complejos, cargas altas,
pruebas corridas en un período de tiempo largo,
muchos casos de prueba y bajas condiciones de
memoria disponible.

25. Place your screenshot
here
TEST DE FLUJO
Hacé una cosa después de la otra.
❖ Conducí una prueba que haga múltiples actividades
que se conectan de principio a fin, por ejemplo hacer
un tour a través de todo el diagrama de flujo de la
aplicación haciendo actividades como usuario que
afecten a todas las áreas del programa,
continuamente.
❖ No resetees el sistema entre estas acciones.
❖ Variá el tiempo y la secuencia, y probá threads
paralelas si el programa lo permite.

26. Place your screenshot
here
TEST DE ESCENARIO
Probar para contar una historia atrapante.
❖ Comenzá por pensar acerca de todo lo que sucede
alrededor del producto (programa).
❖ Diseñá pruebas que involucran interacciones
significativas y complejas con el mismo.
❖ Un buen escenario de prueba es una historia
interesante acerca de cómo alguien importante
dentro de la organización que requirió el producto
podría hacer algo significativo con el mismo.

27. Place your screenshot here
TEST DE PRETENSIONES
Creá un reto a todo lo que afirma
hacer el programa.
❖ Identificá materiales promocionales, comerciales, de
referencia que incluyen afirmaciones acerca del
producto (implícitas o explícitas). Considerá los
acuerdos de nivel de servicio (SLA, service level
agreements), licencias de usuario final (EULA, end user
level agreements), que muchas veces son tomados
como acuerdos legales entre el cliente/usuario y el
proveedor del software, junto con las promociones
comerciales del producto, las especificaciones, el texto
de ayuda, los manuales, etc.
❖ Analizá cada una de las afirmaciones individualmente
hechas acerca del producto.
❖ Si estás probando desde una especificación explícita,
esperá que ésta y el producto estén alineados entre sí.

28. Place your screenshot here
TEST DE USUARIO
Involucrá a los usuarios
❖ Identificá a las categorías y roles de usuarios.
❖ Determiná qué es lo que cada categoría de usuario va
a hacer (desde los casos de uso), cómo lo va a hacer, y
qué es lo que cada uno valora.
❖ Conseguí datos reales de los usuarios, en lo posible, o
traelos a los mismos para crear pruebas.
❖ Si eso no es posible, simulá sistemáticamente ser uno
de esos usuario (cuidado- es fácil pensar que estás
pensando/actuando como un usuario estándar cuando
no lo sos).
❖ Los tests de usuario poderosos son los que involucran
una variedad de usuarios y roles de usuarios, no sólo
uno.

29. Place your screenshot here
TEST DE RIESGO
Imaginá un problema, luego buscá
repercusiones del mismo.
❖ ¿Qué tipos de problemas podrìa tener el producto?
❖ ¿Qué tipos de problemas importan más? Concentrate
en esos.
❖ ¿Cómo los detectarían si estos estuviesen allì?
❖ Hacé una lista de problemas interesantes y pruebas
diseñadas específicamente para revelarlos.
❖ Podría servir consultar a los expertos, a la
documentación de diseño si esta existe, viejos reportes
de bugs, o aplicar heurísticas de riesgo.

30. CHEQUEOS AUTOMÁTICOS
Verificá un millón de ocurrencias .
❖ Buscá o creá herramientas de desarrollo que puedan ejecutar muchas de acciones
y verificar una variedad de cosas pertinentes al programa.
❖ Considerá herramientas que automatizan parcialmente la cobertura del plan de
pruebas.
❖ Considerá herramientas que automatizan parcialmente oráculos (un oráculo en
software testing es un mecanismo para determinar si un test ha fallado o pasado
basado en inputs y outputs de la parte bajo prueba del programa dentro de un caso
de prueba).
❖ Considerá el uso de programas que detectan automáticamente cambios (Ej.
herramientas de comparación de texto online).
❖ Considerá el uso de generadores de datos de prueba automáticos.
❖ Considerá herramientas que consigan que la ejecuciòn de pruebas de parte del
elemento humano sean más poderosas.

31. Severidad de los bugs:
Bloqueante
Problema grave de seguridad o que afecta a una funcionalidad primordial del programa para el
cual no hay una solución alternativa. Impide el uso o la prueba del mismo.
Alto
Un defecto que afecta a un funcionalidad primordial, para el cual existe una solución alternativa.
El uso o la prueba del sistema puede continuar de modo degradado o accediendo a la misma a
través de otra ruta que no es la principal.
Medio
Un defecto que afecta una funcionalidad no-primordial para el cual no hay solución alternativa.
La característica no puede ser utilizada.
Bajo
Una defecto que afecta un requisito no-primordial para el cual existe una solución alternativa
para mantener la usabilidad.
Cosmético
La información se muestra, pero el aspecto es incorrecto, por ejemplo errores gramaticales o de
ortografía, fuente incorrecta, glitches visuales, mal alineamiento de elementos, etc.

32. Bibliografìa (en inglés):
-Glosario completo de tèrminos, documento del ISTQB
http://www.istqb.org/downloads/send/20-istqb-glossary/186-glossary-all-terms.html
-Standards ISO 25000
http://iso25000.com/index.php/en/iso-25000-standards
-Referencia Històrica:
http://www.testingreferences.com/testinghistory.php
-"The Growth of Software Testing" - Gelperin D.; B. Hetzel (1988) - ISSN 0001-0782.
Extracto de la gaceta "Communications of the ACM" (Association for Computer
Machinery).
-Mathematical Tables and Other Aids to Computation
https://www.jstor.org/journal/mathtablotheaids
-Charles L. Baker - http://history.computer.org/pioneers/baker.html
-Caso legal de los Estados Unidos Vs. Microsoft Corporation
https://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp
-Browser Wars - Contexto de la Guerra de los Navegadores
http://en.wikipedia.org/wiki/Browser_wars
-Heuristic Test Strategy Model - http://www.satisfice.com/tools/htsm.pdf
-You are Not done Testing Yet Checklist
http://www.thebraidytester.com/downloads/YouAreNotDoneYet.pdf
-Se puede encontrar muchìsima màs informaciòn teòrica dentro del curso gratis:
http://testingeducation.org/BBST/foundations/

33. Testing: Referentes
James Bach
http://www.satisfice.com/blog
http://www.satisfice.com/
Más info acerca de la metodologìa de Rapid Software Testing:
http://www.satisfice.com/info_rst.shtml
A tester's Syllabus - herramientas empìricas de los testers:
http://www.satisfice.com/images/testsyllabus.pdf
Cem Kaner
http://kaner.com
Papel de Cem Kaner acerca de las leyes que engloban el àrea de calidad de
software en los Estados Unidos y Canadà
http://kaner.com/pdfs/asmlaw.pdf

34. GRACIAS!
¿Alguna pregunta?
Podés encontrarme en:
👉 Twitter · @itsShimo
👉 LinkedIn · https://www.linkedin.com/in/gisellellamas/