3. SOBRE MÍ: TRAYECTORIA
Uni Karlsruhe, Alemania
Ing. Electrónica y Tecnología FOTON,
de la Información LAS PALMAS
MEDIA LAB AENTOS,
EUROPE, IRLANDA LAS PALMAS
1996 2003 2005 2007
DEPt.
DEPt. TEST de SOFTWARE
SISTEMA - VEHICULOS - PFC
SIEMENS MERCEDES,
AUTOMATIZACION ALEMANIA
PASCAL JAVA PYTHON
C/C++ C/C++ C/C++ RUBY / RUBY ON RAILS
1996 2003 2005 2007
4. EL TÉRMINO “BUG” I
“It has been just so in all of my inventions. The frst
step is an intuition, and comes with a burst, then
difculties arise — this thing gives out and [it is] then
that 'Bugs' — as such little faults and difculties are
called — show themselves and months of intense
watching, study and labor are requisite before
commercial success or failure is certainly reached.”
Thomas Edison, 1878
5. EL TÉRMINO “BUG” II
→ 9 de Septiembre de 1945
→ Universidad de Harvard
→ Los operadores retiran una
polilla de uno de los relés del
calculador “Mark II Aiken”.
→ “First actual case of bug being
found”.
6. EL CASO ARIANE 5
→ 4 de Junio de 1996
→ Vuelo 501 del cohete Ariane 5
→ 40 segundos después de entrar en
secuencia de vuelo el Ariane 5 se
autodestruye a una altura de 3700m
→ Motivos: análisis y pruebas
insufcientes del sistema de referencia
inercial y el sistema de control de
vuelo.
→ Causa: conversión de un número
demasiado grande → “overfow”
7. EL TIEMPO QUE INVERTIMOS EN
BUSCAR ERRORES
“If you look at how most programmers spend their time, you'll fnd that writing
code is actually a small fraction. Some time is spent fguring out what ought to be
going on, some time is spent designing, but most time is spent debugging. […]
Fixing the bug is usually pretty quick, but fnding it is a nightmare.”
Refactoring, Martin Fowler [Ref]
8. EL COSTE DE LOS ERRORES
150x
[AOOP]
COSTE RELATIVO DE ARREGLAR UN ERROR
10x
5x
1x
REQ. DISEÑO IMPLEM. OPER.
9. EL PROCESO DEL DESARROLLO
CLÁSICO
REQUISITOS
DISEÑO
IMPLEMENTACIÓN
PRUEBAS / VALIDACIÓN
MANTENIMIENTO
10. EL MANIFIESTO ÁGIL
4 Principios:
→ Valorar más a los individuos y su interacción que a
los procesos y las herramientas
→ Valorar más el software que funciona que la
documentación exhaustiva
→ Valorar más la colaboración con el cliente que la
negociación contractual
→ Valorar más la respuesta al cambio que el
seguimiento de un plan
11. DESARROLLO WEB ÁGIL
FUNCIONALIDAD n FUNCIONALIDAD n+1
DISEÑO DISEÑO
IMPLEMENTACIÓN IMPLEMENTACIÓN
PRUEBAS / VALIDACIÓN PRUEBAS / VALIDACIÓN
DESPLIEGUE DESPLIEGUE
12. ¿QUÉ ES EL TESTING? I
Testing = Pruebas de software
Preguntas:
→ ¿El código que acabo de escribir funciona bien?
→ ¿El software hace lo que el cliente desea?
→ ¿El software continúa funcionando bien después del
último cambio que he introducido?
13. ¿QUÉ ES EL TESTING? II
Objetivos
→ Detectar errores (cuanto antes mejor)
→ Validar que el software hace lo que debe
→ Especifcación
→ Confanza y seguridad
→ Ahorrar tiempo de trabajo
14. TIPOS DE PRUEBAS
de integración
de sistema de carga
unitarias de validación
de regresión de aceptación
funcionales
15. TIPOS DE PRUEBAS: UNITARIAS
prueban el correcto funcionamiento de un módulo de código
CLASE
DATOS DE PRUEBA RESULTADOS
ÁREA: 7
P. EJ. MÉTODO ÁREA
LADO A: 2 DE UN RECTÁNGULO
≠
LADO B: 4
=?
RESULTADOS ESPERADOS
ÁREA: 8
16. TIPOS DE PRUEBAS: DE
ACEPTACIÓN
prueban el comportamiento desde el punto de vista del
cliente
Scenario: Login with correct credentials
When I go to the login page
And I fill in "Login" with "manfred"
And I fill in "Password" with "gurke"
And I press "Login"
Then I should see "Logged in"
And I should be on the homepage
Scenario: Login with incorrect credentials
When I go to the login page
And I fill in "Login" with "manfred"
And I fill in "Password" with "tomate"
And I press "Login"
Then I should see "Wrong username/password"
And I should be on the login page
17. TIPOS DE PRUEBAS: DE
REGRESIÓN
Regresión
→ error ya resuelto que vuelve a aparecer
Funcionamiento
→ cuando surge un error escribes una prueba para
demostrar que falla y arreglas el error. La prueba
garantizará que el error no vuelva a aparecer
18. TIPOS DE PRUEBAS: DE CARGA
→ ¿Cómo responderá el sistema cuando entre en producción
con 25.000 usuarios y 50.000 visitas diarias?
→ ¿Cuáles son los cuellos de botella?
→ ¿Que partes de la aplicación hay que optimizar?
19. PRUEBAS MANUALES
→ Repetir todas las pruebas en cada despliegue
→ Consumen mucho tiempo
→ Aburridas y mecánicas
“Monkey testing”
20. PRUEBAS AUTOMATIZADAS
¿Por qué?
→ Tiempo = $$$
→ Automatizar = Ahorrar tiempo = Ahorrar $$$
Deben ser
→ Reusables = rentables
→ Robustas para que no se dañen con facilidad al modifcar
el código
21. PRUEBAS AUTOMATIZADAS vs
MANUALES
Automatizadas más rentables con el tiempo → Reusables
Coste $$$
Tiempo
22. PRUEBAS AUTOMATIZADAS vs
MANUALES II
Ejemplo: Probar manualmente un formulario de registro
Probar 1 vez Probar 50 veces
Manual 2-4 minutos 100 a 200 minutos
5 – 30 minutos ~ 5 – 30 minutos
(escribir el test) (escribir el test)
Automatizada 10 seg. +
(ejecutarlo) 8 minutos
(ejecutarlo 50 veces)
23. REFACTORIZAR CÓDIGO
Cambiar el diseño SIN cambiar el comportamiento
→ Usualmente motivado por el “mal olor” del código
Objetivos:
→ Aumentar la legibilidad
→ Reducir la complejidad
→ Mejorar la mantenibilidad
24. PRUEBAS: CONFIANZA Y
SEGURIDAD
Sentirnos seguros
→ de que lo estamos haciendo bien
→ poder refactorizar
Sentir y dar confanza a los demás
→ funcionamiento correcto demostrable
25. PRUEBAS: ESPECIFICACIÓN
Las pruebas defnen cómo se debe comportar el código y la
aplicación
→ Las pruebas sirven como especifcación
→ Cuando un nuevo desarrollador se incorpora al equipo o
toma el relevo tiene las pruebas y conoce el
comportamiento deseado
26. ¿QUIERES SER UN COWBOY?
LOS PISTOLEROS DISPARAN SIN PESTAÑEAR Y
SIEMPRE SE LA JUEGAN