Changing the way you learn

Tester | N1 | L2

1 - Principios de las pruebas
1. Para simplificar el proceso de pruebas de software
  1. Principio 1 - Sirven para demostrar si existen defectos en el software
  2. Principio 2 - No es posible realizar una prueba que cubra todas las variables y las necesidades del cliente
  3. Principio 3 - Se realizan al principio del ciclo de vida de los productos
  4. Principio 4 - Agrupalas por tipo para revisar el software
    1. Para detectar el mismo tipo de defecto para más rápido
  5. Principio 5 - Deben actualizarse periodicamente para detectar nuevos errores
  6. Principio 6 - Se efectúan dependiendo del funcionamiento del software
    1. Comprobar la seguridad en una aplicación bancaria que en una donde se compran boletos por internet
  7. 7 - El producto final debe de cumplir con las espectativas del usuario
2 - Proceso de pruebas
1. Planificación y control
  1. Planificación de pruebas
    1. Definición de los objetivos y cumplir metas establecidas
      1. Identificar defectos
      2. Aumentar la calidad del software
      3. Facilitar la información para la toma de decisiones
      4. Evitar la aparición de defectos
2. Análisis y diseño de pruebas
  1. Transforma los objetivos en tareas que debemos hacer
    1. Revisar la base de pruebas, requisitos e informes de análisis de riesgos
    2. Identificar y dar prioridad a las condiciones de la prueba con base a los análisis de los elementos, la especificación, el comportamiento y la estructura del sistema
    3. Diseñar y ordenar los casos de prueba
    4. Identificar los datos de prueba
    5. Diseñar la configuración del entorno de las pruebas
3. Ejecución
  1. Actividad donde se especifican los procedimientos
    1. Verificar que el entorno de las pruebas haya sido debidamente configurado
    2. Implementar los casos de prueba
    3. registrar los resultados de la ejecución
4. Evaluación de los criterios de salida
  1. Actividad que compara la ejecución de las pruebas contra los objetivos definidos
    1. Comprobar los resultados con los valores previstos en la planificación de la prueba
    2. Evaluar si se requieren más pruebas
    3. Elaborar un resumen de las pruebas para tu equipo de trabajo y tu cliente
5. Actividades de cierre
  1. Se recopilan los datos de las pruebas terminadas
    1. Comprobar qué documentos han sido entregados
    2. Cerrar los informes de incidencia
    3. Documentar cuántos usuarios aceptaron el sistema
    4. Archivar los productos de soporte, entorno y la infraestructura para usarlos en futuras pruebas
    5. Utilizar la información recopilada
      1. Para mejorar la madurez de las pruebas
3 - Modelos de prueba
1. Contiene la forma en la que puedes aplicar los diferentes tipos de pruebas
  1. Modelo V
    1. Desarrollo secuencial
      1. Nivel 1 - Pruebas de componente
        Localizar los defectos y probar el funcionamiento de los módulos del software de forma neutral
        Enfocadas en los requisitos de los componentes
        Ejemplo
        Módulo: Inicio de sesión
        Cómo reacciona el sistema cuando se ingresan datos correctos, incorrectos y cuando el campo está vacío
        Módulo: Saldo pendiente
        Módulo: Pagos y recargas
        Módulo: Historial de llamadas
      2. Nivel 2 . Pruebas de integración
        Se hacen en base a la arquitectura del sistema o a las tareas funcionales
        Consisten en checar el flujo de información entre los módulos
        Verificar el funcionamiento entre la interfaz y sus componentes
      3. Nivel 3 - Pruebas de sistema
        Sirven para revisar el funcionamiento de un software en su totalidad
        Su objetivo es que el software cumplan con los requisitos funcionales y no funcionales para minimizar la posibilidad de errores
      4. Nivel 4 - Pruebas de aceptación
        El cliente determina si el sistema tiene éxito
        Confirma si es confiable en su uso y su comportamiento
      5. Este modelo podría componerse de más niveles
  2. Modelo de desarrollo iterativo - Incremental
    1. Proceso que forma un grupo de tareas
      1. Pertenecen a una pequeña parte del sistema y sirven para probarlo
    2. Las iteraciones son el número de veces que realizas una prueba modificando algunas condiciones
      1. Cada tarea debes realizarla las veces que sean necesario
        Así comprobarás la funcionalidad de cada una de sus partes
    3. Es incremetnal porque no se puede pasar a la siguiente prueba sin haber terminado la anterior
  3. Existen más modelos de prueba que se pueden adaptar al proyecto o a la arquitectura del sistema
4 - Clasificación de pruebas
1. Pruebas funcionales
  1. Pueden aplicarse en cualquier NIVEL del proceso
    1. Verifican que cada función del software opere en base a sus especificaciones
    2. Validar tanto sus funciones principales como las de uso básico
2. Pruebas no funcionales
  1. Pueden aplicarse en cualquier NIVEL del proceso
    1. Deben realizarse después de las funcionales
      1. Su objetivo es checar que el software funciona bien
        Fiabildiad
        Probabilidad de que un sistema, aparato o dispositivo cumpla una determinada función bajo ciertas condiciones durante un tiempo determinado.
        Rendimiento
        Es la cantidad de trabajo realizado por un sistema informático.
        Ejmeplo:
        Tiempo de respuesta corto para una determinada pieza de trabajo.
3. Pruebas de caja blanca
  1. Pruebas de estructura
    1. Basadas en el código interno del software
      1. Verifica los siguientes puntos
        Fallas en la seguridad interna
        Trayectorias mal estructuradas o rotas en los procesos de codificación
        El flujo de los valores de entrada a través del código y los resultados esperados
        La funcionalidad de los bucles condicionales
      2. Con el objetivo de fortalecer
        La seguridad
        Mejorar el diseño
        Usabilidad de los los sistemas
    2. Verificar el conjunto de caminos independientes y confeccionar casos de prueba que garanticen que se verifican dichos caminos de ejecución
      1. El camino independiente es que introduce por lo menos una nueva secuencia (arista en el grafo de flujo) que no estaba considerada en el conjunto de caminos independientes ya calculados
4. Pruebas de caja negra
  1. Verifican la funcionalidad del software
  2. SIN examinar la estructura del código interno
  3. Pasos
    1. Reconoce los requerimientos y especificaciones del software que probarás
    2. Escoger los valores de entrada que son válidos e inválidos
    3. Determina cuáles son las respuestas esperadas para cada uno de los valores elegidos
    4. Construye casos de prueba para los valores de entrada y ejecutalos
    5. Compara las respuestas obtenidas con las esperadas y determinar si hay errores
  4. Probar la funcionalidad del módulo sin disponer el código fuente
    1. Intentar encontrar errores de ESTRUCTURAS de datos, INICIALIZACIÓN Y FINALIZACIÓN, RENDIMIENTO, interfaces E/S
    2. En base a los parámetros de entrada y los resultados esperados de salida
    3. Técnica de partición equivalente
      1. Consiste en derivar casos de prueba mediante la división del dominio de entrada en clases de equivalencia, evaluando su comportamiento para un valor cualquiera representativo de dicha clase
        Una clase de equivalencia representa al conjunto de estados válidos o inválidos para todas las condiciones de entrada que satisfagan dicha clase
        Annotations:
        Heurístico: Técnica diseñada para resolver un problema más rápidamente cuando los métodos clásicos son demasiado lentos, o para encontrar una solución aproximada cuando los métodos clásicos no logran encontrar una solución exacta. Esto se logra intercambiando la optimización, la integridad, la precisión o la precisión por velocidad. En cierto modo, puede considerarse un atajo.
5. Repetición de pruebas y pruebas de regresión
  1. Se ejecutan para confirmar que los cambios hechos en el código no han afectado otras funciones
    1. Estas variantes pueden incluir corrección de fallas
    2. Cambios en el código
    3. Nuevas características del software
  2. Es necesario repetir una prueba para que un defecto ha sido corregido
5 - Métricas y mediciones
1. Métrica
  1. Al conjunto de mediciones de un software
  2. Con la finalidad de tener una idea clara sobre el estado actual del producto y si existe una mejora en la corrección de errores
  3. Tipos
    1. Métricas de tamaño
      1. Sirven para determinar la longitud del sw
        Contando las líneas del código que lo forman
    2. Métricas de calidad
      1. Número de defectos encontrados en el producto
    3. Métricas de seguridad
      1. Para determinar si el sistema podrá resistir a ataques de acceso no autorizado
  4. Definir métricas
    1. 1 - Definir un número limitado de métricas que sean útiles
      1. Para evitar problemas de intepretación
    2. 2 - Se definen por metas
      1. Para un proceso
      2. Una tarea
      3. Un componente
      4. Un sistema
    3. 3 - Seguimiento y recopilación de métricas
      1. Debe estar automatizado para reducir los tiempos de medición
    4. 4 - El uso de métricas te permitirá comunicar a tu cliente y a tu equipo de trabajo información importante

Next up

Tester | N1 | L2

Description

Resource summary

Media attachments

Similar

	Created by Rodrigo Charnichart about 4 years ago