NEW
Font size
WorksheetsHolistic Testing
Total questions: 40
Worksheet time: 14mins
¿Cuándo se involucran los tester en un proyecto ágil?
En una reunión de planificación del lanzamiento
Cuando el equipo desglosa una funcionalidad en historias
Durante los talleres de preparación de historias o reuniones de refinamiento de backlog
Todas las anteriores son correctas
¿Quién es el responsable del testing en los equipos ágiles?
El dueño del producto
Ingenieros QA
Desarrolladores
El equipo entero
¿Quién debería responsabilizarse de la calidad en un desarrollo ágil? Elige la mejor respuesta
Todos los miembros del equipo de desarrollo
Los dueños del producto
Los ejecutivos de la empresa
Los tester
¿Que herramientas pueden utilizarse para colaborar?
Mapas mentales
Ayudas visuales como mock-ups
Impact mapping o mapa de impacto
Todas las anteriores son correctas
Tu equipo siguiendo un enfoque semi-cascada esta realizando el testing de todas las historias al final de la iteración ¿Que sugerirías para eliminar este problema?
No empezar nuevas historias hasta que las actividades de testing hayan finalizado
Empezar las nuevas iteraciones sin trabajo pendiente de iteraciones anteriores
Reducir el numero de historias en las que se trabaja simultaneamente
Todas las anteriores son correctas
¿Cuál es el objetivo de la "tolerancia cero defectos"respecto a los errores que surjan trabajando como un equipo ágil?
Que quien introduzca un fallo será despedido
Que el cliente no encuentre ningún fallo
Que no halla fallos en el producto
Que todos los fallos se arreglen antes de acabar la iteración
¿Qué tan técnicos deben de ser los tester en los equipos ágiles?
Todos en un equipo ágil incluidos los testers, tienen que ser capaces de escribir código de producción
Los tester no necesitan ninguna habilidad técnica, solo sus habilidades de testing importan
Los tester necesitan tener una conciencia técnica para ser capaces de comunicarse y colaborar con los desarrolladores y otros miembros
Los tester necesitan tener fuertes habilidades de diseño UX
¿Cuál de estas afirmaciones es verdad?
Los programadores en los equipos ágiles no deberían invertir tiempo en las actividades de testing, su tiempo esta mejor empleado escribiendo código
Los equipos ágiles solo tienen dos roles programador y cliente
Los roles en los equipos ágiles (programador, tester, dueño del producto...) estan claramente delimitados y cada persona debería atenerse a su propio rol
Los límites entre los roles en los equipos ágiles son borrosos. Cada miembro del equipo puede entrar a ayudar con cualquier tarea no importa cuál sea su titulo oficial.
Tu equipo no tiene tests de regresión automatizados aún. Para remediarlo tú:
Le pides al manager comprar una herramienta de capture/relay testing de terceros
Te apuntas a un curso online de Selenium
Lo pones en retrospectiva en tu equipo, identificas por donde comenzar y diseñas un pequeño experimento para realizar pruebas
Decides simplemente delegar todo el testing de regresión a un servicio offshore de testing manual
¿Por qué deberíamos automatizar la mayoría de los tests orientados a negocio?
1. Porque la comprobación de la regresión manual toma demasiado tiempo y es propensa a errores
2. Porque los tests de aceptación ejecutables generan documentación cada vez que se ejecutan
Porque si automatizamos los tests ya no necesitaríamos ningún tester en el equipo
1 y 2 son correctas
¿Que NO deberíamos intentar automatizar?
La tareas propensas a errores
Pruebas de humo o Smoke test
Tests que van ejecutar solamente una vez
Construcción y despliegue
¿Dónde deberían los test automatizados ser almacenados y gestionados?
1. En el mismo repositorio que el código de producción, si fuera posible
2. Separados del código de producción para que los test no se corrompan por él
3. No hay la necesidad de tener el código de los tests automatizados en un sistema de control de versiones
2 y 3 son correctas
¿Qué tests son los más adecuados para automatizar en la API o capa de servicio, la capa intermedia de la pirámide?
a) Los tests unitarios o units tests
b) Los test end-to-end
c) La lógica de negocio y la funcionalidad que se encuentran en la capa del servidor
a y b son correctas
Tu equipo esta discutiendo maneras de reducir la tasa de rechazo del dueño del producto para las historias ¿Qué técnicas sugerirías probar?
1. Escribir planes de tests detalladamente para garantizar una mayor cobertura después de escribir el código
2. Preguntar al dueño si puede aprobar una lista detallada de requerimientos para cada historia
3. Antes de cada iteración organizar reuniones de planificación (preparación de las historias o para refinar el backlog) con los testers, stakeholders, y desarrolladores, y utilizar una framework de colaboración como, por ejemplo, mapeo para capturar reglas empresariales, ejemplos y preguntas
4. 1 y 2 son correctas
¿Cuál es una buena manera de documentar estrategias de testing y planes para nuevas funcionalidades?
l. Los mapas mentales, ya que posibilitan la colaboración y hacen el testing más visible para todos
ll. Herramientas de gestión de test comerciales, pues ahorran tiempo
lll. La wiki del equipo, junto con gráficos de pared con los cuadrantes de ágil testing en los que estén marcadas las actividades de testing planeadas
IV. No hay documentación en los proyectos ágiles
Elige la mejor respuesta
I
l y lll
IV
ll y IV
¿Cuáles son las cosas más importantes a considerar cuando se planifican los test a nivel de lanzamiento o funcionalidad?
Dependencias entre equipos o con otras partes del producto
Dependencias entre historias
Escribir tests que cubran los riesgos y las suposiciones realizadas
Todas las anteriores son correctas
¿Quién debería estar involucrado en tomar una funcionalidad y dividirla en historias?
l. El dueño del producto
ll. El analista de negocios
lll. Todo el equipo de desarrollo
IV. El dueño del producto y los programadores
Elija la mejor respuesta
l y ll
l
l y lll
IV
¿Qué puntos puede discutir un equipo para ayudar a elegir las métricas adecuadas?
l. ¿Qué problema necesitamos resolver, cómo podemos medir si estamos mejorando?
ll. ¿Cómo podemos visualizar la métrica de manera que nos ayude a mantenernos por el buen camino?
lll. ¿Los datos son lo suficientemente sencillos como para que podamos recorgerlos y utilizarlos?
IV. La velocidad es la única métrica que los equipos ágiles deberían usar
Elige la mejor respuesta
IV
l y IV
l, ll y lll
lll
El principio básico detrás de ATDD, BDD y SBE es:
Guiar el desarrollo con ejemplos concretos de los comportamientos deseados y no deseados
Escribir test cases para ejecutarlos cuando se termine de programar
Solamente el dueño del producto puede crear tests de aceptación
Hacer code reviews guidas de código ya terminado
De las siguientes opciones ¿Cuál es el mejor momento para hacer exploratory testing y quién debería hacerlo?
l. Cuando los programadores crean que han terminado el código de una historia, y antes antes de hacer commit de los cambios finales, ellos mismos deben explorar el código
ll. Cuando el código de las historias de una funcionalidad está terminado, los tester deberían explorar esa funcionalidad
lll. El código de las nuevas funcionalidades que se haya terminado será examinado por los testers en la siguiente iteración
lV. l y ll son correctas
¿Qué es el criterio de DONE en una historia?
Es un acuerdo entre los miembros del equipo sobre el estándar de calidad que se aplicará a cada historia del producto
Significa que el código está terminado, así que podemos contar los puntos de esta historia (story points) en nuestra velocidad y realizar las pruebas más tarde
Significa que en realidad las historias nunca están terminadas, pues el Product Owner pueden seguir cambiando los requisitos
Una historia está terminada cuando el Product Owner dice que lo está
¿Cómo ayuda un chapter con el exploratory testing?
Guía el testing pero no fuerza al tester a usar datos específicos
Permite a los tester usar sus propias habilidades de pensamiento crítico
Permite al tester concentrarse en un área específica de riesgo
Todas las anteriores son correctas
Eres un programador y te desconcierta el motivo por el que los testers encuentran tantos errores en tu código. De estas opciones, ¿qué es lo mejor que podrías hacer para evitar tantos defectos en tu código?
a) Nada. No te preocupes, es normal tener errores en tu código, para eso hay tester en tu equipo
b) Pedir a un tester que haga pair programming contigo para aprender más técnicas de testing
c) Hacer pair programming con otro programador para mejorar tus técnicas de test-driven development
d) b y c
¿A qué áreas deben los equipos asegurarse de dedicar tiempo y energía?
Historias que son de alto riesgo
Aprender sobre lo 'desconocido'
Comprender las diferencias culturales en el equipo y mantener a los miembros del equipo que trabajan en remoto informados
Todas las anteriores son correctas
En que actividad NO es apropiado que un tester participe:
En la especificación de los test de las historias
En el explory testing sobre una funcionalidad
En las demos para clientes empresariales
En tomar la decisión final sobre si desplegar un posible release a producción
La mejor manera de gestionar errores es:
Ponerlos en sistema de seguimiento de errores y resolverlos más tarde, ahora estás ocupado tratando de terminar tus historias
Que los desarrolladores, testers y otros miembros del equipo colaboren para evitar que haya bugs desde un primer momento. Sin embargo, si no se solucionan inmediatamente, habría que registrarlos en algún lugar
Solamente arreglar los errores que los clientes encuentran en producción, los otros bugs no son importantes
Mantener todos los errores hasta que haya una iteración de 'corrección de bugs'
¿Cómo obtienen los equipos ágiles datos de prueba para sus tests?
Generan datos de prueba con scripts u otras herramientas
Utilizan datos de producción alterados
Cada test crea y destruye sus propios datos
Cualquiera o todas las anteriores
¿Cómo pueden los testers mejor agregar valor a las discusiones sobre la preparación de las historias?
Presentando un plan de testing basado en el documento de requisitos con los test cases detallados
Haciendo preguntas como por ejemplo de que forma el usuario usará la funcionalidad de donde puede el equipo obtener datos de prueba que terceras partes estarán involucradas
Los tester deben permanecer en silencio y no estorbar al equipo
Escribiendo preguntas para hacerlas durante las reuniones de planificación de las iteraciones
El propósito principal del End Game es:
Asegurarse de que las funcionalidades están listas para llevar a producción
Es un hardening sprint o 'sprint de refuerzo' para corregir errores y ponerse al día con la deuda técnica
Es una oportunidad para terminar todo el código
Nunca debería necesitar un End Game en desarrollo ágil
¿Cuál de las siguientes NO es una actividad de testing que podrían realizarse en el End Game?
Tests de aceptación de los usuarios finales
Una última comprobación de regresión
Pruebas de instalación
Pruebas unitarias o unit testing
¿Cuál de las siguientes afirmaciones en cierta?
La necesidad de modificar los datos o de scripts de migración se deben identificar al principio de la planificación de la versión y los scripts también se deben testear durante la iteración así como un entorno de prueba durante el End Game
Los equipos deben realizar todas las actividades de migración de datos, incluyendo escribir los scripts y testearlos durante el End Game, no se posible hacerlo antes
Los equipos deben definir todas las tablas y columnas de sus bases de datos para la aplicación desde el principio y nunca más volver a tocarlas
La migración de datos debe ser testeada en producción
¿Cuál de estas NO es parte de la mentalidad de un agile tester?
Los tester estan aquí para romper el software
Los tester preguntan que pueden hacer para ayudar a entregar el software con éxito
Aplicar valores y principios ágiles para ayudar a añadir calidad
Ser proactivo y aprender continuamente
Los cuadrantes de agile testing son útiles para
1. Ayudar a definir que tests forman parte del 'Story Done' y cuáles del 'Feature Done'
2. Asegurarse de que todas las actividades de testing necesarias pueden verse y estén planificadas
3. Definir el orden en que se realizan las actividades de testing, comenzando en el Q1
4. 1 y 2 son correctas
Una gran diferencia entre el testing en equipos ágiles y el testing en proyectos sincronizados y en fase es:
1. No hay tester en los equipos ágiles
2. Los equipos que desarrollan en cascada nunca automatizan los test
3. Los equipos ágiles comienzan en desarrollo pensando primero en testear y prevenir errores, los equipos que desarrollan en cascada se enfocan en encontrar errores después de que se termina la programación
4. 1 y 2 son correctas
¿Que mentalidad debería tener un tester para ser exitoso en un equipo agile?
¡El testing se usa para encontrar bugs después de que se realiza la programación?
Los testers son los guardianes de la calidad y necesitan actuar como policías de calidad
Los testers deben pensar en como ayudar a entregar el software con éxito y centrarse en la prevención de errores, así como en encontrarlos
Los testers están aquí para romper el software
Podemos usar el modelo de pirámide de automatización de tests para ayudar a
Centrarse en automatizar los tests a través de la interfaz de usuario
Decidir que herramienta de automatización de tests usar
Visibilizar la automatización, hacer que el equipo hable y planee tareas de automatización
Decidir con reglas duras quién debería automatizar el que
Estas en un nuevo equipo que está comenzando un nuevo ciclo de lanzamiento que planea entregar varias funcionalidades en dos meses con iteraciones cada dos semanas. ¿Cómo planificas el testing para este lanzamiento?
1. Obtener todos los detalles de todas esas funcionalidades para comenzar a escribir los tests
2. Hacer preguntas en la reunión de planificación para que las características se entiendan a un alto nivel y se puedan priorizar
3. Comprender los riesgos y suposiciones del testing de alto nivel
4. 2 y 3 son correctas
De las siguientes opciones, ¿cuándo suele ser el mejor momento para escribir tests detallados ejecutables (automatizables) para ayudar a guiar el desarrollo de un conjunto de funcionalidades que incluya una interfaz de usuario, y quién debería escribirlos?
Un tester debe escribir esos tests cuando el código esté terminado para que así la interfaz de usuario sea estable y no cambie más
Un tester debe escribirlos antes de que comience la iteración, y así se tiene en cuenta para la planificación y la programación
Junto a un programador y un stakeholder comercial (dueño del producto o analista de negocios), el tester debe escribir algunos tests básicos de camino feliz antes de que se empiece a escribir el código y después escribir los tests detallados, cuando ya se ha empezado a escribir el código y los tests de camino feliz pasan en verde
En el desarrollo ágil no se escriben tests detallados, solo se hace exploratory testing
¿Que técnicas de exploratory testing ayudan a los equipos ágiles a aprender sobre las funcionalidades y el producto?
Ad hoc y monkey testing
Elaboración de listas de tests manuales y criterios de aceptación
Tours y personajes
Revisiones de código y análisis
Tu equipo de producto te dice que la seguridad es uno de los atributos de calidad más importantes para la aplicación que tu equipo esta desarrollando. Tu equipo discute cómo asegurar que la funcionalidad que se está desarrollando sea segura. Un buen planteamiento es:
a. Adoptar los estándares de programación seguros
b. Decirle al dueño del producto que necesitas dos semanas para los tests de seguridad después de la puesta en pre-producción y no se preocupe por la seguridad hasta ese momento
c. Planificar el tiempo suficiente para realizar exploratory testing sobre la seguridad a nivel de sistema antes del lanzamiento
d. a y c son correctas
