Class Notes
Pruebas Funcionales | Pruebas de aceptación
Logros de esta semana:
Al término de la sesión los estudiantes podrán analizar los conceptos necesarios sobre
niveles y
tipos de pruebas, comprendiendo conceptos de pruebas funcionales y de aceptación,
basado en
un entorno tradicional y ágil y aplicando dicho análisis de manera lógica en un caso
práctico
1. Niveles de prueba
2. Tipos de prueba
3. Pruebas de aceptación
4. Pruebas Funcionales
5. Herramientas de apoyo
[Link]
Pruebas de Software (Testing de Software) - Entrevista a Javier Marchese
La cita de Donald E. Knuth dice:
"Tenemos que cambiar la tradicional actitud ante la construcción de software. En vez de
pensar que nuestra principal tarea es indicar a un ordenador qué hacer, concentrémonos
en explicar a las personas lo que queremos que el ordenador haga".
Explicación
Donald Knuth, un reconocido científico de la computación, está sugiriendo un cambio de
enfoque en cómo se aborda el desarrollo de software.
1. Cambio de Actitud Tradicional:
• Tradicionalmente, los desarrolladores de software se enfocan en decirle a la
computadora exactamente qué hacer. Esto se refiere a escribir código detallado y
específico que dicta cada acción del ordenador.
2. Enfoque en la Comunicación:
• Knuth sugiere que, en lugar de concentrarnos únicamente en la programación
detallada, deberíamos poner más énfasis en comunicar claramente nuestras
intenciones y objetivos a otras personas (como usuarios, clientes, y otros
desarrolladores).
3. Claridad en las Intenciones:
• Al explicar claramente lo que queremos que haga el ordenador, mejoramos la
comprensión y la colaboración entre los involucrados en el proyecto. Esto puede llevar
a una mejor alineación con las necesidades del usuario y a un software más efectivo y
fácil de mantener.
4. Beneficios:
• Este enfoque puede facilitar el proceso de desarrollo, hacer que el software sea más
intuitivo y asegurarse de que cumple con las expectativas y requisitos de los usuarios.
También puede ayudar a identificar problemas y soluciones más rápidamente, ya que
todos los involucrados comprenden claramente los objetivos del software.
Resumen
En resumen, Knuth está abogando por una mayor comunicación y colaboración en el
desarrollo de software. En lugar de centrarse solo en cómo decirle a la computadora qué
hacer, los desarrolladores deben asegurarse de que todos entiendan claramente lo que se
quiere lograr con el software, lo que puede llevar a mejores resultados y a un desarrollo
más efectivo y eficiente.
NIVELES Y TIPOS DE PRUEBAS DE SOFTWARE
Recuerda que un nivel de prueba es un grupo de actividades de prueba que se organizan y
gestionan en conjunto.
También se requiere un entorno adecuado para cada nivel de prueba, por ejemplo, en las
pruebas de aceptación se requiere un entorno similar al de producción, mientras que en la
prueba de componente los desarrolladores suelen usar su propio entorno de desarrollo.
NIVELES DE PRUEBAS DE SOFTWARE
También conocida como prueba unitaria o de módulo, incluso prueba del desarrollador.
• Tiene como foco centrarse en componentes que se pueden probar por separado.
• Comúnmente se realiza de manera aislada del resto del sistema.
• Este nivel de prueba puede incluir tipos de prueba diversos, por ejemplo funcionales
(exactitud en los cálculos), o no funcionales búsqueda de fugas de memoria.
• La responsabilidad de este tipo de prueba generalmente es la del desarrollador que la
escribió.
• En marcos ágiles se puede considerar TDD (desarrollo guiado por pruebas) en este nivel.
PRUEBAS DE INTEGRACIÓN:
• Tiene como foco centrarse en las interacciones entre componentes o sistemas.
(Se prueban grupos de componentes).
• Uno de sus objetivos más destacados es la reducción del riesgo, y generar
confianza en la calidad de las interfaces y prevenir la propagación de defectos a
niveles superiores de prueba.
• Este nivel de prueba puede incluir diferentes tipos de pruebas.
• Este nivel de prueba se puede dividir en 2 tipos:
Prueba de integración de componentes. En agilidad se automatiza y este
suele formar parte del proceso de integración continua.
Prueba de integración de sistemas se centran en la interacción de
interfaces. Se puede implementar a nivel subsistemas si se tiene un
grupo de los mismos.
• En marcos ágiles se puede considerar BDD (desarrollo guiado por
comportamientos) en este nivel.
PRUEBAS DE SISTEMA
• Tiene como foco centrarse en el comportamiento y capacidades de todo un sistema o
producto.
• Uno de sus objetivos más resaltantes es la reducción del riesgo, y
• generar confianza en la calidad de las interfaces y prevenir la propagación de defectos
a niveles superiores de prueba o producción.
• Este nivel de prueba puede incluir diferentes tipos de pruebas.
• La responsabilidad de este nivel es dada a los probadores o testers.
• Pueden incluir pruebas basadas en los riesgos y/o especificaciones sobre los
requerimientos, procesos de negocio, casos de uso, u otras descripciones de alto nivel
del comportamiento del sistema, las interacciones con el sistema operativo y los
recursos del sistema.
PRUEBAS DE ACEPTACIÓN
• Tiene como foco la igualdad, que el nivel de sistema se centre en el comportamiento y
capacidades de todo un sistema o producto.
• Los objetivos más resaltantes son establecer confianza en la calidad de los sistemas en su
conjunto, validar que el sistema esté completo y funcione como se esperaba.
• Este nivel de prueba produce información para evaluar el grado de preparación del
sistema para su despliegue y uso por parte del usuario final.
• Las responsabilidades de este nivel son dadas a los clientes, PO, usuarios finales,
operadores, etc.
• En agilidad, este nivel de prueba se podría dar al final del sprint.
TIPOS DE PRUEBAS DE SOFTWARE
Los tipos de prueba son actividades destinadas a probar características específicas de un
sistema de software, o de una parte de un sistema, basado en objetivos de prueba
específicos.
Dichos objetivos deben incluir:
1. Evaluar características de calidad funcional (corrección, pertinencia).
2. Evaluar características no funcionales (eficiencia en el desempeño, seguridad,
usabilidad).
3. Evaluar si la estructura del componente o sistema es correcta, completa y según lo
especificado.
4. Evaluar los efectos de los cambios, tales como confirmar que los defectos han sido
corregidos (pruebas de confirmación), y buscar cambios no deseados en el
comportamiento.
PRUEBAS FUNCIONALES
Entre el tipo de pruebas que se realiza en un sistema está el tipo que evalúa la
funcionalidad de éste.
Los requisitos funcionales pueden estar descritos en productos de trabajo tales como
especificaciones de requisitos de negocio, épicas, historias de usuario, casos de uso,
especificaciones funcionales; incluso pueden estar sin documentar.
"Las funciones describen "qué" debe hacer el sistema."
Se deben realizar pruebas funcionales en todos los niveles de prueba; por ejemplo, en una
prueba de componente debe basarse en una especificación de éste.
PRUEBAS NO FUNCIONALES
• Entre el tipo de prueba se evalúan las características de sistemas de software,
recordemos el estándar ISO 25010 que se basa en una clasificación de características de
calidad del producto de software. Los famosos atributos de la calidad.
• Se deben realizar pruebas no funcionales en todos los niveles de prueba y tan pronto
como sea posible.
• El descubrimiento tardío de defectos no funcionales puede ser muy peligroso para el
éxito de su proyecto.
“Las pruebas no funcionales describen “cómo hacen” lo que hace el sistema”.
PRUEBAS ESTRUCTURADAS O DE COBERTURA ISTQB - CAJA BLANCA
• Entre el tipo de prueba está enfocado en la estructura interna del sistema o en su
implementación. Esta puede incluir código, arquitectura, flujos de trabajo o de datos.
• Asimismo, se encarga de evaluar la exhaustividad de las pruebas, muchas veces usa
niveles porcentuales para sus definiciones.
• Se pueden realizar pruebas estructuradas en todos los niveles de prueba.
• Usa técnicas de caja blanca para ello.
ENTONCES ...
• Cuando se realizan cambios en el sistema, ya sea para corregir un defecto o debido a una
funcionalidad nueva o modificada, se debe probar para confirmar que los cambios han
corregido el defecto o implementado la funcionalidad correctamente, y no han causado
ninguna consecuencia adversa o imprevista.
• Estos tipos de pruebas se realizan en todos los niveles de prueba, sobre todo en
entornos ágiles, donde surgen por sprint nuevas características y refactorización, lo que da
lugar a cambios frecuentes en el código.
NIVELES Y TIPO DE PRUEBAS DE SOFTWARE
Posible fija:
Entonces...
Se puede realizar cualquiera de los tipos de prueba mencionados anteriormente en
cualquier nivel de prueba.
