STLC - Guía rápida

STLC son las siglas de Software Testing Life Cycle. STLC es una secuencia de diferentes actividades realizadas por el equipo de pruebas para garantizar la calidad del software o del producto.

  • STLC es una parte integral del ciclo de vida del desarrollo de software (SDLC). Pero, STLC solo se ocupa de las fases de prueba.

  • STLC comienza tan pronto como se definen los requisitos o las partes interesadas comparten el SRD (documento de requisitos de software).

  • STLC proporciona un proceso paso a paso para garantizar un software de calidad.

  • En la etapa inicial de STLC, mientras se desarrolla el software o el producto, el evaluador puede analizar y definir el alcance de las pruebas, los criterios de entrada y salida y también los casos de prueba. Ayuda a reducir el tiempo del ciclo de prueba junto con una mejor calidad.

  • Tan pronto como finaliza la fase de desarrollo, los probadores están listos con los casos de prueba y comienzan con la ejecución. Esto ayuda a encontrar errores en la fase inicial.

Fases STLC

STLC tiene las siguientes fases diferentes, pero no es obligatorio seguir todas las fases. Las fases dependen de la naturaleza del software o del producto, el tiempo y los recursos asignados para las pruebas y el modelo de SDLC que se va a seguir.

Hay 6 fases principales de STLC:

  • Requirement Analysis - Cuando el SRD está listo y compartido con las partes interesadas, el equipo de prueba comienza un análisis de alto nivel sobre la AUT (Aplicación en prueba).

  • Test Planning - Test Team planifica la estrategia y el enfoque.

  • Test Case Designing - Desarrollar los casos de prueba en base a alcance y criterios.

  • Test Environment Setup - Cuando el entorno integrado está listo para validar el producto.

  • Test Execution - Validación de producto en tiempo real y búsqueda de errores.

  • Test Closure - Una vez que se completan las pruebas, se documentan la matriz, los informes y los resultados.

En este capítulo, comprenderemos los factores de comparación entre STLC y SDLC. Consideremos los siguientes puntos y, por lo tanto, comparemos STLC y SDLC.

  • STLC es parte de SDLC. Se puede decir que STLC es un subconjunto del conjunto SDLC.

  • STLC se limita a la fase de prueba en la que se garantiza la calidad del software o del producto. SDLC tiene un papel importante y enorme en el desarrollo completo de un software o producto.

  • Sin embargo, STLC es una fase muy importante de SDLC y el producto final o el software no se puede lanzar sin pasar por el proceso STLC.

  • STLC también es parte del ciclo de post-lanzamiento / actualización, la fase de mantenimiento de SDLC donde los defectos conocidos se solucionan o se agrega una nueva funcionalidad al software.

La siguiente tabla enumera los factores de comparación entre SDLC y STLC según sus fases:

Fase SDLC STLC
Reunión de requisitos
  • Business Analyst reúne requisitos.
  • El equipo de desarrollo analiza los requisitos.
  • Después del alto nivel, el equipo de desarrollo comienza a analizar desde la perspectiva de la arquitectura y el diseño.
  • El equipo de pruebas revisa y analiza el documento de SRD.
  • Identifica los requisitos de prueba: puntos clave de alcance, verificación y validación.
  • Revisa los requisitos para la relación lógica y funcional entre varios módulos. Esto ayuda a identificar las lagunas en una etapa temprana.
Diseño
  • La arquitectura de SDLC le ayuda a desarrollar un diseño de software de alto y bajo nivel basado en los requisitos.
  • Business Analyst trabaja en el burlón del diseño de la interfaz de usuario.
  • Una vez que se completa el diseño, las partes interesadas lo firman.
  • En STLC, el arquitecto de pruebas o un jefe de pruebas suelen planificar la estrategia de prueba.
  • Identifica los puntos de prueba.
  • La asignación de recursos y los plazos se finalizan aquí.
Desarrollo
  • El equipo de desarrollo comienza a desarrollar el software.
  • Integre con diferentes sistemas.
  • Una vez realizada toda la integración, se proporciona un software o producto listo para probar.
  • El equipo de pruebas escribe los escenarios de prueba para validar la calidad del producto.
  • Se escriben casos de prueba detallados para todos los módulos junto con el comportamiento esperado.
  • Aquí se identifican los requisitos previos y los criterios de entrada y salida de un módulo de prueba.
Configuración del entorno
  • El equipo de desarrollo configura un entorno de prueba con un producto desarrollado para validar.
  • El equipo de prueba confirma la configuración del entorno según los requisitos previos.
  • Realiza pruebas de humo para asegurarse de que el entorno sea estable para que el producto se pruebe.
Pruebas
  • La prueba real se lleva a cabo en esta fase. Incluye pruebas unitarias, pruebas de integración, pruebas de sistemas, nuevas pruebas de defectos, pruebas de regresión, etc.
  • El equipo de desarrollo corrige el error informado, si lo hay, y lo envía al probador para que lo vuelva a probar.
  • Las pruebas de UAT se realizan aquí después de aprobar las pruebas de SIT.
  • Las pruebas de integración del sistema comienzan según los casos de prueba.
  • Los defectos informados, si los hay, se vuelven a probar y se reparan.
  • La prueba de regresión se realiza aquí y el producto se cierra una vez que cumple con los criterios de salida.
Implementación / lanzamiento de producto
  • Una vez que se recibe la aprobación de varios equipos de prueba, la aplicación se implementa en un entorno de producción para usuarios finales reales.
  • Las pruebas de humo y cordura en el entorno de producción se completan aquí tan pronto como se implementa el producto.
  • Los informes de prueba y la preparación de la matriz son realizados por el equipo de pruebas para analizar el producto.
Mantenimiento
  • Cubre los apoyos posteriores a la implementación, las mejoras y las actualizaciones, si las hubiera.
  • En esta fase, el mantenimiento de casos de prueba, trajes de regresión y scripts de automatización se lleva a cabo en función de la mejora y las actualizaciones.

El objetivo común de las pruebas es encontrar errores lo antes posible. Y, una vez que se solucionen los errores, asegúrese de que esté funcionando como se esperaba y no interrumpa ninguna otra funcionalidad.

Para lograr estos objetivos, se dan siete principios básicos para las pruebas de software:

¿Qué muestra la prueba?

Las pruebas pueden mostrar que hay defectos, pero no hay forma de probar que no hay ningún defecto en el producto. Las fases de prueba garantizan que la aplicación bajo prueba esté funcionando según el requisito dado y ayuda a reducir la probabilidad de defectos no descubiertos en la aplicación. Pero, incluso si no se encuentran defectos, no significa que sea absolutamente correcto. Podemos suponer que AUT coincide con nuestros criterios de salida y mantiene los requisitos de acuerdo con SRD.

¿Es posible realizar pruebas exhaustivas?

La cobertura del 100% o la prueba de todas las combinaciones de entradas y posibles combinaciones no son posibles excepto en casos triviales. En lugar de pruebas exhaustivas, se utilizan análisis de riesgos y prioridades para definir el alcance de las pruebas. Aquí, la mayoría de los escenarios en tiempo real pueden considerar incluir también el escenario negativo más probable. Esto nos ayudará a rastrear el error.

Pruebas tempranas

Las actividades de prueba deben comenzar lo antes posible y centrarse en los objetivos definidos en la estrategia de prueba y los resultados esperados. Las primeras etapas de las pruebas ayudan a identificar los defectos de los requisitos o las discrepancias en el nivel de diseño. Si estos tipos de errores se capturan en la etapa inicial, nos ayuda a ahorrar tiempo y también es rentable. La respuesta a por qué las pruebas deben comenzar en una etapa temprana es muy simple: tan pronto como se recibe el SRD, los evaluadores pueden analizar el requisito desde la perspectiva de la prueba y pueden notar una discrepancia en los requisitos.

Agrupación de defectos

Basado en análisis de defectos de productos anteriores, se puede decir que la mayoría de los defectos se identifican a partir de un pequeño conjunto de módulos que son críticos para la aplicación. Estos módulos se pueden identificar en función de la complejidad, la interacción del sistema diferente o la dependencia de otros módulos diferentes. Si los evaluadores pueden identificar estos módulos cruciales, pueden centrarse más en estos módulos para identificar todos los errores posibles. En un estudio, se encontró que 8 de cada 10 defectos se identifican a partir del 20% de funcionalidad de AUT.

Paradoja del pesticida

¿Qué es la paradoja de los pesticidas? Si los pesticidas se usan con frecuencia en los cultivos, llega cuando los insectos desarrollan un cierto tipo de resistencia y gradualmente los pesticidas así rociados parecen ser ineficaces sobre los insectos.

El mismo concepto se aplica también a las pruebas. Aquí, los insectos son bichos, mientras que los pesticidas son casos de prueba que se utilizan para funcionar una y otra vez. Si los mismos conjuntos de casos de prueba se ejecutan una y otra vez, estos casos de prueba se vuelven ineficaces después de cierto período de tiempo y los probadores no podrán identificar ningún defecto nuevo.

Para superar estas condiciones, los casos de prueba deben revisarse y revisarse de vez en cuando y se pueden agregar casos de prueba nuevos y diferentes. Esto ayudará a identificar nuevos defectos.

Las pruebas dependen del contexto

Este principio establece que no se pueden probar dos tipos diferentes de aplicaciones utilizando el mismo enfoque hasta que ambas aplicaciones sean de la misma naturaleza. Por ejemplo, si un evaluador usa el mismo enfoque para la aplicación basada en web y la aplicación móvil, eso es completamente incorrecto y existe un alto riesgo de que el lanzamiento del producto sea de baja calidad. Los evaluadores deben utilizar diferentes enfoques, metodologías, técnicas y cobertura para diferentes tipos y naturaleza de aplicaciones.

Ausencia de error - Falacia

Este principio establece encontrar defectos y corregirlos hasta que la aplicación o el sistema sea estable, lleve mucho tiempo y también consuma recursos. Incluso después de corregir el 99% de los defectos, existe un alto riesgo de aplicación inestable. Lo primero esencial es verificar la estabilidad de la aplicación y los requisitos previos del entorno. Si se cumplen estas dos condiciones, solo entonces podemos comenzar con las pruebas detalladas.

El análisis de requisitos es la primera fase de STLC y comienza tan pronto como el SRD / SRS se comparte con el equipo de pruebas. Consideremos los siguientes puntos para comprender el análisis de requisitos en STLC.

  • El criterio de entrada de esta fase es la provisión de SRS (Especificación de requisitos de software); También se recomienda que la arquitectura de la aplicación sea útil.

  • En esta fase, el equipo de control de calidad analiza en un nivel superior qué probar y cómo probar.

  • El equipo de control de calidad realiza un seguimiento con varias partes interesadas, como el analista de negocios, la arquitectura del sistema, el cliente, el administrador de pruebas / líder en caso de que se requiera alguna consulta o aclaración para comprender el requisito.

  • Los requisitos pueden ser funcionales o no funcionales, como rendimiento, seguridad, usabilidad, etc., o tanto funcionales como no funcionales.

  • El criterio de salida de esta fase es completar el documento RTM, el informe de viabilidad de automatización y una lista de preguntas, si corresponde, para ser más específicos sobre los requisitos.

Actividades realizadas para el análisis de requisitos

Hay tres actividades principales que realiza el equipo de garantía de calidad en esta fase. Las actividades se describen a continuación.

Definición del alcance

El equipo de QA identifica el alcance de las pruebas en niveles altos y se divide en varios módulos funcionales. El equipo también identifica los tipos de pruebas necesarias para realizar: pruebas de humo, pruebas de cordura, pruebas funcionales, pruebas de regresión, etc. El equipo de control de calidad analiza los requisitos previos y los detalles del entorno donde se supone que deben realizarse las pruebas. El equipo recopila detalles sobre las prioridades de prueba y se centra en la secuencia de módulos a validar. También identifica los defectos de los requisitos si los módulos se contradicen y la funcionalidad no se transfiere junto con otros módulos.

Preparar RTM

El rastreo de requisitos es un proceso de documentación de los vínculos entre los requisitos y los productos de trabajo desarrollados para implementar y verificar esos requisitos. El RTM captura todos los requisitos en el análisis de requisitos junto con su trazabilidad en un solo documento. Todo esto se entrega al final del ciclo de vida.

La Matriz se crea al comienzo de un proyecto, ya que forma la base del alcance del proyecto y los entregables que se producirán.

La Matriz es bidireccional, ya que rastrea el requisito hacia adelante al examinar el resultado de los entregables y hacia atrás al observar el requisito de negocio que se especificó para una característica particular del producto.

Análisis de automatización

En la fase de requisitos, el equipo de control de calidad analiza el alcance de la automatización para las pruebas de regresión. Si se agrega la automatización al alcance, el equipo decide qué herramienta se puede usar, qué funcionalidades se cubrirán como automatización, el marco de tiempo y la asignación de recursos involucrados para el desarrollo de la automatización. Una vez que se completa este análisis, el equipo de control de calidad proporciona el Informe de viabilidad de automatización a diferentes partes interesadas para que lo aprueben.

En este capítulo, veremos los Criterios de entrada y salida en diferentes niveles en STLC. Se deben considerar los siguientes puntos para comprender los criterios.

Idealmente, el equipo de garantía de calidad no procede con la siguiente fase hasta que se cumplen los criterios de salida de la fase actual. Los criterios de entrada deben incluir la finalización de los criterios de salida de la fase anterior.

En tiempo real, no es posible esperar a la siguiente fase hasta que se cumplan los criterios de salida. Ahora, la siguiente fase puede iniciarse si se han completado los entregables críticos de la fase anterior.

En cada fase de STLC, se deben definir los criterios de entrada y salida.

Criterio para entrar

Los criterios de entrada para las fases STLC se pueden definir como condiciones específicas; o, todos aquellos documentos que se requieren para comenzar una fase particular de STLC deben estar presentes antes de ingresar a cualquiera de las fases de STLC.

Los criterios de entrada son un conjunto de condiciones que permiten que se realice una tarea o, en ausencia de cualquiera de estas condiciones, la tarea no se puede realizar.

Al establecer los criterios de entrada, también es importante definir el marco de tiempo cuando el elemento de los criterios de entrada está disponible para iniciar el proceso.

Por ejemplo, para iniciar la fase de desarrollo de casos de prueba, se deben cumplir las siguientes condiciones:

  • El documento de requisitos debe estar disponible.
  • Se requiere una comprensión completa del flujo de la aplicación.
  • El documento del plan de prueba debería estar listo.

Criterio de salida

Los criterios de salida para las fases de STLC se pueden definir como elementos / documentos / acciones / tareas que deben completarse antes de concluir la fase actual y pasar a la siguiente.

Los criterios de salida son un conjunto de expectativas; esto debe cumplirse antes de concluir la fase STLC.

Por ejemplo, para concluir la fase de desarrollo de casos de prueba, se deben cumplir las siguientes expectativas:

  • Los casos de prueba deben escribirse y revisarse.
  • Los datos de prueba deben estar identificados y listos.
  • El script de automatización de pruebas debe estar listo si corresponde.

Criterios de aceptación significa el comportamiento esperado de una funcionalidad, un módulo y una aplicación que se enumeran en los documentos de requisitos. Son etapas de verificación / puntos de control para determinar si el sistema de software ha cumplido o no con las especificaciones de los requisitos. El propósito principal de esta prueba es evaluar el cumplimiento del sistema con los requisitos comerciales y verificar si cumple con los criterios requeridos.

Criterios de aceptación es un conjunto de declaraciones que mencionan claramente el resultado esperado de aprobado / reprobado. Los criterios de aceptación especifican requisitos tanto funcionales como no funcionales. Estos requisitos representan "condiciones de satisfacción o comportamiento esperado". No hay aceptación parcial; o se cumple un criterio o no se cumple.

Estos criterios definen los límites y parámetros de una funcionalidad / módulo y determinan si la funcionalidad / módulo está completo y funciona como se esperaba.

Los criterios de aceptación de alto nivel se mencionan en el nivel del plan de prueba. Los criterios de aceptación se convierten en una lista de puntos a verificar o resultados esperados a nivel de casos de prueba.

Los criterios de aceptación se definen sobre la base de los siguientes atributos:

  • Corrección e integridad funcional
  • Integridad de los datos
  • Conversión de datos
  • Usability
  • Performance
  • Timeliness
  • Confidencialidad y disponibilidad
  • Capacidad de instalación y actualización
  • Scalability
  • Documentation

Un plan de prueba describe la estrategia que se utilizará para probar una aplicación, los recursos que se utilizarán, el entorno de prueba en el que se realizarán las pruebas y las limitaciones de las pruebas y el cronograma de las actividades de prueba. Por lo general, el líder del equipo de garantía de calidad será responsable de redactar un plan de prueba.

¿Qué incluye un plan de prueba?

Un plan de prueba incluye lo siguiente.

  • Introducción al documento del plan de prueba.
  • Supuestos al probar la aplicación.
  • Lista de casos de prueba incluidos en la prueba de la aplicación.
  • Lista de características que se probarán.
  • El tipo de enfoque que se utilizará al probar el software.
  • Lista de entregables que deben probarse.
  • Los recursos asignados para probar la aplicación.
  • Cualquier riesgo involucrado durante el proceso de prueba.
  • Un cronograma de tareas e hitos a alcanzar.

Puntos importantes para la planificación de pruebas

Los siguientes puntos deben tenerse en cuenta para la planificación de pruebas en STLC.

  • Idealmente, el analista de pruebas (líder) / el gerente prepara el documento de estrategia de prueba / plan de prueba.

  • El análisis se centra más en los datos / información relacionados con la aplicación.

  • Es la primera fase de las tareas de prueba reales.

  • Esta fase responde “QUÉ se va a probar” y “QUÉ RECURSOS se requieren para probar”.

  • El criterio de entrada básico de esta fase es la provisión de Documentos de Requisitos (versión actualizada de requisitos poco claros / faltantes / aclarados) junto con la Matriz de Trazabilidad de Requisitos.

  • Si la automatización está dentro del alcance, se debe preparar el Informe de viabilidad de automatización antes de ingresar a esta fase.

  • El criterio de salida de esta fase es la finalización del documento de estrategia de prueba / plan de prueba y el documento de estimación de esfuerzo de prueba.

Aspectos de la fase de planificación de la prueba

El objetivo principal de esta fase es preparar un documento de Plan de prueba / Estrategia de prueba. Incluye tres aspectos principales: alcance de los entregables, estimación del esfuerzo y plan de recursos.

Alcance de los entregables

Es necesario realizar las siguientes actividades para concluir sobre el alcance de los entregables:

  • Identificar el modelo adecuado de participación y entrega.
  • Definir objetivos de prueba, alcance de prueba, fases de prueba y actividades.
  • Revise los requisitos comerciales y los requisitos del sistema para identificar la viabilidad de la prueba.
  • Defina el proceso de prueba, el tipo de prueba y los procedimientos.
  • Definir procedimientos de gestión de defectos y gestión de cambios.
  • Identificar herramientas, técnicas y mejores prácticas de prueba.
  • Definir análisis de riesgo.
  • Defina la solución de automatización e identifique candidatos adecuados para la automatización, si corresponde.

Estimación del esfuerzo

La estimación es el proceso de encontrar una estimación o aproximación, que es un valor que se puede usar para algún propósito, incluso si los datos de entrada pueden ser incompletos, inciertos o inestables.

La estimación determina cuánto dinero, esfuerzo, recursos y tiempo tomará construir un sistema o producto específico. La estimación se basa en:

  • Datos pasados ​​/ experiencia pasada
  • Documentos / conocimientos disponibles
  • Assumptions
  • Riesgos identificados

Los cuatro pasos básicos en la prueba de estimación son:

  • Estimación del tamaño de la AUT (Aplicación bajo prueba).
  • Estimación del esfuerzo en meses-persona u horas-persona.
  • Estimación del cronograma en meses naturales.
  • Estimación del costo del proyecto en moneda acordada.

Plan de recursos

Los planes de recursos son el elemento clave en las fases de prueba. Estos planes son inversamente proporcionales al tiempo que tarda el equipo de prueba en completar una tarea en particular. Aumentar la cantidad de recursos disminuirá la cantidad de días de finalización para un cierto límite después de que se sature y aumentar el recurso no tendrá mucho impacto y podría no conducir a una disminución en los días de finalización.

Un Solicitante de Recursos, generalmente un gerente de proyecto, crea planes de recursos para solicitar recursos, rastrear esfuerzos y costos. Un administrador de recursos puede modificar y aprobar planes de recursos antes de que se utilicen.

El flujo de trabajo normal para un plan de recursos es:

  • Planificación por Project Manager
  • Solicitud presentada por Project Manager
  • Aprobar / modificar / rechazar por el administrador de recursos
  • Completo: cierre de la solicitud después de que Resource Manager la apruebe

Una vez que el plan de prueba está listo, el equipo de control de calidad inicia el desarrollo de casos de prueba. El principal objetivo de esta fase es preparar casos de prueba para una unidad individual. Estos casos de prueba funcionales y estructurales cubren la funcionalidad, los puntos de verificación y validación mencionados en el Plan de prueba.

Los siguientes puntos deben tenerse en cuenta para el desarrollo de casos de prueba en STLC.

  • En esta fase, el equipo de QA escribe el caso de prueba con un enfoque gradual. El caso de prueba es luego firmado por un analista de negocios después de revisar o volver a trabajar en los casos de prueba en caso de que se requieran modificaciones.

  • Una vez que los casos de prueba están listos, el equipo de control de calidad prepara los datos de prueba según las condiciones previas.

  • El criterio de entrada de esta fase es que las actividades en la planificación de pruebas deben estar terminadas y el plan de pruebas debe estar listo.

  • El criterio de salida de esta fase es que los casos de prueba deben firmarse, los datos de prueba deben estar listos y los scripts de prueba deben estar preparados si la automatización está dentro del alcance.

  • Los casos de prueba deben mapearse con la Matriz de trazabilidad de requisitos para realizar un seguimiento de la cobertura de los requisitos si se omite algo.

Actividades en la fase de desarrollo de casos de prueba

A continuación se muestran las tres actividades que se llevan a cabo en la fase de desarrollo de casos de prueba:

Identificación de escenarios de prueba

Los escenarios facilitan la prueba y evaluación de un sistema complejo. Las siguientes estrategias ayudan a crear buenos escenarios:

  • Enumerar posibles usuarios, sus acciones y objetivos.

  • Evalúe a los usuarios con mentalidad de hacker y enumere posibles escenarios de abuso del sistema.

  • Enumere los eventos del sistema y cómo maneja el sistema tales solicitudes.

  • Enumere los beneficios y cree tareas de un extremo a otro para comprobarlos.

  • Lea sobre sistemas similares y su comportamiento.

  • Estudiar las quejas sobre los productos de la competencia y su predecesor.

Escritura de casos de prueba

Un caso de prueba es un documento que incluye datos de prueba, condiciones previas, resultados esperados y condiciones posteriores, desarrollado para un escenario de prueba particular con el fin de verificar el cumplimiento de un requisito específico.

Test Case actúa como punto de partida para la ejecución de la prueba. Después de que se aplica un conjunto de valores de entrada; la aplicación tiene un resultado definitivo y deja el sistema en algún punto final que también se conoce como condición de ejecución posterior.

Preparación de datos de prueba

Los datos de prueba se utilizan para ejecutar las pruebas en el material de prueba. Los datos de prueba deben ser precisos y exhaustivos para descubrir los defectos. Para lograr estos tres objetivos, se sigue un enfoque gradual como se indica a continuación:

  • Identificar los recursos o requisitos de prueba
  • Identificar las condiciones / funcionalidad a probar
  • Establecer condiciones de prueba prioritarias
  • Seleccionar condiciones para la prueba
  • Determinar el resultado esperado del procesamiento de casos de prueba
  • Crear casos de prueba
  • Documentar las condiciones de prueba
  • Realizar prueba
  • Verificar y corregir casos de prueba basados ​​en modificaciones

Diagrama de bloques de actividades

El siguiente diagrama muestra las diferentes actividades que forman parte del desarrollo de casos de prueba.

El entorno de prueba consta de elementos que respaldan la ejecución de la prueba con software, hardware y red configurados. La configuración del entorno de prueba debe imitar el entorno de producción para descubrir cualquier problema relacionado con el entorno o la configuración.

Los siguientes puntos deben tenerse en cuenta en la configuración del entorno de prueba.

  • Es una combinación de entorno de hardware y software en el que se ejecutarán las pruebas.

  • Incluye configuración de hardware, configuración del sistema operativo, configuración de software, terminales de prueba y otro soporte para realizar la prueba.

  • Es el aspecto más crucial del proceso de prueba. La falta de disponibilidad o la configuración del entorno defectuosa pueden arruinar todos los esfuerzos de prueba.

  • Prácticamente, el equipo de control de calidad no puede comenzar a trabajar sin tener el entorno adecuado para realizar pruebas.

  • Es una actividad independiente y puede iniciarse junto con el desarrollo de casos de prueba.

  • De manera más genérica, esta actividad es realizada por desarrolladores en aspectos técnicos, mientras que las condiciones de requisitos pueden ser realizadas por Clientes / Analistas comerciales.

  • La preparación del entorno de prueba puede validarse mediante pruebas de humo y el equipo de control de calidad puede realizarla.

  • Idealmente, podemos decir que los criterios de entrada de esta fase son la provisión del plan de prueba, la preparación de los casos de prueba de humo y la preparación de los datos de prueba.

  • El criterio de salida de esta fase es que el entorno de prueba debe estar listo y la prueba de humo debe realizarse con éxito con los resultados esperados.

Actividades realizadas para la configuración del entorno de prueba

En esta fase se realizan las siguientes actividades.

Entorno de prueba de diseño

Los siguientes factores juegan un papel importante para el diseño de un entorno de prueba.

  • Determine si es necesario archivar el entorno de prueba para realizar copias de seguridad.

  • Verifique la configuración de la red.

  • Identifique el sistema operativo del servidor, las bases de datos y otros componentes necesarios.

  • Identifique la cantidad de licencia requerida por el equipo de prueba.

Configuración del entorno

Analice los requisitos de configuración del entorno y prepare una lista de requisitos de software y hardware para la configuración. Obtenga la confirmación oficial para la configuración del entorno de prueba y configúrelo para acceder al entorno de prueba.

Prueba de humo

Una vez que el entorno está configurado y el equipo de control de calidad tiene acceso a él, se debe realizar una ronda rápida de pruebas de humo para validar la estabilidad de construcción del entorno de prueba. Si los resultados son los esperados, el equipo de control de calidad puede pasar a la siguiente fase; de ​​lo contrario, señalar las discrepancias y esperar la implementación después de las correcciones.

La ejecución de la prueba es el proceso de ejecutar el código y comparar los resultados esperados y reales. Los siguientes factores deben tenerse en cuenta para un proceso de ejecución de prueba:

  • Según un riesgo, seleccione un subconjunto de la suite de pruebas que se ejecutará para este ciclo.
  • Asigne los casos de prueba en cada conjunto de pruebas a los probadores para su ejecución.
  • Ejecute pruebas, informe errores y capture el estado de las pruebas de forma continua.
  • Resuelva los problemas de bloqueo a medida que surjan.
  • Informe el estado, ajuste las asignaciones y reconsidere los planes y las prioridades a diario.
  • Informar los resultados y el estado del ciclo de prueba.

Los siguientes puntos deben tenerse en cuenta para la ejecución de la prueba.

  • En esta fase, el equipo de QA realiza la validación real de AUT basada en casos de prueba preparados y compara el resultado paso a paso con el resultado esperado.

  • El criterio de entrada de esta fase es la finalización del plan de prueba y la fase de desarrollo de casos de prueba, los datos de prueba también deben estar listos.

  • La validación de la configuración del entorno de prueba siempre se recomienda a través de pruebas de humo antes de ingresar oficialmente a la ejecución de la prueba.

  • Los criterios de salida requieren la validación exitosa de todos los casos de prueba; Los defectos deben cerrarse o aplazarse; La ejecución del caso de prueba y el informe de resumen de defectos deben estar listos.

Actividades para la ejecución de pruebas

El objetivo de esta fase es la validación en tiempo real de AUT antes de pasar a la producción / lanzamiento. Para cerrar esta fase, el equipo de control de calidad realiza diferentes tipos de pruebas para garantizar la calidad del producto. Junto con esta notificación de defectos y la repetición de pruebas también es una actividad crucial en esta fase. Las siguientes son las actividades importantes de esta fase:

Prueba de integración del sistema

La validación real de producto / AUT comienza aquí. La prueba de integración del sistema (SIT) es una técnica de prueba de caja negra que evalúa el cumplimiento del sistema frente a requisitos específicos / casos de prueba preparados.

Las pruebas de integración del sistema generalmente se realizan en un subconjunto del sistema. La SIT se puede realizar con un uso mínimo de herramientas de prueba, se verifica las interacciones intercambiadas y también se investiga el comportamiento de cada campo de datos dentro de la capa individual. Después de la integración, hay tres estados principales de flujo de datos:

  • Estado de los datos dentro de la capa de integración
  • Estado de los datos dentro de la capa de la base de datos
  • Estado de los datos dentro de la capa de aplicación

Note- En las pruebas SIT, el equipo de QA intenta encontrar tantos defectos como sea posible para garantizar la calidad. El objetivo principal aquí es encontrar tantos errores como sea posible.

Notificación de defectos

Un error de software surge cuando el resultado esperado no coincide con el resultado real. Puede ser un error, falla, falla o falla en un programa de computadora. La mayoría de los errores surgen de errores y errores cometidos por desarrolladores o arquitectos.

Mientras realiza las pruebas de SIT, el equipo de control de calidad encuentra este tipo de defectos y es necesario informarlos a los miembros del equipo en cuestión. Los miembros toman más medidas y arreglan los defectos. Otra ventaja de los informes es que facilita el seguimiento del estado de los defectos. Hay muchas herramientas populares como ALM, QC, JIRA, Version One, Bugzilla que admiten informes y seguimiento de defectos.

El informe de defectos es un proceso para encontrar defectos en la aplicación que se está probando o en el producto probando o registrando los comentarios de los clientes y creando nuevas versiones del producto que corrigen los defectos en función de los comentarios del cliente.

El seguimiento de defectos también es un proceso importante en la ingeniería de software, ya que los sistemas complejos y críticos para el negocio tienen cientos de defectos. Uno de los factores más desafiantes es gestionar, evaluar y priorizar estos defectos. El número de defectos se multiplica durante un período de tiempo y, para gestionarlos de forma eficaz, se utiliza un sistema de seguimiento de defectos para facilitar el trabajo.

Mapeo de defectos

Una vez que se informa y registra el defecto, se debe asignar a los casos de prueba fallidos / bloqueados correspondientes y los requisitos correspondientes en la Matriz de trazabilidad de requisitos. Esta asignación la realiza Defect Reporter. Ayuda a hacer un informe de defectos adecuado y analizar la picardía en el producto. Una vez que los casos de prueba y los requisitos se mapean con el defecto, las partes interesadas pueden analizar y tomar una decisión sobre si corregir o diferir el defecto en función de la prioridad y la gravedad.

Nueva prueba

La repetición de la prueba consiste en ejecutar una prueba previamente fallida contra AUT para comprobar si el problema está resuelto. Una vez que se ha solucionado un defecto, se realiza una nueva prueba para verificar el escenario en las mismas condiciones ambientales.

Durante la nueva prueba, los evaluadores buscan detalles granulares en el área cambiada de funcionalidad, mientras que las pruebas de regresión cubren todas las funciones principales para garantizar que no se rompan funcionalidades debido a este cambio.

Pruebas de regresión

Una vez que todos los defectos están en estado cerrado, aplazado o rechazado y ninguno de los casos de prueba está en progreso / fallido / sin estado de ejecución, se puede decir que las pruebas de integración del sistema se basan completamente en los casos de prueba y los requisitos. Sin embargo, se requiere una ronda de pruebas rápidas para garantizar que ninguna de las funciones se rompa debido a cambios en el código o correcciones de defectos.

La prueba de regresión es una técnica de prueba de caja negra que consiste en volver a ejecutar aquellas pruebas que han tenido un impacto debido a cambios en el código. Estas pruebas deben ejecutarse con la mayor frecuencia posible a lo largo del ciclo de vida del desarrollo de software.

Tipos de pruebas de regresión

  • Final Regression Tests- Se realiza una "prueba de regresión final" para validar la compilación que no ha sufrido cambios durante un período de tiempo. Esta compilación se implementa o se envía a los clientes.

  • Regression Tests - Se realiza una prueba de regresión normal para verificar si la compilación NO ha roto ninguna otra parte de la aplicación debido a los cambios de código recientes para la corrección de defectos o para la mejora.

Diagrama de bloques de actividades

El siguiente diagrama de bloques muestra las actividades importantes realizadas en esta fase; también muestra la dependencia de las fases anteriores -

El ciclo de vida del defecto, también conocido como ciclo de vida del error, es el viaje de un defecto, el ciclo por el que pasa un defecto durante su vida. Varía de una organización a otra y también de un proyecto a otro, ya que se rige por el proceso de prueba de software y también depende de las herramientas utilizadas.

Ciclo de vida de los defectos: flujo de trabajo

El siguiente diagrama muestra el flujo de trabajo de un ciclo de vida de un defecto.

Estados del ciclo de vida de un defecto

A continuación se muestran los diferentes estados de un ciclo de vida de un defecto.

  • New - Defecto potencial que se plantea y aún no se ha validado.

  • Assigned - Asignado frente a un equipo de desarrollo a abordar.

  • Active- El desarrollador está solucionando el defecto y la investigación está en curso. En esta etapa, hay dos resultados posibles: diferido o rechazado.

  • Test / Fixed / Ready for Retest - El defecto está arreglado y listo para probar.

  • Verified - El defecto que se vuelve a probar y el control de calidad ha verificado la prueba.

  • Closed - El estado final del defecto que puede cerrarse después de la repetición del control de calidad o puede cerrarse si el defecto está duplicado o se considera que NO es un defecto.

  • Reopened - Cuando el defecto NO se arregla, QA reabre / reactiva el defecto.

  • Deferred - Cuando un defecto no se puede solucionar en ese ciclo en particular, se pospone para una versión futura.

  • Rejected - Un defecto puede ser rechazado por cualquiera de las tres razones: defecto duplicado, NO defecto, no reproducible.

Los defectos se clasifican desde la perspectiva del equipo de control de calidad como Priority y desde la perspectiva del desarrollo como Severity(complejidad del código para solucionarlo). Estas son dos clasificaciones principales que juegan un papel importante en el marco de tiempo y la cantidad de trabajo que se requiere para corregir defectos.

¿Qué es Prioridad?

La prioridad se define como el orden en que deben resolverse los defectos. El estado de prioridad generalmente lo establece el equipo de control de calidad, mientras que el equipo de desarrollo plantea el defecto y menciona el plazo para solucionar el defecto. El estado de Prioridad se establece en función de los requisitos de los usuarios finales.

Por ejemplo, si el logotipo de la empresa está colocado incorrectamente en la página web de la empresa, la prioridad es alta pero de gravedad baja.

Listado prioritario

Una prioridad se puede clasificar de las siguientes formas:

  • Low - Este defecto se puede solucionar después de que se solucionen los críticos.

  • Medium - El defecto debe resolverse en las versiones posteriores.

  • High - El defecto debe resolverse de inmediato porque el defecto afecta a la aplicación en gran medida y los módulos correspondientes no se pueden utilizar hasta que se solucione.

  • Urgent - El defecto debe resolverse de inmediato porque el defecto afecta gravemente a la aplicación o al producto y el producto no puede utilizarse hasta que se haya reparado.

¿Qué es la gravedad?

La severidad se define como la picardía del defecto en la aplicación y la complejidad del código para solucionarlo desde la perspectiva del desarrollo. Itestá relacionado con el aspecto de desarrollo del producto. La gravedad se puede decidir en función de qué tan malo / crucial sea el defecto para el sistema. El estado de gravedad puede dar una idea de la desviación en la funcionalidad debido al defecto.

Example - Para el sitio web de operaciones de vuelo, el defecto en la generación del número de boleto contra la reserva es de alta gravedad y también de alta prioridad.

Listado de gravedad

La gravedad se puede clasificar de las siguientes formas:

  • Critical /Severity 1- El defecto afecta la funcionalidad más crucial de la aplicación y el equipo de control de calidad no puede continuar con la validación de la aplicación bajo prueba sin corregirla. Por ejemplo, la aplicación / producto se bloquea con frecuencia.

  • Major / Severity 2- Defecto impacta un módulo funcional; el equipo de control de calidad no puede probar ese módulo en particular, pero continuar con la validación de otros módulos. Por ejemplo, la reserva de vuelo no funciona.

  • Medium / Severity 3- El defecto tiene un problema con una sola pantalla o relacionado con una sola función, pero el sistema aún está funcionando. El defecto aquí no bloquea ninguna funcionalidad. Por ejemplo, Ticket # es una representación que no sigue los caracteres alfanuméricos adecuados como los primeros cinco caracteres y los últimos cinco como numéricos.

  • Low / Severity 4- No afecta la funcionalidad. Puede ser un defecto cosmético, una inconsistencia de la interfaz de usuario para un campo o una sugerencia para mejorar la experiencia del usuario final desde el lado de la interfaz de usuario. Por ejemplo, el color de fondo del botón Enviar no coincide con el del botón Guardar.

Una verificación con los criterios de salida de la prueba es muy esencial para afirmar que la prueba ya está completa. Antes de poner fin al proceso de prueba, la calidad del producto se mide contra los criterios de finalización de la prueba.

El criterio de entrada de esta fase es que la ejecución del caso de prueba esté completa, los resultados de la prueba estén disponibles y el informe de defectos esté listo.

Los criterios para completar la prueba incluyen lo siguiente:

  • Se ha logrado la cobertura especificada.
  • No showstoppers o defectos críticos
  • Hay muy pocos defectos conocidos de prioridad media o baja. Estos no afectan el uso del producto.

El criterio de salida de esta fase es la provisión de informes de cierre de pruebas y la preparación de matrices que luego son firmadas por el cliente.

Analicemos ahora el activities involved in the closure of Test Cycle.

Informe de finalización de la prueba

El informe de finalización de la prueba es un proceso mediante el cual las métricas de la prueba se informan en formato resumido para actualizar a las partes interesadas. Esto les permite tomar una decisión informada.

El informe de finalización de la prueba contiene la siguiente información.

  • Identificador de informe de resumen de prueba
  • Summary
  • Variances
  • Resumen de resultados
  • Evaluation
  • Esfuerzos planificados frente a esfuerzos reales
  • cerrar sesión

Un buen Informe de finalización de la prueba indica la calidad, mide los riesgos pendientes e identifica el nivel de un software probado.

Matriz de finalización de la prueba

Una vez finalizada la prueba, se recopilan varias matrices para preparar los informes de prueba. Los criterios para preparar los informes incluyen lo siguiente:

  • Número de pruebas ejecutadas
  • Número de pruebas aprobadas
  • Número de pruebas fallidas
  • Número de pruebas fallidas según cada módulo
  • Número de defectos de prueba planteados durante el ciclo de ejecución
  • Número de defectos de prueba aceptados
  • Número de defectos de prueba rechazados
  • Número de defectos de prueba aplazados
  • Estado de defectos activos
  • Cálculo del índice de calidad de la construcción

Resultados de la prueba

Al ejecutar un caso de prueba, volver a probar los defectos y realizar un caso de prueba de regresión, Test results articulate deben guardarse y pueden producirse junto con los documentos de cierre del ciclo de prueba para respaldar la finalización de la ejecución de la prueba.

Los articulados pueden ser capturas de pantalla, resultados de consultas de bases de datos, grabaciones, archivos de registro, etc.