Cuadro Comp 1P + Agregados para final Flashcards
Timebox development
6
2
Kanban
Aplicar cuando
• Proyectos inestables. Domino/entorno caótico y complejo.
• La prioridad de los requerimientos cambia constantemente.
• Hay demasiado trabajo con poca productividad.
• Nos abrumamos de tareas.
• Perdemos el foco cambiando de tarea.
• Hay demasiado trabajo con poca productividad.
• Hay problemas de comunicación en el equipo provocando esfuerzos duplicados, defectos, retrabajos, etc.
Objetivo principal: Detectar cuellos de botella que representan estancamiento para avanzar. Evitar abrumación. Mejorar comunicación, evitando duplicación y retrabajo.
Scrum
- Proyecto donde hay mucha incertidumbre.
- Cuando tenemos un contexto complejo.
Lean
- Se basa en los principios de mejora continua.
- Objetivo: crear valor para satisfacer al cliente.
- En IT, se puede aplicar desde requerimientos hasta mantenimiento.
- Involucra el 100% de los colaboradores de IT.
Planning Poker
Ventajas Planning Poker (técnicas de estimación ágiles)
- Promueve la participación y la colaboración.
- Abstrae el concepto del tiempo, las estimaciones se hacen por puntos (medida proporcional a tareas simples).
- Aumenta el compromiso, si la historia del usuario entra en el sprint estamos comprometidos por participar en la estimación.
- No está bueno para proyectos sin historia porque no vas a tener con qué comparar.
- No es bueno para un proyecto corto.
- Sin un mínimo conocimiento es difícil estimar basado en puntos (estimar tamaño).
Wideband Delphi
“Wideband Delphi” es un método de estimación rudimentario, basado en el juicio experto en grupos.
Cada equipo dice porqué llegó al valor x (sin decir x), las razones de porqué llegó a esa estimación. La idea es que hay un moderador y después de rondas, se termina teniendo un x común. Se llega a un consenso entre varias personas.
- Para grupos grandes y que no se tenga mucha idea.
- Cuando no haya experiencia previa.
- Cuando no haya datos históricos en este tipo de estimaciones.
- Es fácil de implementar.
- Se puede utilizar en etapas tempranas del proyecto.
Function Points
- Los Function Points miden el tamaño del SW en base a la funcionalidad capturada en los requerimientos.
- El método “Puntos por Función” da como salida puntos de función que luego deben ser convertidas a Lines of Code (LOC).
- El método Function Points se lo puede ajustar a través de factores de ajustes, pero no son distintos métodos sino que es el mismo método ajustado.
- Requiere un análisis de requerimientos avanzados.
- No se puede utilizar en una etapa temprana de análisis.
- Es independiente a las tecnologías a utilizar.
- Busca no invertir el tiempo desmedidamente.
- Es difícil de aprender y perfeccionar.
Object Points
- El Objects Points considera como factor de ajuste el porcentaje de reutilización de código.
- OPs son muy adecuados para estimar proyectos de mantenimiento de SW porque tiene en cuenta la reusabilidad del código, entre otros.
- Estima esfuerzo.
- A diferencia de FP se puede utilizar en una etapa temprana del análisis.
- Carece de una tabla de ajustes técnicos o de entorno.
Métricas de Testing
- Productividad Diseño - que capacidad tiene mi tester de crear condiciones por unidad de tiempo , sirve cuando hay que hacer alguna estimación
Ej.: Condiciones Construidas x Unid. Tiempo” - Productividad Ejecución . cuántos casos puede ejecutar por unidad de tiempo (sirve para ver si es susceptible de automatización o no)
Ej.: Casos Ejecutados x Unid. Tiempo - Eficacia (Pre Release) - cuantos incidentes de los que reporte fueron finalmente son aceptados y declarados como defecto (que NO sean falsos positivos)
Ej.: ( Incidentes Reportados Aceptados / Total Incidentes Reportados x 100 )
Es interesante medir también la eficacia en la resolución de defectos - Eficacia (Post Release) - cuantas de las fallas son relevantes
Ej.: [ Fallas Reportadas / (Fallas Reportados + Fallas Rep. User ]x 100 - “Calidad” del Desarrollo
Ej.: Índice de Severidad por Defectos Reportados - Release Readiness - cuan listo estoy para salir a producción
Ej.: Índice de Severidad por Defectos Abiertos.
Definición de Incidente de Testing.
- Toda ocurrencia de un evento que sucede durante la ejecución de una prueba de software que requiere investigación.
- Todo lo que termina reportando el tester termina reportando al equipo de desarrollo para que sea revisado y trate de encontrar el DEFECTO- lo que origina la falla- (y de confirmarlo, se convierte en una falla).
- No toda incidencia es una falla.
- Cuando el resultado esperado es distinto al obtenido.
Ejemplos: Defectos en los casos/ Equivocaciones al ejecutar las pruebas/Interpretaciones erróneas/Dudas
Definición de Equivocación.
- Acción humana que produce un resultado incorrecto, origen del defecto.
- 1 equivocacion => 1 o + defectos presentes en el código.
Definición de Defecto.
- Paso, proceso o definición de dato incorrecto.
- Ausencia de cierta característica.
- No solo estan en el código, en tablas de datos, etc.
- El tester ve la manifestación del defecto y lo reporta, el desarrollador debe buscar el defecto
- Es lo que genera fallas.
- 1 defecto => 0 o + fallas.
Ejemplo- olvidarse de validar algo en un campo de input.
todo new: chequear que no haya otra def mas linda
Definición de Falla.
- Resultado de ejecución incorrecto. Es el producido por el SW. Es cuando el resultado obtenido es distinto al resultado esperado.
- 1 falla tiene que ver con 1 o + defectos.
Definición de Condiciones de prueba.
- Son descripciones de situaciones que quieren probarse ante las que el sistema debe responder.
- Crear condiciones es un proceso “creativo”.
Definición de Partición - clases de equivalencia.
- Todos los posibles casos de prueba los dividimos en clases
- La identificación de clases de equivalencia se hace dividiendo cada condición de entrada en dos tipos de grupos: clases válidas y clases inválidas
- Todos los casos de una clase son equivalentes entre sí - Detectan los mismos defectos
- Con solo ejemplos de cada clase cubrimos todas las pruebas
- El éxito está en la selección de la partición !!!
Definición de Depuración.
- Depurar es eliminar un defecto que posee el SW.
- La depuración NO es una tarea de prueba aunque es consecuencia de ella.
- La prueba detecta el falla (efecto) de un defecto (causa).
La depuración puede ser fuente de introducción de nuevos defectos.
Hasta cuando probar.
PROBAR en definitiva es el proceso de establecer confianza en que un SW hace lo que se supone que tiene que hacer.
Y ya que nunca se va a poder demostrar que un SW es correcto, continuar probando es una decisión económica.
Cómo abarato el testing/pruebas.
La forma de abaratarlas y acelerarlas sin degradar su utilidad es: DISEÑANDO EL SW PARA SER TESTEADO Algunas herramientas son: - Diseño Modular - Ocultamiento de Información. - Uso de Puntos de Control. - Programación NO egoísta.
Kanban - Limitar el WIP.
Limitar el WIP: Consiste en acordar la cantidad de ítems que pueden trabajarse en paralelo por cada etapa del proceso.
El principal objetivo es detectar cuellos de botella que representan estancamiento/bloqueos para avanzar.
La práctica de limitar el WIP es lo que marca la diferencia entre tener una “lista visual de to-do” y el tener un sistema Kanban.
Exploratory testing
- Es “unscripted”
• Todas las condiciones y casos no son diseñados y documentados previamente para ser ejecutados.
• El tester va decidiendo tácticamente qué es lo mejor en c/paso de acuerdo al conocimiento que va adquiriendo de la ejecución de un test. - El tester es responsable en todo momento de la decisión del camino a tomar.
– “Unscripted” no significa “sin preparación”.
Cuándo es apropiado el ET?
– Se necesita conocer el producto rápidamente.
– Se demanda feedback en poco tiempo.
– Se ejecutó “scripted testing” y se quiere diversificar la prueba.
– Se pretende chequear el testing realizado por un tercero a través de una breve prueba independiente.
– Hay que atacar un riesgo en particular.
– Hay que buscar un bug puntual previamente reportado.
Cuatro etapas básicas:
- Reconocimiento & Aprendizaje.
- Diseño.
- Ejecución.
- Interpretación.
Conclusión
- ET es una forma de encarar el testing.
- ET es dependiente del tester.
- ET es dependiente del conocimiento que se va obteniendo a medida que se ejecuta la prueba.
- No se trata de “script based testing” vs “unscripted based testing”.
Script driven
– Se confeccionan las condiciones & casos tempranamente para luego ser ejecutados.
• Por lo general, la actividad de creación de condiciones está destinada a profesionales con mas skill.
• La ejecución y reporte está asignada a personas con menor skill (más operativas).
– Muchas veces, en cada ciclo de prueba se vuelven a repetir las condiciones y casos y no se retroalimentan.
• C/ciclo “mira lo mismo”.
Ventajas – Puede ser objeto de revisión entre pares. • Otros Testers. • Usuarios finales. – Puede ser reusado para una nueva ejecución fácilmente. – Puede ser medible • # de condiciones. • # de casos.
Desventajas
– Laborioso.
– La etapa mas creativa se da en el diseño de las condiciones y casos y no en la etapa de ejecución.
Unscripted Testing
– Se confeccionan las condiciones & casos a medida que se aprende de las distintas ejecuciones, refocalizando las pruebas si fuera necesario (obteniendo ventajas de lo aprendido).
– Las nuevas ideas ocurren “on the fly”.
Ventajas
– Se pueden variar los test sobre la marcha de acuerdo a lo que se considere más apropiado.
• El trabajo creativo se hace durante la ejecución (no antes).
– Permite mayor cobertura de situaciones sobre posibilidades difíciles de anticipar.
Desventajas
– Puede perderse la capacidad de “reproducir” sino se sigue un órden (plan o charter) a la hora de probar.
• El “plan” no significa “script”.
– Muy dependiente de las personas.
• Creatividad / Memoria / Intuición.
• Algunos pueden ser expertos en el dominio del negocio (“subject matter experts”), otros en la plataforma tecnológica que soporta la solución, otros pueden conocer el producto con anterioridad, etc …
• ¿Está mal?
TODO NEW: Se contradice con lo que dice laotra carta??
Continuous Delivery
Asociado Integración Continua (CI), Continuous Delivery es un conjunto de prácticas que permiten asegurar que el software puede desplegado en producción rápidamente y en cualquier momento.
Esto lo logra haciendo que cada cambio llegue a un entorno de staging o semi productivo, donde se corren exhaustivas pruebas de sistema. Luego se puede pasar a producción manualmente cuando alguien apruebe el cambio con solo apretar un botón.
TODO: Mepa que había un MC que servía mejor para estudiar
continuous deployment
El continuous deployment es el paso siguiente al continuous Delivery, en donde también el despliegue a producción se realiza en forma automática por un proceso y no por personas.
