Menú

Flujo de proceso de control de calidad de pruebas de software prácticas (requisitos para la publicación)

practical software testing qa process flow

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Una descripción general completa del flujo de proceso de prueba de software de control de calidad de un extremo a otro:

Nota: estamos volviendo a publicar esta útil publicación con contenido actualizado.

El trabajo de un profesional de pruebas de software no es fácil. Está lleno de desafíos, que también son igualmente exigentes. Se supone que los evaluadores deben estar alertas y entusiasmados en todas y cada una de las fases del ciclo de vida de la aplicación.

Aunque existen desafíos, también existen varias oportunidades tremendas para aprender y explorar los diversos aspectos de las metodologías de prueba, los procesos y, por supuesto, el software en detalle.

El papel de un ingeniero de pruebas comienza muy temprano. Y desde la conceptualización del proyecto, los probadores participan en discusiones con el propietario del producto, el gerente del proyecto y varias partes interesadas.

Requisitos para publicar

Este tutorial sobre el “Flujo del proceso de prueba de software” le brinda una descripción completa de las distintas fases de STLC junto con los desafíos involucrados y las mejores prácticas para superar esos desafíos de una manera fácilmente comprensible.

Lo que vas a aprender:

Requisito para la liberación: descripción general completa

Ciclo de vida de las pruebas de software

Desde el requisito hasta el lanzamiento, cada fase se explica claramente. Echemos un vistazo a ellos en detalle.

# 1) Requisito

Un proyecto no puede despegar sin tener un requisito claro. Esta es la fase más crucial en la que las ideas deben escribirse en un documento bien formateado y comprensible. Si es parte del proyecto en el que participa en la fase de recopilación de requisitos, considérese afortunado.

cómo comenzar una carrera en pruebas de software

¿Preguntándome por qué? Es porque estás siendo testigo de cómo se hace un proyecto desde cero. Aunque es un orgullo serlo desde el inicio, también conlleva algunas responsabilidades y desafíos.

Desafíos

No se pueden imaginar todos los requisitos para reunirse en una sola sesión. Sea lo suficientemente paciente.

Se producirán muchas discusiones, algunas de las cuales pueden ser simplemente irrelevantes para su proyecto, pero incluso entonces pueden contener información vital para su proyecto. A veces, la velocidad de las discusiones puede exceder sus capacidades de comprensión o simplemente no le prestará atención al propietario del producto.

La siguiente imagen destaca los pasos cruciales involucrados en la recopilación de requisitos:

Requisitos LifeCycle

Cada dato que se pierde tiene un gran impacto en la comprensión y las pruebas generales del proyecto. Para superar esto, aquí hay algunas mejores prácticas que deben seguirse durante esta fase.

Mejores prácticas

  • Mantenga su mente abierta y preste atención a cada palabra del propietario del producto.
  • No se limite a escuchar, aclare su duda por pequeña que parezca.
  • Utilice siempre cuadernos para guardar notas rápidamente. Debe usar una computadora portátil, solo si realmente puede escribir a una velocidad razonable.
  • Repite las frases y haz que se aclaren del PO que crees que es lo que entendiste.
  • Dibuje diagramas de bloques, texto de enlaces, etc. para que los requisitos sean más claros en un período posterior.
  • Si los equipos están en diferentes ubicaciones, intente convertirlo en una grabación de WebEx o similar. Siempre será útil cuando tenga una duda después de que terminen las discusiones.

Aunque no existe un muro separado como tal para todas y cada una de las fases, los requisitos cambian incluso muy tarde en los desarrollos. Por lo tanto, la idea es aprovechar la mayor parte del requisito y documentarlo correctamente.

Una vez que se haya documentado con todos los puntos necesarios, distribuya y discuta a todas las partes interesadas para que cualquier sugerencia o cambio se capte temprano y antes de continuar, todos estén en la misma página.

# 2) Estrategia de prueba

Se supone que los probadores deben presentar una estrategia de prueba que no solo es suficiente para probar mejor el software, sino que también debe inspirar confianza en todas las partes interesadas con respecto a la calidad del producto.

Estrategia de prueba

Desafíos

El aspecto más crucial de esta fase es crear una estrategia que, cuando se trabaje, debería ofrecer un producto de software libre de errores, sostenible y aceptado por sus usuarios finales.

Las estrategias de prueba son algo que no cambiará cada dos días. En algunos casos, también debe discutir sus estrategias de prueba con los clientes. Por tanto, esta parte debe tratarse con gran importancia.

Mejores prácticas

  • Estas son algunas de las mejores prácticas, que cuando se siguen pueden brindarle un gran alivio y resultar en pruebas sin problemas.
  • Repase el documento de requisitos una vez más. Resalte los puntos de importación con respecto al entorno del software de destino.
  • Haga una lista de entornos en los que se implementará el software.
  • Los entornos pueden entenderse como un tipo de sistemas operativos o dispositivos móviles.
  • Si Windows es el sistema operativo, enumere todas las versiones de la ventana en la que probará su software. Si las versiones a saber. Windows 7, Windows 10 o Windows Server (s) aún no están definidos en el documento de requisitos, entonces es el momento de discutirlos.
  • En una nota similar, obtenga los navegadores de destino con las versiones discutidas y documentadas si el AUT es un sistema basado en web.
  • Haga una lista de todo el software de terceros que necesitará la aplicación (si es necesario / compatible). Estos pueden incluir Adobe Acrobat, Microsoft Office, cualquier complemento, etc.

Aquí, la idea detrás es mantener todas las plataformas, dispositivos y software necesarios y requeridos que nuestra aplicación necesitará para funcionar ante nosotros, de modo que se pueda formular una estrategia integral.

La siguiente figura le ayudará a comprender el esquema de la estrategia de prueba si está trabajando en un proyecto ágil:

Estrategia de prueba

# 3) Planificación de pruebas

Una vez que los probadores están armados con toda la información relacionada con AUT, la fase de planificación es donde se implementa la Estrategia.

Al igual que una estrategia de prueba, la planificación de la prueba también es una fase crucial.

Plan de prueba

Desafíos

Dado que el éxito (o el fracaso) de la AUT depende en gran medida de cómo se llevaron a cabo las pruebas, esta fase se convierte en un aspecto importante de todo el ciclo de vida de la prueba. ¿Por qué? Porque una parte de las pruebas se define en esta fase.

Para superar algunos desafíos, estas mejores prácticas pueden ser realmente útiles.

Mejores prácticas

  • Siempre tenga en cuenta que no debe dejar piedra sin remover cuando se trata de probar su aplicación.
  • Es hora de formular una estrategia de prueba.
  • Cree una matriz del entorno para que el software se pruebe en todas las plataformas.
  • Como, Windows 10 + Internet Explorer 11+ Windows Office 2010+.
  • Como el navegador Chrome Android 4.2.2+.
  • Si su aplicación funciona con múltiples bases de datos (si está documentado), mantenga las bases de datos (MySQL, Oracle, SQLServer) en la matriz de prueba de tal manera que estén demasiado integradas con algunas pruebas.
  • Configure las máquinas de prueba en consecuencia y nómbrelas como SetUp1, SetUp2, etc.
  • SetUp1 tendrá Windows 7+ IE 10+ Office 2007+.
  • SetUp2 puede tener Windows 10+ IE Edge + Office 2013+.
  • SetUp3 puede tener un teléfono Android con su archivo .apk instalado.
  • ¡Felicidades! Su configuración de prueba está lista y también ha incluido todas las combinaciones posibles de plataformas en las que funcionará su aplicación.

# 4) Prueba

Encontrar errores

¡Finalmente, la compilación de su aplicación está lista y está listo para encontrar errores! Ahora es el momento de trabajar en la planificación de pruebas y encontrar tantos errores como sea posible. Habrá algunas fases intermedias si trabaja en un entorno ágil, entonces simplemente siga esos métodos de scrum.

El siguiente diagrama muestra la categorización de varios tipos de pruebas:

Tipos de pruebas

Desafíos

La prueba es un proceso engorroso que en sí mismo es propenso a errores. Uno encuentra muchos desafíos al probar una aplicación. A continuación se presentan algunas de las mejores prácticas para rescatar.

Mejores prácticas

¡Animar! Está intentando encontrar defectos en el código. Debe prestar atención al funcionamiento general del software.

  • Siempre es recomendable mirar la aplicación con una mirada nueva, SIN PASAR POR CASOS DE PRUEBA.
  • Siga la ruta de navegación de su software (AUT).
  • Familiarízate con AUT.
  • Ahora lea los casos de prueba (Todos) de cualquier módulo en particular (Tal vez de su elección).
  • Ahora vaya al AUT y haga coincidir los hallazgos con los mencionados en la sección esperada de los casos de prueba.
  • La idea detrás de esto es probar todas las funciones mencionadas en todas las plataformas compatibles.
  • Tome nota de cada desviación, por trivial que parezca.
  • Escriba los pasos para llegar a cualquier desviación, tome capturas de pantalla, capture registros de errores, registros del servidor y cualquier otra documentación de respaldo que pueda probar la existencia de defectos.
  • No dudes en preguntar. Aunque tiene el documento de requisitos, habrá ocasiones en las que tendrá dudas.
  • Comuníquese con los desarrolladores (si se sientan a su lado o si están disponibles) en duda antes de comunicarse con el propietario del producto. Comprenda la perspectiva del desarrollador sobre el funcionamiento del software. Entiéndelos. Si cree que esta implementación no cumple con los requisitos, informe al administrador de pruebas.

# 5) Antes del lanzamiento

Antes de lanzar cualquier producto al mercado, se debe garantizar la calidad del producto. Los software se desarrollan una vez, pero en realidad se prueban hasta que se reemplazan o eliminan.

Desafíos

El software debe probarse rigurosamente para muchos de sus parámetros.

Los parámetros pueden no limitarse a:

  • Funcionalidad / Comportamiento.
  • Rendimiento.
  • Escalabilidad.
  • Compatible con dichas plataformas.

El desafío también es predecir la tasa de éxito de una aplicación que depende de muchas iteraciones de las pruebas realizadas.

Mejores prácticas

  • Asegúrese de que se prueben todas las funciones en todas las plataformas.
  • Resalte las áreas que no se prueban o la que necesita más esfuerzos de prueba.
  • Mantenga una matriz de todos los resultados de las pruebas antes de su publicación. La matriz de prueba dará una imagen general de la estabilidad del producto. También ayudará a la gerencia a tomar una llamada sobre las fechas de lanzamiento.
  • Proporcione sus comentarios / sugerencias al equipo sobre sus experiencias mientras prueba el producto.
  • Su aportación, considerándose a sí mismo como el usuario final, beneficiará al software en general.
  • Debido a la falta de tiempo o cualquier otra situación similar, nos perdemos algunas pruebas o no profundizamos en esto. No dude en informarle a su jefe sobre el estado de la prueba.
  • Presentar la tarjeta sanitaria de la aplicación a los interesados. Las tarjetas de salud deben tener una cantidad de todos los defectos registrados, abiertos, cerrados e intermitentes con su gravedad y prioridad.
  • Redacte un documento de lanzamiento y compártelo con el equipo.
  • Trabajar en el documento de liberación preparado.
  • Mejorar las áreas sugeridas por la dirección / equipo.

La siguiente imagen muestra el mapa del ciclo de vida de la versión del software:

Antes del lanzamiento

# 6) Lanzamiento

Finalmente, llega el momento en que tenemos que entregar el producto a los usuarios previstos. Todos, como equipo, hemos trabajado duro para aprobar el producto y dejar que el software ayude a sus usuarios.

Desafíos

Los ingenieros de pruebas de software son los principales responsables del lanzamiento de cualquier software. Esta actividad requiere un flujo de trabajo orientado a procesos. Estas son algunas de las mejores prácticas involucradas en esta fase.

Mejores prácticas

  • Recuerde siempre que no está trabajando en el documento de publicación en la fecha de la AUTORIZACIÓN REAL.
  • Siempre planifique la actividad de lanzamiento antes de la fecha de lanzamiento real.
  • Estandarice el documento según las políticas de la empresa.
  • Su documento de lanzamiento debe intentar establecer expectativas positivas del software.
  • Mencione claramente todos los requisitos de software y hardware específicos de sus versiones en el documento.
  • Incluya todos los defectos abiertos y su gravedad.
  • No oculte las principales áreas impactadas debido a defectos abiertos. Dales un lugar en el documento de lanzamiento.
  • Obtenga el documento revisado y firmado digitalmente (puede diferir según la política de la empresa).
  • Tenga confianza y envíe el documento de lanzamiento junto con el software.

Proceso de prueba de control de calidad en un proyecto real: método en cascada

Recibí una pregunta interesante de un lector, ¿Cómo se realizan las pruebas en una empresa, es decir, en un entorno práctico?

Aquellos que acaban de salir de la universidad y comienzan a buscar trabajo tienen esta curiosidad: ¿cómo sería el entorno laboral real en una empresa?

Aquí me he centrado en el proceso de trabajo real de Testing de software en las empresas .

Proceso de prueba real en empresas

Siempre que recibimos un nuevo proyecto, hay una reunión inicial de familiaridad con el proyecto. En esta reunión, básicamente discutimos ¿quién es el cliente? ¿Cuál es la duración del proyecto y cuándo se entrega? ¿Quiénes están involucrados en el proyecto, es decir, el gerente, los líderes de tecnología, los líderes de control de calidad, los desarrolladores, los probadores, etc.?

A partir del plan de proyecto SRS (especificación de requisitos de software) se desarrolla. La responsabilidad de los probadores es crear un plan de prueba de software a partir de este SRS y el plan del proyecto. Los desarrolladores comienzan a codificar desde el diseño. El trabajo del proyecto se divide en diferentes módulos y estos módulos del proyecto se distribuyen entre los desarrolladores.

Mientras tanto, la responsabilidad de un evaluador es crear un escenario de prueba y escribir casos de prueba de acuerdo con los módulos asignados. Intentamos cubrir casi todos los casos de prueba funcional de SRS. Los datos se pueden mantener manualmente en algunas plantillas de casos de prueba de Excel o herramientas de seguimiento de errores.

Cuando los desarrolladores terminan los módulos individuales, esos módulos se asignan a los probadores. Las pruebas de humo se realizan en estos módulos y, si fallan en esta prueba, los módulos se reasignan a los desarrolladores respectivos para una solución.

Para los módulos aprobados, las pruebas manuales se llevan a cabo a partir de los casos de prueba escritos. Si se encuentra algún error que se asigna al desarrollador del módulo y se registra en el herramienta de seguimiento de errores . En la corrección de errores, un probador realiza la verificación de errores y pruebas de regresión de todos los módulos relacionados. Si el error pasa la verificación, se marca como verificado y cerrado. De lo contrario, se repite el ciclo de errores mencionado anteriormente. (Cubriré el ciclo de vida de los errores en otra publicación)

Se realizan diferentes pruebas en módulos individuales y pruebas de integración en la integración de módulos. Estas pruebas incluyen pruebas de compatibilidad, es decir, probar aplicaciones en diferentes hardware, versiones de SO, plataformas de software, diferentes navegadores, etc.

Las pruebas de carga y estrés también se llevan a cabo de acuerdo con SRS. Finalmente, la prueba del sistema se realiza mediante la creación de un entorno de cliente virtual. Una vez que se ejecutan todos los casos de prueba, se prepara un informe de prueba y se toma la decisión de lanzar el producto.

Pasos en los requisitos para publicar

A continuación se muestran los detalles de cada paso de prueba que se lleva a cabo en cada calidad de software y ciclo de vida de prueba especificado por Estándares IEEE e ISO.

#1) Revisión de SRS : Revisión de las especificaciones de requisitos de software.

# 2) Objetivos están configurados para versiones principales.

# 3) Fecha objetivo planeado para los lanzamientos.

# 4) Plan detallado del proyecto está construído. Esto incluye la decisión sobre especificaciones de diseño.

# 5) Desarrolle un plan de prueba se basa en especificaciones de diseño.

# 6) Plan de prueba: Esto incluye los objetivos, la metodología adoptada durante la prueba, las características que se probarán y no se probarán, los criterios de riesgo, el calendario de pruebas, el soporte multiplataforma y la asignación de recursos para las pruebas.

# 7) Especificaciones de prueba: Este documento incluye detalles técnicos (requisitos de software) necesarios antes de la prueba.

# 8) Redacción de casos de prueba

  • Fumar ( BVT ) Casos de prueba
  • Casos de prueba de cordura
  • Casos de prueba de regresión
  • Casos de prueba negativos
  • Casos de prueba extendidos

# 9) Desarrollo: Los módulos se desarrollan uno a uno.

# 10) Enlace de instaladores: Los instaladores se basan en el producto individual.

empresas de internet de las cosas para ver

#11) Procedimiento de construcción : Una compilación incluye instaladores de los productos disponibles: múltiples plataformas.

# 12) Prueba: Prueba de humo (BVT): prueba de aplicación básica para tomar una decisión sobre pruebas adicionales.

  • Prueba de nuevas funciones
  • Navegador cruzado y pruebas multiplataforma
  • Pruebas de estrés y pruebas de fuga de memoria.

#13) Informe de resumen de la prueba

#14) Congelación de código

  • No se agregan más funciones nuevas en este momento.

# 15) Prueba: Pruebas de compilación y regresión.

#16) Decisión de liberar el producto.

#17) Escenario posterior al lanzamiento para otros objetivos.

Este fue un resumen de un proceso de prueba real en un entorno empresarial.

Conclusión

El trabajo de un probador de software está lleno de desafíos, pero uno agradable. Esto es para alguien que es igualmente apasionado, motivado y lleno de entusiasmo. ¡Encontrar fallas en alguien no siempre es un trabajo fácil! Esto requiere mucha habilidad y una diana para los defectos.

Además de todas las cualidades, un probador también debe estar orientado al proceso. Como todas las demás industrias, los proyectos en TI también se trabajan en fases, donde cada fase tiene algunos objetivos bien definidos. Y cada objetivo tiene un criterio de aceptación bien definido. Un ingeniero de pruebas tiene que cargar con muchas cargas de calidad de software sobre sus hombros.

Al trabajar en cualquier fase del software, se supone que los probadores deben seguir las mejores prácticas y alinearse con el proceso involucrado en las respectivas fases. Seguir las mejores prácticas y un proceso bien formulado no solo ayuda a facilitar el trabajo de los probadores, sino que también ayuda a garantizar la calidad del software.

¿Ha sido parte de alguna de las fases anteriores? No dude en compartir sus experiencias a continuación.

Lectura recomendada

^