Pasemos a los conceptos básicos
Las pruebas de software son una verificación de la conformidad de los resultados reales y esperados del comportamiento del programa, llevada a cabo en un conjunto finito de pruebas elegidas de una determinada manera.
El propósito de las pruebas 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 realizan las pruebas de software?
- Verificar el cumplimiento de los requisitos.
- Para detectar problemas en una fase temprana de la fase de desarrollo y evitar aumentos en el precio de los productos.
- Descubrir casos de uso no previstos durante el desarrollo. Así como la perspectiva del usuario sobre el producto.
- , .. .
- 1 — (Testing shows presence of defects).
, , . - 2 — (Exhaustive testing is impossible).
, ( — ). - 3 — (Early testing).
, . - 4 — (Defects clustering).
. - 5 — (Pesticide paradox).
, - . - 6 — (Testing is context 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 satisfacer 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 aseguramiento de la 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 los 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.
Atributos de requisitos:
- La exactitud es una descripción precisa de la funcionalidad desarrollada.
- Verificabilidad : la formulación de requisitos de tal manera que sea posible establecer un veredicto inequívoco si todo se ha hecho de acuerdo con los requisitos o no.
- Integridad : el requisito debe contener toda la información necesaria para implementar la funcionalidad.
- Sin ambigüedades: el requisito debe contener una redacción inequívoca.
- — .
- — ( ). .
- — .
- — .
- — , .
Defecto (error) : desviación del resultado real del esperado.
Informe de error : documento que contiene un informe de cualquier deficiencia en un componente o sistema que podría causar que un componente o sistema no pueda realizar la función requerida.
Atributos del informe de defectos:
- Identificador único (ID): asignado automáticamente por el sistema al crear un informe de error.
- Tema (descripción breve, resumen): una esencia del defecto formulada brevemente de acuerdo con la regla “¿Qué? ¿Dónde? ¿Cuándo?"
- Descripción: una descripción más amplia de la esencia del defecto (especificado opcionalmente).
- (Steps To Reproduce) — , . , .
- (Actual result) — , , .
- (Expected result) — , , .
- (Attachments) — , -.
- (, Severity) — .
- (, Priority) — .
- Estado: define el estado actual del defecto. Los estados de los defectos pueden ser diferentes en diferentes sistemas de seguimiento de errores.
- Entorno: indica el entorno en el que se reprodujo el error.
Ciclo de vida de los insectos
Severidad frente a prioridad
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:
- P1
Error crítico alto para el proyecto. Debe arreglarse lo antes posible. - P2 Medio
No es un error crítico para el proyecto, pero debe resolverse. - P3 (Low)
. , .
:
- (epic) — , .
- (requirement ) — , .
- (story) — (), 1 .
- (task) — , .
- - (sub-task) — / , .
- (bug) — , .
- (Development Env) – , , ,
- (Test Env) – , ( , smoke , .
- (Integration Env) – , , , .
- (Preprod Env) – , . .
- (Production Env) – , .
- Pre-Alpha: , . .
- Alpha: , -.
- Beta: , .
- Release Candidate (RC): .
- Release: , .
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:
- Las pruebas estáticas son un proceso de prueba que se lleva a cabo para verificar casi cualquier artefacto de desarrollo: componentes del código del programa, requisitos, especificaciones del sistema, especificaciones funcionales, documentos de diseño y arquitectura de los sistemas de software y sus componentes.
- Prueba dinámica : la prueba se lleva a cabo en un sistema en ejecución, no se puede realizar sin ejecutar el código del programa de la aplicación.
- Clasificación por código de acceso y arquitectura:
- — , .
- — , ( White Box Black Box ).
- — , ( ) . .
- :
- — - () . , .
- — , , .
- — , , — , , .
- — , - .
- :
- .
- .
-
- — , .
- — , .
- :
- (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) — , .
- (regression testing) — , , , .
- / (re-testing/confirmation testing) — , , , .
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
El autor de A Practitioner's Guide to Software Test Design , Lee Copeland, destaca las siguientes técnicas de diseño de pruebas:
- La prueba de partición de equivalencia es una técnica de caja negra en la que dividimos la funcionalidad (a menudo un rango de posibles valores de entrada) en grupos de valores que son equivalentes en términos de su efecto en el sistema.
- La prueba de valor límite es una técnica para probar el comportamiento del producto en los valores extremos (límite) de los datos de entrada.
- (pairwise testing) — , -.
- (State-Transition Testing) — .
- (Decision Table Testing) — , , .
- (Domain Analysis Testing) — , .
- Prueba de caso de uso: el caso de uso describe el escenario de interacción entre dos o más participantes (generalmente un usuario y un sistema).
Métodos de prueba
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;
- El diseño de prueba basado en la técnica de caja blanca es un 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.
La prueba de caja gris es un método de prueba de software que implica 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 impliquen el conocimiento de la estructura interna de un componente o sistema;
- El diseño de prueba basado en la técnica de caja negra es un procedimiento para escribir o seleccionar casos de prueba basado en el análisis de una especificación funcional o no funcional de un componente o sistema sin conocer su estructura interna.
Documentación de prueba
Un plan de pruebas es un documento que describe todo el alcance de las pruebas, desde la descripción de la instalación, la estrategia, el cronograma, los criterios para iniciar y finalizar las pruebas, hasta el equipo requerido en el proceso de operación, el conocimiento especial y la evaluación de riesgos.
El plan de prueba debe responder a las siguientes preguntas:
- ¿Qué hay que probar?
- ¿Cómo se harán las pruebas?
- ¿Cuándo se realizarán las pruebas?
- Criterios de inicio de la prueba.
- Criterios de terminación de la prueba.
Los principales puntos del plan de prueba:
- Identificador del plan de prueba;
- (Introduction);
- (Test items);
- , (Features to be tested;)
- , (Features not to be tested);
- (Approach);
- (Item pass/fail criteria);
- (Suspension criteria and resumption requirements);
- (Test deliverables);
- (Testing tasks);
- (Environmental needs);
- (Responsibilities);
- (Staffing and training needs);
- (Schedule);
- (Risks and contingencies);
- (Approvals).
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 está satisfecha con los requisitos establecidos.
- Resultado esperado : lo que deberían obtener de hecho.
Resumen
Trate de comprender las definiciones, no de memorizarlas. Si desea saber más sobre las pruebas, puede leer la Biblia QA . Y si tienes alguna duda, siempre puedes preguntarnos en el canal de telegramas @qa_chillout .