Expositora: Juliana Herbert Resumen: En 1979, en su clásico libro “The Art of Software Testing”, Glendford Myers definió testing como el “proceso de ejecutar el programa con la intención de encontrar defectos”. Hoy en día se habla del testing con otros objetivos, relacionados a la búsqueda de calidad, más informaciones para la toma de decisiones y disminución de riesgos, entre otros. Además, el desarrollo de software ha evolucionado bastante, los sistemas son cada vez más complejos y conceptos como movilidad y procesamiento en la nube aumentan la variedad de contextos y ambientes que deben ser considerados para el testing. Sin embargo, ¿el testing realmente ha evolucionado a lo largo del tiempo? ¿Estamos consiguiendo cumplir con el objetivo presentado por Myers en 1979? ¿La base que ha sido construida para el testing es robusta? ¿Cuál fue la evolución del perfil y de las habilidades del tester? ¿Cuál es el impacto de paradigmas como agile, lean y otros sobre el testing? La charla tiene el objetivo de presentar una serie de reflexiones sobre este asunto, identificando puntos de evolución, involución y estagnación del área del testing al largo del tiempo.

1. Tes$ng
Uy
2
–
14
de
abril
de
2015

2. • Considerada
el
“primer
computador”
de
la
historia.
• Ac6vidades
de
verificación
y
de
validación.
2

3. • Escribió
el
primer
“programa”
de
computador
para
la
máquina
de
Babbage.
• Encontró
un
defecto
con
el
primer
debugging.
3

4. • Thomas
Edson
iden6ficó
un
bug
depurando
su
máquina
de
telégrafo.
4

5. • “Eletronic
Numerical
Integrator
and
Computer”.
• “Una
de
las
grandes
preocupaciones
era
que
sus
resultados
fuesen
altamente
confiables”.
• “ENIAC
fallaba
2
a
3
veces
por
semana”.
• “Los
fallos
fueron
encontrados
a
través
de
funciones
de
tes6ng
introducidas
en
los
programas”
5

6. • Paper
“On
Checking
a
Large
Rou;ne”
–
Turing
propone
una
estrategia
para
verificar
si
un
programa
está
correcto.
• Uso
de
aser6vas.
6

7. • Calidad
definida
como
“adecuación
al
uso”.
• Ges6ón
de
calidad:
planificación,
monitoreo
y
control,
mejora.
7

8. • Primer
libro
sobre
programación.
• Escrito
por
Daniel
McCracken.
• Aconseja
el
uso
de
break
points
para
verificar
el
funcionamiento
del
programa
durante
su
ejecución.
8

9. • Charles
Baker
(RAND
Corpora;on)
define
las
diferencias
entre
tes;ng
y
depuración,
revisando
el
libro
de
Daniel
McCracken.
9

10. • Formada
por
Gerald
Weinberg
–
Projecto
Mercury
(para
inves6gar
la
capacidad
de
humanos
para
viajar
en
el
espacio).
10

11. • Libro
escrito
por
Gerald
Weinberg
y
Herbert
Leeds.
• Con6ene
un
capítulo
sobre
tes;ng
de
soZware,
relacionado
a
la
adaptabilidad
del
programa.
11

12. 1967
–
Ar6go
de
IBM
“Func;onal
Tes;ng
of
Control
Programs”
–
William
Elmendorf.
1968
–
Durante
la
conferencia
de
Ingeniería
de
SoZware
promovida
por
NATO
–foco
en
no
solamente
ser
correcto
funcionalmente,
pero
también
traer
valor
al
usuario.
1969
–
“El
tes;ng
enseña
la
presencia,
no
la
ausencia
de
defectos”
–
Edsger
Dijkstra.
12

13. 1971
–
Tes6ng
de
Mutación
–
Richard
Lipton.
1972
–
“The
Humble
Programmer”
–
Edsger
Dijkstra
–
No
probar
la
correteza
del
programa
después
de
desarrollarlo.
1973
–
“Program
Test
Methods”
–
William
Hetzel.
1975
–
“Toward
a
Theory
of
Test
Data
Selec;on”
–
John
Goodenough
y
Susan
Gehart.
1976
–
“Design
and
Code
Inspec;ons”
–
Michael
Fagan.
1976
–
“SoFware
Relibility:
Principles
and
Prac;ces”
–
Glenford
Myers
–
obje6vo
del
tes6ng:
hacer
con
que
el
programa
falle”.
13

14. 1977
–
“Factors
on
SoFware
Quality”
–
Jim
McCall,
Paul
Richards
y
Gene
Walters.
1977
–
“Program
Tes;ng
Techniques”
–
Edward
Miller
–
técnicas
estructurales
de
tes6ng.
1978
–
“Func;onal
Program
Tes;ng”
–
William
Howden.
1978
–
“State
Transi;on
Tes;ng”
–
Tsun
Chow.
1979
–
“The
Art
of
So+ware
Tes/ng”
–
Glenford
Myers.
14

15. 1981
–
“SoFware
Engineering
Economics”
–
Barry
Boehm.
1982
–
“Out
of
the
Crisis”
–
Edward
Deming.
1982
–
“Life
Cycle
Concept
Considered
Harmful”
–
Daniel
McCracken
y
Michael
Jackson.
1983
–
IEEE
829
–
Standard
for
SoFware
Tes;ng
Documenta;on.
1983
–
Publicación
del
“US
Federal
V&V
Standard”.
1986
–
V-­‐model
-­‐
Paul
Rook.
15

16. 1986
–
Creación
de
SQE.
1986
–
“No
Silver
Bullet
–
Essence
and
Accidents
of
SoFware
Engineering”
–
Fred
Brooks.
1987
–
“Test
then
code”
–
Fourth
Interna6onal
Conference
on
SoZware
Tes6ng
(SQE).
1988
–
“Tes;ng
Computer
SoZware”
–
Tes6ng
exploratório
–
Cem
Kaner.
16

17. 1990
–
Taxonomía
de
Bugs
–
Boris
Beizer.
1990
–
Paradojo
del
Pes6cida
–
Boris
Beizer.
1991
–
Publicación
del
standard
ISO/IEC
9126.
1991
–
Primera
publicación
del
CAST
Report.
1992
–
Technical
Debt
–
Howard
Cunningham.
1993
–
Scrum
–
Jeff
Sutherland.
1994
–
Primero
Chaos
Report
–
Standish
Group.
1995
–
Publicación
de
TMAP
(Mar6n
Pol,
Ruud
Teunissen
y
Erik
van
Veenendaal).
1996
–
Desarrollo
del
TMM.
1996
–
Estrategia
de
tes6ng
basada
em
heurís6cas
–
James
Bach.
1997
–
Primero
encuentro
de
testers
seniors
–
LAWSW
–
Cem
Kaner
y
Brian
Lawrence.
17

18. 1999
–
Tes6ng
basado
en
contexto
–
Cem
Kaner,
James
Bach,
Brian
Marick
y
Brep
Peqchord.
Varias
heramientas
lanzadas!
Cer6ficaciones
en
tes6ng!
18

19. 2000
–
tes;ng
bassado
em
sesiones
–
Jonathan
Bach.
2000
–
Integración
consnua
–
Mar6n
Fowler.
2001
–
Manifiesto
Agil.
2001
–
“Lessons
Learned
on
SoZware
Tes6ng”
–
James
Bach,
Cem
Kaner
y
Brep
Peqchord.
2002
–
Fundación
de
ISTQB.
2002
–
Test
Driven
Development
-­‐
Kent
Beck.
2003
–
Fundación
de
la
AST.
2003
–
Cuadrantes
del
Agile
Tes;ng
–
Brian
Marick.
2003
–
Tes;ng
de
escenarios
–
Cem
Kaner.
2005
–
TMMi.
Muchas
conferencias
y
algunas
cer6ficaciones!
19

20. 2010
–
Primera
edición
de
la
revista
“Tes;ng
Circus”.
2011
–
“Test
is
Dead”
-­‐
Alberto
Savoia.
2011
–
Specifica;on
by
Example
–Gojko
Adzic
2012
–
Primera
conferencia
“Let´s
Test”,
en
Suecia.
2014
–
Primer
Tes;ng
Uy,
com
211
par6cipantes!
2015
–
Tes6ng
Uy
2!!
20

21. Tenemos,
desde
hace
mucho
6empo:
• Técnicas
de
tes;ng;
• Estrategias;
• Conceptos
de
defectos;
• Análisis
relacionada
a
prác6cas
de
ingeniería
de
soZware;
• Normas,
estándares,
modelos,
templates,
etc.
21

22. Las
alterna6vas
de
tes;ng
están
relacionadas
también
a:
• Decisiones
de
negocio,
lucro,
cronogramas;
• Miedo,
incer6tud
y
dudas;
• Datos
incompletos;
• Disponibilidad
de
herramientas;
• Resistencia
de
los
testers...
También:
a
un
deseo
altruista
de
tener
una
mayor
calidad
de
soZware...
22

23. Por
la
academia:
Búsqueda
de
nuevos
métodos,
técnicas,
estrategias
de
tes6ng,
sin
explorar
completamente
las
que
ya
fueron
propuestas.
Por
la
industria:
Sen6miento
de
que
solamente
es
posible
probar
con
el
uso
de
herramientas
(que
son
caras,
o
entonces
necesitan
de
6empo
para
aprender
a
usarlas…).
Falta
de
conocimiento
del
estado
del
arte
del
tes6ng.
23

24. Conceptos
“nuevos”
como:
• Agile
tes;ng
• Mobile
tes;ng
• Sistemas
embarcados
• Cloud
compu;ng
• Sistemas
de
sistemas
• Etc...
Parecen
necesitar
de
nuevas
técnicas,
métodos,
herramientas,
estrategias
de
tes6ng...
24

25. “Necesitamos
de
más
conocimiento
maduro
y
robusto
de
tes6ng”.
“Necesitamos
de
testers
que
en6endan
el
contexto
en
que
es
realizado
el
tes6ng,
que
se
adapten”.
25

26. “Necesitamos
de
testers
intelectuales.
Que
sepan
pensar.
Que
sepan
u6lizar
técnicas,
métodos
y
estratégias
de
tes6ng.
Testers,
be
smart!”
26

27. “Testers
necesitan
habilidades
de
ges6ón,
de
discernimiento,
de
entender
los
riesgos
de
las
varias
formas
de
hacer
tes6ng.”
27

28. “Testers
no
deben
tener
miedo.
Y
conseguirán
no
tener
miedo
cuando
tengan
conocimiento,
habilidades
y
sobretodo
en6endan
lo
que
trae
más
valor
al
tes6ng
y
al
soZware”.
28

29. Las
ac6vidades
de
tes6ng
deben
ser
consistentes
con
relación
a
sus
obje6vos.
Los
obje6vos
deben
ser
conocidos.
El
valor
de
negocio
debe
ser
prioritario.
El
tester
6ene
responsabilidad
social,
con
los
usuarios,
los
clientes
y
con
los
desarrolladores.
29

30. Tes$ng
Uy
2
–
14
de
abril
de
2015