Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

CLASE #3 II SEMESTRE 2017

No description
by

Marlen Villalobos

on 7 August 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of CLASE #3 II SEMESTRE 2017

Actividades de
Verificación y Validación

Principios de las pruebas
Código de ética de las pruebas
Verificación y Validación
Psicología de las pruebas
Pruebas de Software
Definición
La
validación y la verificación
son
procesos de evaluación de productos
que son
útiles para determinar si se satisfacen las necesidades del negocio y si se están construyendo acorde a las especificaciones.
Verificación
Busca comprobar que
el software está de acuerdo con su especificación
. Debería comprobarse que satisface sus requisitos funcionales y no funcionales.
Demostrar la consistencia, la completitud y la corrección de los
artefactos
de las distintas fases (productos intermedios).
La verificación es una
actividad desarrollada por ingenieros
teniendo en cuenta un modelo del programa y el programa en sí.
¿Se está construyendo el producto de la manera correcta?
¿Qué haga lo correcto?
Validación
Busca
asegurar que el sistema satisface las expectativas del cliente
.

Determinar la corrección del
producto final
respecto a las necesidades del usuario.
Debe realizarla el
usuario
teniendo en cuenta lo que él espera del programa y el programa en sí.
¿El software cumple las expectativas del cliente?
¿Se está construyendo el producto correcto?
¿Qué sea lo correcto?
Verificación y Validación en el Ciclo de Vida
Modelo en Cascada
Modelo V
Modelo Incremental
Modelo de prototipos
XP
SCRUM
Ordena las etapas
del ciclo de vida, de forma que
el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.
Las pruebas se realizan al final
del ciclo de vida del proyecto por lo que
los defectos son detectados cerca de la fecha de implementación
del producto o sistema, lo que supone un
coste muy elevado en la corrección de defectos.
Solventa algunos problemas que ocurrían usando el enfoque propuesto por el modelo de cascada.
Proporciona guías para comenzar con la realización de pruebas tan pronto como sea posible en el ciclo de vida del producto.
Integra las actividades de prueba (verificación y validación) en cada fase del ciclo de vida
La parte izquierda de la V representa la corriente donde se definen las especificaciones del sistema.

La parte derecha de la V representa la corriente donde se comprueba el sistema
(contra las especificaciones definidas en la parte izquierda).
La parte de abajo, donde se encuentran ambas partes, representa la corriente de desarrollo.
Se construye el producto incrementando las funcionalidades del programa con cada incremento
Las funcionalidades pueden probarse a medida que se van añadiendo al sistema, por lo que no tiene que realizarse una implementación completa del producto para que comiencen las pruebas.
Comienza con la
recolección de requisitos
.
Se
construye un prototipo
que es evaluado por el cliente y se utiliza para
refinar los requisitos
.
Está muy presente tanto la validación como la verificación, ya que el desarrollador tiene muy en cuenta la opinión del cliente con el objetivo de conseguir cubrir sus necesidades, realizando revisiones de manera periódica para conseguir un producto final que cumpla los requisitos especificados.
Diseño y codificación:se propone trabajar de manera que tanto el diseño como la arquitectura se creen de forma incremental.
Probar: Se utilizan las pruebas para probar el funcionamiento del código y para validar la correcta implementación de los requisitos del cliente.
Escuchar: Escuchar al cliente para entender sus necesidades e implementar un software adecuado a su negocio.
Pilares
Transparencia
Se conoce claramente el avance del proyecto porque el equipo se comunica constantemente entre sí para identificar dependencias y temas técnicos
El cliente prueba la funcionalidad que pidió cada dos semanas
Adaptación
Reuniones diarias
: Adaptación diaria del proceso, producto y proyecto.
Cambios en los requerimientos
: Permitir realizar cambios necesarios que beneficien al negocio y que impacten la visión del producto.
Reuniones de Retrospectiva del Sprint
: El mejorar constantemente el proceso sprint tras sprint, es parte importante de la adaptación necesaria para ser más exitosos.
Identificación de Riesgos
: incentiva la adaptación del proyecto, producto y del proceso.
Inspección
Los usuarios de Scrum deben inspeccionar con frecuencia los Artefactos y el progreso hacia los objetivos del Sprint para detectar variaciones no deseadas.
Proceso que consiste en todas las actividades del ciclo de vida, tanto estático como dinámico, que tiene que ver con planificación, preparación y evaluación de productos de software y productos relacionados al trabajo para determinar que satisfagan los requisitos especificados, para demostrar que son aptos para el propósito y para detectar defectos.

(RBCS)
La prueba (testing) es el proceso de ejecutar un programa con la intención de encontrar fallos.

(Glenford J. Myers)
Una investigación técnica del producto bajo prueba para proporcionar a los interesados (stakeholders) información relacionada con la calidad

(Cem Kaner)
Definición
Objetivos
Encontrar defectos y proporcionar a los programadores con la información que ellos necesitan para corregir defectos importantes
Ganar confianza acerca del nivel de calidad del sistema
Prevenir defectos (a través de la participación temprana en las revisiones y el diseño anticipado de las pruebas)
Proporcionar la información acerca de los aspectos más importantes de la calidad del sistema sometido a prueba
Ayudar a la gerencia a comprender la calidad del sistema
Proceso
de pruebas
Productos
Relación de componentes del sistema de pruebas
Las pruebas de software se integran dentro de las diferentes fases del ciclo del software
Puede considerarse como un subproyecto dentro del proyecto sobre el cual se están ejecutando las pruebas
Tras la superación de todas las actividades del proceso de pruebas del software se dispondrá de las siguientes salidas:
Elementos de prueba
, con distintos scripts, programas de prueba, datos de prueba,..., desarrollados para la ejecución y reproducción de las pruebas.
Producto probado
y listo para su implantación.
Planes de prueba
con los casos de prueba identificados.
Informes de pruebas
, con los resultados obtenidos de las pruebas, los errores detectados, las acciones llevadas a cabo para su corrección y la evidencia final de superación de todas las pruebas.
Pruebas
Caso de prueba
"Un caso de prueba es un conjunto de entradas, condiciones de ejecución y resultados esperados, desarrollado para conseguir un objetivo particular o condición de prueba".
"Un caso de prueba es un proceso detallado que busca probar una funcionalidad o requerimiento particular, parcial o totalmente"
"Un buen caso de prueba tiene una alta probabilidad de encontrar defectos".
Ciclo de vida
Concepto
Objetivos
Establecer la participación de los
roles
implicados.
Definir el
alcance, momento y características de las diferentes pruebas
a realizar.
Definir los
contenidos de los manuales
de usuario y de administración.
Establecer los
requisitos necesarios para la aceptación del producto
antes de su promoción a la siguiente fase del ciclo de vida de desarrollo.
Definir el
ciclo de vida de gestión de un caso de prueba.
Establecer los
mecanismos de resolución
de casos fallidos producidos en las pruebas del software.
Presentar
técnicas y estrategias aplicables en la elaboración y ejecución de las pruebas del software.
Plan de pruebas
El plan de pruebas es un documento que describe el alcance, enfoque, recursos y planificación de las actividades de prueba.

Mediante la creación y uso de planes de pruebas se va a definir:
La
forma
en la que las pruebas se van a realizar
El
nivel de cobertura
del ciclo de pruebas a ejecutar
Diferentes
estrategias
a seguir según el estado en el que se encuentre el producto a probar
Informe de pruebas
Son documentos que recogen información del tipo: objetivo y alcance de las pruebas, resultados obtenidos durante la realización de pruebas, evaluaciones de los elementos de pruebas respecto a sus correspondientes criterios de salida, resultado final de las pruebas
Sistema de pruebas
Las pruebas forman parte de lo que se denomina sistema de pruebas.
Equipo de pruebas
Los ingenieros de pruebas, técnicos de pruebas y el responsable de las pruebas, los cuales tienen habilidades, experiencia y trabajan para diseñar, implementar, y usar componentes de pruebas.
Recursos de pruebas
Casos de prueba, datos de prueba, herramientas de pruebas, y otro material de desarrollo.
Procesos de prueba
Condiciones informales, formales, no documentadas y
documentadas en las que se realiza el trabajo de pruebas.
Entorno de pruebas
Hardware, software, infraestructura de redes, oficina y laboratorio, y otros elementos que formen el lugar de trabajo.
El sistema de pruebas debe ser
funcional
. Debería cubrir los riesgos de calidad críticos.
El sistema de pruebas debe ser
fiable
. Cuando se ejecuta la misma prueba sobre el mismo sistema bajo pruebas, deberían obtenerse los mismos resultados.
El sistema de pruebas debe ser
robusto
. Cambios pequeños y errores menores en el entorno de prueba no deberían causar mayores fallos en las pruebas.
Un sistema de pruebas debe ser
útil
para todos aquellos que quieran usarlo. La curva de aprendizaje del sistema de pruebas debería ser corta para personal calificado.
Un sistema de pruebas debe ser
eficiente
. La ejecución de pruebas debería ser rápida.
Un sistema de pruebas debe ser
portable
, es decir, debería permitir a los técnicos de prueba ejecutar pruebas en cualquier plataforma.
Características
Las pruebas revelan la presencia de defectos
La imposibilidad de pruebas exhaustivas
Los caminos de ejecución en un software no-trivial son casi infinitos
Hay grandes flujos de datos separados en el espacio (características) y el tiempo (datos estáticos)
Pequeños cambios pueden provocar regresiones las cuales no son lineales al tamaño del cambio
Perfiles de uso y campos de configuración variados, algunos desconocidos y algunos imposibles de conocer
Los beneficios de las pruebas tempranas
El costo de un defecto
tiende a aumentar a medida que el proyecto continúa
La mayor parte de los costos asociados con defectos de una pre-versión tienden a ser asociados con el esfuerzo necesario para eliminarlos, por lo que
costos más altos significan cronogramas más largos
Mientras más defectos entran en una actividad de QA o de pruebas,
más defectos se escaparán de esa actividad
La aglomeración de defectos: La agrupación de defectos
Los estudios han demostrado por largo tiempo y continúan mostrando la
distribución desigual de los defectos
MVS (Sistema Operativo Multiple Virtual Storage): 38% de defectos de campo en el 4% de los módulos
IMS (IBM Information Management System): 57% de defectos de campo en el 7% de los módulos
Capers Jones reporta que la
presencia excesiva de módulos propensos a errores causa una reducción del 50% de la productividad en el mantenimiento de software
Regla de pareto: 20/80
La paradoja del pesticida
Regrese a su huerta
Usted rocía un pesticida en su huerta, y los gusanos picudos mueren, pero el pesticida no es eficaz contra todos los insectos
Así como los pesticidas se vuelven menos eficaces, también lo hacen las pruebas
Las pruebas funcionales no pueden encontrar defectos de rendimiento
Intente nuevas técnicas de pruebas, si el objetivos es encontrar defectos
Las pruebas deberían adaptarse a necesidades específicas
Encontrar y corregir muchos errores no garantiza la satisfacción del usuario, del cliente y/o de los interesados del negocio
Muchos productos con pocos defectos han fracasado en el mercado
Los proyectos exitosos equilibran fuerzas que compiten en términos de características, cronograma, presupuesto y calidad.
“El testing puede probar la presencia de errores pero no la ausencia de ellos”
Edsger Dijkstra
La falacia de la ausencia de errores
Una metáfora
Usted tiene una huerta hermosa, pero un día ve hojas comidas sobre los tomates
“Oh no”, piensa usted, “!Gusanos Picudos¡”
Usted sabe que tiene insectos en su jardín
¿Si no hubiera visto los síntomas, podría estar seguro de no tuviera insectos?
Algunos insectos son fáciles de detectar, otro no
Las pruebas revelan la presencia de defectos, pero no pueden probar su ausencia
Atributos de un buen probador
Curiosidad
Ojo crítico (Constructivista)
Atención al detalle
Buenas habilidades de comunicación
La mezcla adecuada de las habilidades es necesaria
Habilidades
Lectura
: especificaciones, correos electrónicos, casos de prueba, etc
Escritura
: casos de prueba, informes de defectos, documentación de pruebas, etc
Habilidades en tecnologías, proyectos y pruebas
Tecnología: lenguajes de programación, sistemas operativos, redes, Internet, dispositivos móviles, etc
Dominio de la aplicación
: banca, oficina, salud, etc
Pruebas
: construcción de guiones, exploración y el ataque del sistema, automatización, modelado de rendimiento, etc.
¿Constructor o destructor?
A veces se percibe que el probador critica el producto o al autor
Se visualiza a las pruebas como una actividad destructiva
El probador debe comunicar de forma constructiva acerca de los defectos
QA vs Testing
Cliente y Empleador
Los probadores deberían actuar de una manera que es en el
mejor interés de su cliente y empleador
, compatible con el interés público
Producto
Los probadores deberían asegurar que los entregables que ellos proporcionan cumplan con los estándares más altos posibles
Juicio
Los probadores de software
deberían mantener la integridad e independencia en su juicio profesional
Profesión
Los probadores deben
promover la integridad y reputación de su profesión
Colegas
Los probadores deben ser justos con sus colegas y de gran ayuda para ellos; así como
promover la cooperación con los desarrolladores de software
Ética según el ISTQB
La ética es una serie de reglas de conducta reconocidas con respecto a una clase particular de acciones humanas o un grupo en particular, una cultura, etc
Hay que recordar que los probadores tienen acceso a información confidencial y privilegiada, las guías éticas les ayudan a utilizar dicha información adecuadamente
Uno mismo
Los probadores deben participar en el aprendizaje permanente con relación a la práctica de su profesión y
promover un método ético para la práctica de su profesión
Público
Los probadores de software deberían actuar coherentemente con el interés público
¿Cuáles son las principales diferencias entre validación y verificación?
¿Cómo aplicarías la verificación y validación en tus procesos?
Full transcript