Debido a las metodologías ágiles las metodologías clásicas están en desuso Verdadero Falso. Las metodologías ágiles son más comunes que las metodologías clásicas Verdadero Falso. Las metodologías clásicas son más comunes que las metodologías ágiles Verdadero Falso. Extreme Programming (XP) es una metodología en cascada para el desarrollo de software Verdadero Falso. Extreme Programming (XP) es una metodología ágil para el desarrollo de software Verdadero Falso. Extreme Programming (XP) es una metodología clásica para el desarrollo de software Verdadero Falso. Extreme Programming se sustenta principalmente en ______ valores 3 4 5 6 7. Extreme Programming se sustenta sobre 5 reglas Verdadero Falso. Extreme Programming se sustenta sobre 5 valores Verdadero Falso. Cuáles de las siguientes características NO es uno de los valores de Extreme Programming Valentía Comunicación Respeto Enfoque Retroalimentación. Cuáles de los siguientes características SI es uno de los valores de Extreme Programming Transparencia Inspección Simplicidad Apertura Enfoque. ¿Qué es KISS en Extreme Programming? Simplicidad Respeto Retroalimentación Ninguna es correcta . ¿A qué valor de Extreme Programming corresponde la siguiente "descripción"?
No me anclo, pero todo lo que hago es con cabeza Valentía Comunicación Retroalimentación Respeto Simplicidad. ¿A qué valor de Extreme Programming corresponde la siguiente "descripción"?
Es fundamental entre el equipo y el cliente, ya que ambos deben participar en la creación del proyecto Valentía Comunicación Retroalimentación Respeto Simplicidad. ¿A qué valor de Extreme Programming corresponde la siguiente "descripción"?
De cada parte que hago recibo feedback de los juicios de todos mis compañeros Valentía Comunicación Retroalimentación Respeto Simplicidad. ¿A qué valor de Extreme Programming corresponde la siguiente "descripción"?
Trabaja lo menos posibles obteniendo siempre lo máximo Valentía Comunicación Retroalimentación Respeto Simplicidad. En Extreme Programming la unidad de medida es Las HU El tiempo Las iteraciones Las entregas. En la metodología de trabajo de Extreme Programming se debe llevar un desarrollo variable pero con un ritmo sostenible Verdadero Falso. En la metodología de trabajo de Extreme Programming se debe llevar un desarrollo iterativo pero con un ritmo sostenible Verdadero Falso. En Extreme Programming no existen las Historias de Usuario Verdadero Falso. En Extreme Programming la planificación es trimestral Verdadero Falso. En Extreme Programming se permiten los reajustes y cambios trimestralmente Verdadero Falso. En Extreme Programming se práctica el ajuste continuo Verdadero Falso. En Extreme Programming la planificación es trimestral pero se aplica el ajuste continuo Verdadero Falso. En Extreme Programming se puede reajustar la planificación fuera del plazo trimestral Verdadero Falso. Las iteraciones en Extreme Programming son Mensuales Semanales Trimestrales Variables. En Extreme Programming existen 3 roles fundamentales en el equipo de desarrollo: desarrolladores, Product Owner, y supervisor Verdadero Falso. En Extreme Programming existen 3 roles fundamentales en el equipo de desarrollo: Desarrolladores, Product Owner, y supervisor Desarrolladores, investigador, y supervisor Desarrolladores, Product Owner, e investigador No existen roles en Extreme Programming. ¿Qué son los SLACKS? Tiempo de la jornada en la que en vez de programar se aprende algo nuevo Tiempo sobrante que suele darse al finalizar una iteración antes de tiempo Iteraciones que excepcionalmente duran más que la media por lo que debe reajustarse la planificación Divisiones de tiempo dentro de las iteraciones semanales en los que los desarrolladores ponen en común su trabajo . ¿Cuál es el tiempo que suele dedicarse a los SLACKS? Menos del 20% de la jornada laboral El 10% de cada iteración 1h por cada 10 trabajadas Mínimo 15 minutos al día . Comunicación Osmótica en Extreme Programming, ¿qué es? El equipo trabaja en un espacio compartido por lo que todas las dudas y resoluciones también son compartidas en el momento en el que se hacen El equipo debe ponerse en contacto cada hora durante 10 minutos para exponer las dudas o eventos relevantes encontrados de modo que todos están al tanto de todo. ¿Qué día no puede ser nuca la reunión semanal de Extreme Programming? Lunes Martes Miércoles Jueves Viernes. ¿Por qué la reunión semanal de Extreme Programming no puede ser un lunes? Porque los trabajadores no descansan el finde se semana Porque suele el ser el día con más bajas laborales Porque los trabajadores no tienen "fresco" el trabajo que hicieron el viernes anterior Porque los empleados deben preparase cierto información que no pueden hacer antes de la reunión . En la reunión trimestral de Extreme Programming no se planifica Verdadero Falso. En la reunión trimestral de Extreme Programming se planifica las HU de esa semana pero no se altera el plan trimestral Verdadero Falso. En la reunión trimestral de Extreme Programming se puede modificar el plan trimestral Verdadero Falso. En Extreme Programming se añaden HU de usuario cada 3 meses no en cada iteración Verdadero Falso. En la reunión semanal de Extreme Programming se habla de lo que se ha hecho, de lo que se va a hacer y se planifica Verdadero Falso. El ajuste continuo del plan trimestral se realiza en la reunión semanal Verdadero Falso. El ajuste continuo del plan trimestral se realiza todos los lunes Verdadero Falso. El ajuste continuo del plan trimestral se realiza en la extreme reunión Verdadero Falso. En las reuniones semanales de Extreme Programming debe participar el cliente Verdadero Falso. En Extreme Programming el cliente colabora con la creación de la Historias de Usuario Verdadero Falso. Extreme Programming no fomenta el programar en parejas Verdadero Falso. Programar en parejas solo sirve para intercambiar conocimientos entre 2 programadores Verdadero Falso. Es beneficioso que más de una persona conozcan el código Verdadero Falso. Programar en pareja empeora la calidad del código, ya que ralentiza el desarrollo Verdadero Falso. Programar en parejas ralentiza el desarrollo al principio Verdadero Falso. Un código programado en parejas tiende a ser de mayor calidad Verdadero Falso. Programar en parejas consiste en dos personas con su respectivo ordenador desarrollando el mismo código a la vez y comunicándose y ayudándose en el proceso Verdadero Falso. Programar en parejas consiste en dos personas con un único ordenado Verdadero Falso. Compilar y ejecutar un programa no debe tardar más de: 5 minutos 10 minutos 15 minutos 12 minutos. Los Spikes están incluidos en la "tabla" de las historias de usuario Verdadero Falso. El TDD es como Un ciclo Una secuencia de pasos Una reglas a seguir Un triángulo . En el TDD lo que primero se escribe es: El test El código . ¿Cuál es el orden a seguir en el TDD? Primero Segundo Tercero. El primer TDD sobre el código siempre debería fallar Verdadero Falso. En TDD reescribimos el código cuando el test falla Verdadero Falso. El primer TDD sobre el código siempre debería funcionar Verdadero Falso. El objetivo del TDD es probar el código Verdadero Falso. El objetivo del TDD es programar el código para que no pase las pruebas Verdadero Falso. En TDD solo se puede escribir código si es para corregir un test que falla Verdadero Falso. En el TDD tengo que redactar los test de cara a que el código los pase Verdadero Falso. En el TDD tengo que redactar los test de cara a que el código los fallé Verdadero Falso. Gracias al TDD obtener códigos con todas las necesidades cubiertas Verdadero Falso. No podemos evitar que el TDD sea infinito, simplemente paramos de hacer pruebas Verdadero Falso. Para que el TDD no sea infinito Utilizamos pruebas de caja negra Marcamos un límite de test por código Paramos cuando el código pase todos los test Utilizamos pruebas de caja blanca. Si necesito un número del rango 0 y 100, ¿con qué número implemento las pruebas de caja negra de particiones de equivalencia? -1/ 10 / 200 10 / 25 / 50 /75 / 90 0 / 50 / 100 0 / 100. Las pruebas TDD se hacen con los valores límite Verdadero Falso. Las pruebas TDD se pueden hacer con cualquier valor pero no es recomendable Verdadero Falso. Existen 2 tipos de pruebas TDD De unidad e integración De comprobación y corrección . Prueba de calidad dentro de una función o mi código único Prueba de unidad Prueba de integración . Prueba de la relación entre 2 clases Prueba de unidad Prueba de integración . Los objetivos del TDD son 4 Verdadero Falso. ¿Cuál de los siguientes no es un objetivo del TDD? Favorecer diseños buenos y simples Eliminar fallos por suposiciones erróneas Producir código que pueda ser probado Asegurar un código libre de fallos. ¿Cuál de los siguientes si es un objetivo del TDD? Evitar problemas de un código con baja calidad Soporta el desarrollo evolutivo Proporciona evidencias concretas de que el software funciona Proporciona un código más limpio y simple. En el ciclo TDD la palabra correspondiente a la parte de escribir pruebas corresponde con: Rojo Verde Refactor. En el ciclo TDD la palabra correspondiente a la parte de escribir el código de para que la prueba funcione corresponde con: Rojo Verde Refactor. En el ciclo TDD la palabra correspondiente a la parte de simplificar el código corresponde con: Rojo Verde Refactor. Las pruebas de caja blanca son apropiadas para hacer TDD Verdadero Falso. Las pruebas de caja negra son apropiadas para hacer TDD Verdadero Falso. En análisis minucioso del código corresponde con Las pruebas de caja blanca Las pruebas de caja negra. Suelen ser más difíciles Las pruebas de caja blanca Las pruebas de caja negra. Suelen ser más costosas Las pruebas de caja blanca Las pruebas de caja negra. Analizan los requerimientos funcionales (qué resultado espero, sin importar como esté programado) Las pruebas de caja blanca Las pruebas de caja negra. Detecta errores como: funciones incorrectas o ausentes y estructura de datos Las pruebas de caja blanca Las pruebas de caja negra. Diferencia entre OBJETIVOS y BENEFICIOS del TDD Objetivos Beneficios. Diferencia entre OBJETIVOS y BENEFICIOS del TDD Objetivos Beneficios. En las particiones de equivalencia de las pruebas de caja negra, sobre un valor concreto obtengo 3 clases de equivalencia 1 clases de equivalencia 2 clases de equivalencia. En las particiones de equivalencia de las pruebas de caja negra, sobre un valor de un rango obtengo 3 clases de equivalencia 1 clases de equivalencia 2 clases de equivalencia. En las particiones de equivalencia de las pruebas de caja negra, sobre un valor dentro de un conjunto obtengo 3 clases de equivalencia 1 clases de equivalencia 2 clases de equivalencia. En las particiones de equivalencia de las pruebas de caja negra, sobre un valor booleano obtengo 3 clases de equivalencia 1 clases de equivalencia 2 clases de equivalencia. En las particiones de equivalencia de las pruebas de caja negra, ¿qué clases obtengo? Sobre un valor en un rango entre 0 y 99 Sobre un valor concreto, 50. Para probar valores límite con las pruebas de caja negra probamos con min-1, min, min+1, max-1, max, max+1 min-1, min+1, max-1, max+1 min-1, min, max, max+1 min, min+1, max-1, max. ¿Cuánto casos serías adecuados para probar siguiendo las pruebas de caja negra de particiones de equivalencia?
Tenemos 2 variables: a y b
Posibles casos por variable: valor negativo, valor positivo y 0
<head>
<script>
function suma(a,b) {
return a+b
}
</script>
</head>
9 20 6 8 12. Probablemente, al ir mejorando el diseño de nuestro código, podemos hacer menos número de casos de prueba Verdadero Falso. Probablemente, al ir mejorando el diseño de nuestro código, podemos hacer más número de casos de prueba Verdadero Falso. La función envio_gratis devuelve true cuando el importe de la compra es igual o superior al importe mínimo; false en otro caso.
¿Qué valores deberían probarse según los método de partición de equivalencia?
function envio_gratis( importe_compra
, minimo_envio_gratis) {
return importe_compra>=minimo_envio_gratis
} minimo_envio_gratis: <0, =0, >0
importe_compra: <minimo_envio_gratis, =minimo_envio_gratis, >minimo_envio_gratis minimo_envio_gratis: <importe_compra , =importe_compra, >importe_compra
importe_compra: <minimo_envio_gratis, =minimo_envio_gratis, >minimo_envio_gratis minimo_envio_gratis: -1, 0, 1
importe_compra: minimo_envio_gratis -1 , minimo_envio_gratis, > minimo_envio_gratis minimo_envio_gratis: <importe_compra , =importe_compra, >importe_compra
importe_compra: <0, =0, >0. La función envio_gratis devuelve true cuando el importe de la compra es igual o superior al importe mínimo; false en otro caso.
¿Qué valores deberían probarse según los método de valores límites para dicha función?
function envio_gratis( importe_compra
, minimo_envio_gratis) {
return importe_compra>=minimo_envio_gratis
} minimo_envio_gratis: importe_compra -1 , importe_compra, > importe_compra
importe_compra: -1, 0, 1 minimo_envio_gratis: -1, 0, 1
importe_compra: minimo_envio_gratis -1 , minimo_envio_gratis, > minimo_envio_gratis minimo_envio_gratis: <0, =0, >0
importe_compra: <minimo_envio_gratis, =minimo_envio_gratis, >minimo_envio_gratis minimo_envio_gratis: <importe_compra , =importe_compra, >importe_compra
importe_compra: <0, =0, >0. La función envio_gratis devuelve true cuando el importe de la compra es igual o superior al importe mínimo; false en otro caso.
¿Cuál es la correcta representación del método pruebas de equivalencia?
function envio_gratis( importe_compra
, minimo_envio_gratis) {
return importe_compra>=minimo_envio_gratis
} minimo_envio_gratis: <0, =0, >0
importe_compra: <minimo_envio_gratis, =minimo_envio_gratis, >minimo_envio_gratis minimo_envio_gratis: -1, 0, 1
importe_compra: minimo_envio_gratis <, minimo_envio_gratis, > minimo_envio_gratis . La función envio_gratis devuelve true cuando el importe de la compra es igual o superior al importe mínimo; false en otro caso.
¿Cuál es la correcta representación del método de los valores límite?
function envio_gratis( importe_compra
, minimo_envio_gratis) {
return importe_compra>=minimo_envio_gratis
} minimo_envio_gratis: <0, =0, >0
importe_compra: <minimo_envio_gratis, =minimo_envio_gratis, >minimo_envio_gratis minimo_envio_gratis: -1, 0, 1
importe_compra: minimo_envio_gratis -1 , minimo_envio_gratis, > minimo_envio_gratis . En las pruebas TDD existen dos métodos a la hora elegir los parámetros y test que hagamos Verdadero Falso. En los TDD usamos 2 métodos para elegir los test y sus valores Pruebas de caja negra y caja blanca Pruebas de caja negra y particiones de equivalencia Pruebas de unidad y de integración Valores límite y particiones de equivalencia . 1. Crear conjuntos para cada condición de entrada
2. Probar un representante de cada conjunto Clases de equivalencia Valores límite. Permiten probar la unidad en los valores cercanos a los últimos de un rango Clases de equivalencia Valores límite. ¿En qué fase del ciclo TDD se encuentra?
function get_a_number(num) {
}
describe("Obtiene un número", function() {
it("devolvería el cuadrado del número que se le pasa",
function() {
expect( get_a_number(8)).toEqual( 64 )
});
}); Roja Verde Refactor. ¿En qué fase del ciclo TDD se encuentra?
function get_a_second_number(num) {
if( num<10 || num>10 || num<=10 || num>=10) return 10;
if( num==10 || num>=10 ) return 10;
}
describe("Obtiene otro número", function() {
it("debería devolver el la raíz cuadrada de 100",
function() {
expect( get_a_second_number(-5)).toEqual( 10 )
expect( get_a_second_number(9)).toEqual( 10 )
expect( get_a_second_number(10)).toEqual( 10 )
expect( get_a_second_number(11)).toEqual( 10 )
expect( get_a_second_number(12)).toEqual( 10 )
});
}); Rojo Verde Refactor. Dado el siguiente código en Javascript, ¿cuál de las *DOS LINEAS DESTACADAS* es la que habríamos escrito primero si estuviéramos usando la metodología TDD? ¿Por qué?
<script>
function siempre_devuelve_false() {
*RETURN FALSE*
}
describe("Siempre devuelve false", function() {
it("debería devolver false",
function() {
*EXPECT( SIEMPRE_DEVUELVE_FALSE()).TOEQUAL(FALSE)*
});
});
</script>
RETURN FALSE EXPECT( SIEMPRE_DEVUELVE_FALSE()).TOEQUAL(FALSE) Da igual el orden de escritura . El ATDD o Acceptance TDD está pensado para proyectos individuales Verdadero Falso. El ATDD o Acceptance TDD está pensado para proyectos grupales Verdadero Falso.
