Este documento trata sobre las habilidades necesarias para ser un tester de software. Explica conceptos clave como las habilidades técnicas (conocimientos de testing, programación, herramientas), habilidades blandas (comunicación, pensamiento crítico, trabajo en equipo), y habilidades de negocio específicas de cada industria. También incluye ejemplos de perfiles de tester y estadísticas sobre ofertas de empleo y salarios en el campo del testing.

2. ¿Que es calidad?
0 La calidad es el valor a alguna persona
0 Es subjetiva
0 Diferentes clientes perciben del mismo producto
diferentes niveles de calidad
0 La gente de calidad buscan cosas diferentes para los
diferentes clientes

3. Software Testing
0 Investigación
0 Empirica
0 Tecnica
0 Llevada a cabo para proporcionar a los interesados
0 Con información
0 Sobre la calidad
0 Del producto que se esta probando o del servicio

4. Software Testing
0 Encontrar bugs
0 Evaluar la calidad del producto
0 Ayudar a los managers / Product owners a evaluar el
producto y ayudar en la toma de decisión de liberar el
producto
0 Ayudar a predecir y controlar los costes del soporte del
producto
0 Evaluar la interoperabilidad con otros productos
0 Certificar productos para normativas legales
0 Confirmar que el sistema cumple con las expectativas de
los clientes.

5. El rol del tester

6. Falacias sobre QA

7. Falacias sobre QA
PROGRAMADORES TESTER

8. Falacias sobre QA

9. Falacias sobre QA
El que vale, vale y el que no
para QA
Testing in Google
Testing in Microsoft
Testing in Amazon
Testing in Twitter

10. Tareas del testing
0 Diseñar la arquitectura de testing
0 Diseñar los tests
0 Automatizar si es posible
0 Ayudar a los programadores a realizar su código
0 Evitando los errores de comunicación entre PO /
desarrollo
0 Ayudándoles a hacer tests unitarios
0 Dar información a POs sobre la calidad del producto
0 Revisar las métricas sobre la calidad del producto

11. Sprint planning
0 Planificar las diferentes tareas de
testing
0 Dar al equipo diferentes puntos
de vista sobre las historias de
usuario.
0 Ayudar a definir los criterios de
aceptación mediante preguntas
0 Definir los escenarios que luego
guiaran el desarrollo.

12. Retrospectiva
0 Promover la mejora continua del
equipo.
0 La gente de QA puede exponer las
diferentes deficiencias que han
encontrado durante el desarrollo del
sprint
0 Dan feedback a todo el equipo sobre
la calidad del producto
0 Obtener feedback del resto del
equipo sobre el trabajo del equipo de
calidad

13. Demonstración
0 Ayudar a la preparación de la demostración a los Produto
Owners mediante los escenarios diseñados
0 Pueden resolver o solventar las diferentes dudas que
tengan los clientes sobre el producto

14. Durante el sprint
0 Acabar de diseñar los escenarios y los diferentes
casos de prueba
0 Automatizar los casos de prueba
0 FrontEnd
0 BackEnd
0 Mantener el sistema de integración continua
0 Revisar las métricas de desarrollo

15. El día a día de un QA
3
2
1
Let’s Go!

16. Sprint Planning
0 Google API sobre codificación Geográfica:
0 Queremos ofrecer un producto que nos ayude a mejorar
nuestros conocimientos de Geografía.
0 Como usuario necesitamos un producto que cuando le
indiquemos una ciudad nos devuelva el país al que pertenece.
0 A parte necesitamos guardar si la petición se realiza desde un
dispositivo con un sensor de localización para usos futuros.

17. Sprint Planning
La historia de usuario podría
ser:
Como usuario
Quiero saber el código del país
de una localización
Para mejorar mis conocimientos
de Geografía

18. Sprint Planning
0 Empezamos a construir y pensar escenarios para
definir los criterios de aceptación:
0 Que pasa si le damos una ciudad que no existe?
0 Que pasa si no le damos ninguna localización?
0 Que pasa si le damos una ciudad mal deletreada?
0 Que pasa si no le damos un valor en el sensor?
0 Hay auntenticación

19. Sprint Planning
0 La gente de programación hace una aproximación
técnica de la solución:
0 API:
0http://maps.googleapis.com/maps/api/geocode/output?p
arameters
0 Como parámetros
0address (ciudad de la que queremos saber el código del país)
0Sensor (indica si la solicitud de codificación geográfica
procede de un dispositivo con un sensor de ubicación)

20. Creamos los escenarios
Scenario Outline: Retrieve the geolocation with city name given
and without sensor
Given a <city> name
When I request the geoencoding of the city
Then I obtain the <city> name with the <country_code>
Examples:
| city | country_code |
| Barcelona | ES |
| Paris | FR |
| San+Francisco | US |

21. Programamos los escenarios
0 Cada uno de los pasos se corresponde a una función.
0 Cada función tiene los pasos necesarios para ejecutar
el comportamiento definido por la función
0 Given: Pasos para hacer setting de las precondiciones
0 When: Las acciones que se deben realizar dentro del
escenario
0 Then: Se realizan las comprobaciones necesarios para
comprobar el comportamiento de la funcionalidad.

22. Ejecutamos!

23. Refactor
0 Vamos obteniendo y dando feedback de los
programadores y Product Owners
0 Refactorizamos nuestros tests para que aumentar la
reutilización de código y mejorar el mantenimiento
0 Aumentamos el número de tests para cubrir más
escenarios.

24. Documentación
0 Los escenarios que hemos creado usando BDD son
ejemplos de como funciona nuestra aplicación
0 Podemos utilizar los escenarios que hemos creado
como documentación del proyecto

25. FrontEnd
0 Podemos realizar el mismo ejercicio si lo que tenemos
que probar es un Front End:
0 Probamos el login / pwd de Gmail?

26. Recomendación

27. Sprint Planning
La historia de usuario podría
ser:
Como usuario
Quiero entrar en la aplicación
Gmail cuando introduzco mi
usuario y contraseña
Para poder ver mis correos

28. Sprint Planning
0 Empezamos a construir y pensar escenarios para
definir los criterios de aceptación:
0 Que pasa si ponemos un usuario que no existe?
0 Que pasa si ponemos una combinación de usuario /
contraseña no validos?
0 Que pasa si dejo alguno de los 2 campos vacíos?
0 Que pasa si accedo a la página por https?
0 Hay algún carácter prohibido en el username o el pwd?

29. Sprint Planning
0 Programadores / arquitectos definen la URL y los
paramatros / identificadores de los elementos de la
página:
0 URL:
0http://gmail.com
0 Como parámetros
0TextBox username: Email
0TextBox pwd: Passwd
0Button Sign In: signIn

30. Creamos los escenarios
Scenario Outline: Incorrect login
Precondition: User created with username: testing and
password: fib
Given a <username> and <password>
When I make a login
Then I obtain an error
Examples:
| username | password |
| testing | testing1 |
| qa | fib |
| fib | testing |
| testing | |

31. Seguimos con el proceso
0Se programan los pasos necesarios
0Se ejecutan los tests diseñados
utilizando mocks o cuando el código
este disponible
0Refactorizamos

32. Skills
Ok! Me has
convencido…
Que necesito?

33. Testing Skills
0 Hard Skills
0 Soft Skills
0 Bussiness skills

34. Hard Skills
Conocimientos sobre testing
Lenguajes de programación
Herramientas
Management
ALM

35. Conocimientos testing

36. Desarrollo de software
0 Lenguajes de programación
0 Modelado de software
0 Diseño de software
0 Configuración
0 Application Life Cycle

37. Herramientas
0 Automatización
0 SCM
0 Performance
0 Seguridad
0 Management
0 Defect Tracking

38. Soft Skills
Comunicación
Observación
Pensamiento crítico
Creatividad
Análisis
Team player

39. Comunicación
0 Interlocutores entre varios miembros del equipo.
Active listener Speaking and writting

40. Observación
0 Una de las principales
misiones del tester es
encontrar defectos
0 Observar todos los
detalles del software para
encontrar anomalías.

41. Creatividad
0 El 70 % de las pruebas
generalmente pueden ser
diseñadas mediante
técnicas de testing
comunes.
0 Permite encontrar pruebas
“diferentes” no previstas
por otros miembros del
equipo.

42. Team Player
0 Tester debe ser capaz
de integrarse en el
todo el equipo.
0 La calidad es
responsabilidad de
todos.
0 Participante activo en
el equipo.

43. Continuos learning
0 Aplicar una cultura de
feedback.
0 Aprender de los aciertos y
de los errores.
0 Importante para crecer
como profesional.

44. Bussiness skills
0 Dependen del sector
profesional
0 Muy volátiles
0 Necesitan una constante
actualización.
0 Pueden afectar a niveles de
diseño de software y de
pruebas.
0 No son reutilizables entre
diferentes sectores.

45. Perfiles de testing
0 Funcionales / Automatizadores
0 FrontEnd
0 BackEnd
0 SAP
0 Moviles
0 …
0 Performance
0 Seguridad
0 Usabilidad
0 Managers

46. Algunos números

47. Ofertas de trabajo
0 En Infojobs
0 42 ofertas si buscamos por QA
0 142 ofertas si buscamos testing
0 Empresas como
0Edreams
0Softonic
0eMagister
0Thomson Reuters
0Zurich

48. Algunos datos más

49. Encuesta salarios

50. OK, Me has convencido
Por donde empiezo?

51. Libros
0Testing Computer
Software
0Agile Testing
0Lessons Learned in
Software Testing
0A Practitioner's Guide to
Software Test Design

52. Cursos
0Webinars en EuroStar
0Udacity
0Materiales de cursos de pago disponibles:
0Syllabus ISTQB
0Rapid Software Testing
0BBST

53. Blogs & Forums
• SQAForum
• Utest
• QualityTesting
• Softwaretestingclub
Forums:
• http://www.satisfice.com/
• http://www.shino.de/
• http://softqatest.com/
Blogs:

54. Learning By Doing
Weekend Testing
Testing Dojos
Ayudar en proyectos
Open Source

55. Preguntas

56. Contacto
0 Antonio Robres Turón
0 Twiiter: @twiindan
0 Email: twiindan@gmail.com
0 Linkedin: http://es.linkedin.com/in/antoniorobres
0 Web: www.softqatest.com
0 Asociación: http://es.testqa.org/