Pasemos a los conceptos básicos.
La prueba de software es una verificación de la conformidad de los resultados reales y esperados del comportamiento del programa, realizada en un conjunto finito de pruebas elegidas de una determinada manera.
El propósito de la prueba es verificar que el software cumple con los requisitos, asegurar la confianza en la calidad del software, buscar errores obvios en el software, que deben ser identificados antes de que los usuarios del programa los encuentren.
¿Por qué se requieren pruebas de software?
- El proceso de prueba asegura que el software funcionará según sea necesario.
- Esto reduce los ciclos de codificación al identificar problemas al principio de la fase de desarrollo. La detección de problemas al principio de la fase de desarrollo asegura el uso correcto de los recursos y evita aumentos de costos.
- , .
- , , , .
- 1 — (Testing shows presence of defects). , , , . , , .
- 2 — (Exhaustive testing is impossible). , . , .
- 3 — (Early testing). , , .
- 4 — (Defects clustering). – . . , .
- 5 — (Pesticide paradox). , . « », , , , , .
- 6 — (Testing is concept depending). - . , , , , .
- Principio 7 - Concepto erróneo sobre la ausencia de errores (poner fin a la falacia de la ausencia de errores) . La ausencia de defectos encontrados durante las pruebas no siempre significa que el producto esté listo para su lanzamiento. El sistema debe ser fácil de usar y cumplir con las expectativas y necesidades del usuario.
Garantía de calidad (QA) y Control de calidad (QC) : estos términos son similares a los intercambiables, pero aún existe una diferencia entre garantía de calidad y control de calidad, aunque en la práctica los procesos tienen algunas similitudes.
QC (control de calidad): control de calidad del producto: análisis de los resultados de las pruebas y la calidad de las nuevas versiones del producto lanzado.
Las tareas de control de calidad incluyen:
- comprobar la disponibilidad del software para su lanzamiento;
- verificación del cumplimiento de los requisitos y calidad de este proyecto.
QA (Quality Assurance): garantía de calidad del producto: explorar oportunidades para cambiar y mejorar el proceso de desarrollo, mejorar la comunicación en el equipo, donde las pruebas son solo uno de los aspectos de la garantía de calidad.
Los objetivos de garantía de calidad incluyen:
- verificación de características técnicas y requisitos de software;
- Evaluación de riesgos;
- programar tareas para mejorar la calidad del producto;
- preparación de documentación, entorno de prueba y datos;
- pruebas;
- análisis de los resultados de las pruebas, así como elaboración de informes y otros documentos.
La verificación y la validación son dos conceptos estrechamente relacionados con los procesos de prueba y aseguramiento de la calidad. Desafortunadamente, a menudo se confunden, aunque las diferencias entre ellos son bastante significativas.
La verificación es el proceso de evaluar un sistema para ver si los resultados de la fase de desarrollo actual cumplen con las condiciones que se formularon al principio.
La validación es la determinación del cumplimiento del software desarrollado con las expectativas y necesidades del usuario, sus requisitos para el sistema.
: 310, , «», . , , «». , . , , , . «» — , «» — . , .
La documentación que se utiliza en proyectos de desarrollo de software se puede dividir aproximadamente en dos grupos:
- Documentación del proyecto: incluye todo lo relacionado con el proyecto en su conjunto.
- La documentación del producto es parte de la documentación de diseño, separada por separado, que se relaciona directamente con la aplicación o el sistema desarrollado.
Etapas de prueba:
- Análisis de producto
- Trabajar con requisitos
- Desarrollar una estrategia de prueba y planificar procedimientos de control de calidad.
- Creación de documentación de prueba
- Prueba de prototipos
- Pruebas basicas
- Estabilización
- Explotación
Etapas de desarrollo de software : las etapas que atraviesan los equipos de desarrollo de software antes de que el programa esté disponible para una amplia gama de usuarios.
El producto de software pasa por las siguientes etapas:
- análisis de los requisitos del proyecto;
- diseño;
- implementación;
- pruebas de producto;
- implementación y soporte.
Requisitos
Los requisitos son una especificación (descripción) de lo que se debe implementar.
Los requisitos describen lo que se debe implementar sin detallar el aspecto técnico de la solución.
Requisitos para requisitos:
- Corrección : cada requisito debe describir con precisión la funcionalidad deseada.
- Verificabilidad : el requisito debe formularse de tal manera que haya formas de verificar sin ambigüedades si se cumple o no.
- Integridad : cada requisito debe contener toda la información necesaria que el desarrollador necesita para implementar la funcionalidad.
- No ambiguo : el requisito se describe sin abreviaturas no obvias y redacciones vagas y solo permite una interpretación inequívoca de lo que está escrito.
- — .
- — ( ). .
- — .
- — .
- — , .
Defecto (error) : desviación del resultado real del esperado.
Un informe de error es un documento que describe la situación que llevó al descubrimiento de un defecto, indicando las razones y el resultado esperado.
Atributos del informe de defectos:
- Identificador único (ID): asignado automáticamente por el sistema.
- Tema (descripción breve, resumen): una esencia del defecto formulada brevemente de acuerdo con la regla “¿Qué? ¿Dónde? ¿Cuando?"
- Descripción detallada (Descripción): una descripción más amplia de la esencia del defecto (especificado opcionalmente).
... - Pasos para reproducir: una descripción secuencial de las acciones que llevaron a la identificación del defecto. Es necesario describir con el mayor detalle posible, indicando los valores de entrada específicos.
- (Actual result) — , , .
- (Expected result) — , , .
- (Attachments) — , -.
- (, Severity) — .
- (, Priority) — .
- (Status) — . - .
- (environment) – , .
Severity vs Priority
La severidad muestra el grado de daño causado al proyecto por la existencia de un defecto. El probador expone la gravedad.
Clasificación de la gravedad del defecto:
- La
prueba de bloqueo (S1 - Blocker) de una parte significativa de la funcionalidad no está disponible en absoluto. Error de bloqueo que deja la aplicación inoperativa, como resultado de lo cual se vuelve imposible seguir trabajando con el sistema bajo prueba o sus funciones clave. - (S2 – Critical)
, -, , , , - , workaround ( / ), . - (S3 – Major)
- /-, , workaround, - . visibility – , , , . - (S4 – Minor)
GUI, , . , . - Trivial (S5 - Trivial)
casi siempre defectos en la GUI: errores tipográficos en el texto, falta de coincidencia de fuente y tono, etc., o un error poco reproducible que no concierne a la lógica empresarial, un problema con bibliotecas o servicios de terceros, un problema que no tiene ningún efecto sobre la calidad general del producto.
La prioridad indica la rapidez con la que se debe solucionar el defecto. La prioridad la establece el gerente, el líder del equipo o el cliente.
Gradación de prioridad de defectos (Prioridad):
- P1 High El
error debe corregirse lo antes posible. su presencia es fundamental para el proyecto. - P2 Medio El
error debe corregirse, su presencia no es crítica, pero debe resolverse. - P3 (Low)
, .
:
- (epic) — , .
- (story) — (), 1 .
- (task) — , .
- - (sub-task) — / , .
- (bug) — , .
- (Development Env) – , , , Unit-. .
- (Test Env) – . . , , . .
- (Integration Env) – , . end-to-end , , . , . – , .
- (Preview, Preprod Env) – , : , - , . , «». end-to-end , / (User Acceptance Testing (UAT)), L3 L2 DryRun ( ). L3 .
- (Production Env) – , . L2 , , . L3.
- Pre-Alpha: . . . .
- Alpha: . — . - . . .
- Beta: . , .
- Release Candidate (RC) : según los comentarios de la prueba Beta, realiza cambios de software y desea probar las correcciones de errores. En este punto, no desea realizar cambios drásticos en la funcionalidad, simplemente verifique si hay errores. RC también puede ser divulgado al público.
- Lanzamiento: todo funciona, el software se lanza al público.
Los principales tipos de pruebas de software.
Un tipo de prueba es un conjunto de actividades destinadas a probar las características especificadas de un sistema o su parte, en función de objetivos específicos.
- Clasificación ejecutando código para su ejecución:
- — . , . «». — .
- — . , / . — , . , , .
- :
- — , , // .
- — , White Box Black Box . , .
- — , – , .
- :
- — - ( , subprograms, subroutines, ) . , .
- — , ( , ).
- — , , .
- — , - .
- :
- .
- .
-
- — , .
- — , .
- :
- (smoke test) — , , .
- (critical path) — , .
- (extended) — .
- :
- - — . - .
- - — . , .
- :
- (functional testing) — ( ).
- (non-functional testing) — , , , « ».
- (performance testing) — , , .
- (load testing) — , , .
- (scalability testing) — .
- (volume testing) — , .
- (stress testing) — , .
- (installation testing) — , , .
- (GUI/UI testing) — .
- (usability testing) — , .
- (localization testing) — (, ).
- (security testing) — , .
- (reliability testing) — .
- Prueba de regresión : prueba de la funcionalidad probada previamente después de realizar cambios en el código de la aplicación, para asegurarse de que estos cambios no introdujeron errores en áreas que no se han modificado.
- Nueva prueba / prueba de confirmación : prueba durante la cual se ejecutan los scripts de prueba que detectaron errores durante la última ejecución para confirmar el éxito de la corrección de estos errores.
El diseño de prueba es la etapa de prueba de software, en la que se diseñan y crean casos de prueba (casos de prueba).
Técnicas de diseño de pruebas:
- (equivalence partitioning) — , , ( ) .
- (boundary value testing) — () .
- (pairwise testing) — , -.
- (State-Transition Testing) — .
- (Decision Table Testing) — , , .
- (Exploratory Testing) — , -: .
- (Domain Analysis Testing) — , .
- (Use Case Testing) — Use Case ( — ).
La prueba de caja blanca es un método de prueba de software que asume que el evaluador conoce la estructura / dispositivo / implementación internos del sistema.
Según ISTQB, las pruebas de caja blanca son:
- pruebas basadas en un análisis de la estructura interna de un componente o sistema;
- diseño de prueba basado en la técnica de caja blanca - procedimiento para escribir o seleccionar casos de prueba basado en un análisis de la estructura interna de un sistema o componente.
¿Por qué White Box? El programa bajo prueba para el probador es una caja transparente, cuyo contenido ve perfectamente.
Prueba de caja gris- método de prueba de software, que asume una combinación de enfoques de caja blanca y caja negra. Es decir, solo conocemos parcialmente la estructura interna del programa.
La prueba de caja negra , también conocida como prueba basada en especificaciones o prueba de comportamiento, es una técnica de prueba que se basa únicamente en las interfaces externas del sistema bajo prueba.
Según ISTQB, las pruebas de caja negra son:
- pruebas, tanto funcionales como no funcionales, que no implican el conocimiento de la estructura interna de un componente o sistema;
- diseño de prueba basado en la técnica de caja negra - procedimiento para escribir o seleccionar casos de prueba basado en un análisis de la especificación funcional o no funcional de un componente o sistema sin conocer su estructura interna.
Documentación de prueba
Un plan de prueba es un documento que describe todo el alcance de la prueba, desde la descripción de la instalación, la estrategia, el cronograma, los criterios para el inicio y el final de la prueba, hasta el equipo requerido en el proceso de operación, conocimientos especiales, así como evaluación de riesgos con opciones para su resolución. ...
El plan de prueba debe responder a las siguientes preguntas:
- ¿Qué se debe probar?
- ¿Qué vas a probar?
- ¿Cómo vas a probar?
- ¿Cuándo harás la prueba?
- Criterios de inicio de la prueba.
- Criterios de terminación de la prueba.
Los puntos principales del plan de prueba:
El estándar IEEE 829 enumera los puntos en los que debe constar el plan de prueba:
a) Identificador del plan de prueba;
b) Introducción;
c) Elementos de prueba;
d) Características que se probarán;
e) Características que no se probarán;
f) Aproximación;
g) Criterios de aprobación / reprobación del artículo;
h) Criterios de suspensión y requisitos de reanudación;
i) Probar los entregables;
j) Tareas de prueba;
k) Necesidades ambientales;
l) Responsabilidades;
m) Necesidades de personal y capacitación;
n) Horario;
o) Riesgos y contingencias;
p) Aprobaciones.
Una lista de verificación es un documento que describe lo que se debe probar. La lista de verificación puede tener niveles de detalle completamente diferentes.
La mayoría de las veces, la lista de verificación contiene solo acciones, sin el resultado esperado. La lista de verificación está menos formalizada.
Un caso de prueba es un artefacto que describe un conjunto de pasos, condiciones específicas y parámetros necesarios para probar la implementación de una función bajo prueba o una parte de ella.
Atributos del caso de prueba:
- Condiciones previas : una lista de acciones que llevan al sistema a un estado adecuado para realizar una verificación básica. O una lista de condiciones, cuyo cumplimiento indica que el sistema se encuentra en un estado adecuado para realizar la prueba principal.
- Pasos : una lista de acciones que transfieren el sistema de un estado a otro, para obtener un resultado, sobre la base del cual es posible concluir que la implementación cumple con los requisitos.
- Resultado esperado : lo que deberían obtener de hecho.
Resumen
Trate de comprender las definiciones, no de memorizarlas. Y si tienes alguna duda, siempre puedes preguntarnos en el canal de telegramas @qa_chillout .