Menú

Implementación práctica de 7 pasos de pruebas manuales antes del lanzamiento de producción

7 step practical implementation manual testing before production release

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

En la publicación anterior de esta serie sobre las pruebas manuales, traté de arrojar la mayor cantidad de luz posible sobre los conceptos básicos de las pruebas manuales.

Si te lo perdiste Puede leerlo aquí .

Espero que haya tenido éxito al acercarlo lo más posible a las respuestas que estaba buscando.

En ese caso, ¿no le encantaría saber más sobre la implementación práctica de las pruebas manuales, cómo familiarizarse con él y cómo comenzar una carrera en él?

Este artículo arrojará luz sobre todos estos aspectos.

Implementación de pruebas manuales

Empecemos.

Lo que vas a aprender:

Ciclo de prueba manual

Comprender Ciclo de prueba manual o Ciclo de vida de prueba de software (STLC), en primer lugar, debemos comprender el Ciclo de vida de desarrollo de software (SDLC), que estoy seguro de que ya conoce.

La gente se refiere a ellos por separado, pero no está segura de si realmente pueden coexistir. Están tan estrechamente integrados entre sí. Bueno, incluso estos ciclos tienen tantas versiones de ellos creadas y flotando en el espacio de Internet, que varían principalmente según el modelo de desarrollo que se seleccione.

Como la mayoría de el mundo se está volviendo ágil En estos días, mantendré mis cosas simplificadas en torno a Agile.

7 pasos prácticos de prueba manual antes del lanzamiento de producción

Aquí voy.

Recuerde que estoy hablando tanto de SDLC como de STLC.

# 1) Reunión de requisitos

Fase de reunión de requisitos

Business Analyst (persona / equipo responsable de la recopilación de requisitos) documenta los requisitos. Documentan los requisitos, eso es lo más destacado, puede concentrarse solo en eso. Donde está documentado importa menos.

Las personas usan cualquier cosa para documentarlos que les convenga, pero no se limitan a plataformas tradicionales como MS Word doc, plataformas modernas como Jira / Rally y herramientas de la nueva era como Trello.

# 2) Discusión / intercambio de requisitos

Fase de discusión de requisitos

Luego, se supone que Business Analyst debe compartir los requisitos documentados con el equipo de desarrollo, el equipo de pruebas y el equipo de UX (si es necesario). Esto suele suceder a través de una reunión formal en la que los SPOC (punto de contacto único o un equipo completo, depende) de las tres funciones cumplen y comprenden todo el requisito.

En una cultura de trabajo saludable, los requisitos se discuten desde todos los ángulos y cada miembro de la reunión puede hacer preguntas y dudas. Una vez que se hayan respondido todas las preguntas y se haya realizado la modificación necesaria en el requisito, esta fase se puede considerar terminada. Nuevamente, lo que uno llama esta reunión / paso en particular y su documentación difieren de una compañía a otra.

Otras lecturas=> Cómo revisar el documento SRS

Una vez que se responden todas las preguntas y se realizan las modificaciones necesarias en el requisito, esta fase se puede considerar como Hecho .

Nuevamente, lo que uno llama esta reunión / paso en particular y su documentación difieren de una compañía a otra.

Por ejemplo, la documentación se llama o se desglosa como SRS (Especificación de requisitos del sistema), Documento de requisitos, Épica, Historia de usuario, Punto de historia (posiblemente, la unidad de requisitos más pequeña), etc. En líneas similares, esta reunión en la que se comparte el requisito se llama como Reunión de discusión de requisitos, preparación, reunión de perforación, etc., ¿espero que entiendas mi punto?

Al presionar estas terminologías para que siempre recuerde la idea principal independientemente de los diferentes nombres.

Publicar esta reunión se activan dos pasos al mismo tiempo, sin ningún orden en particular, consulte los dos pasos siguientes.

# 3) Diseño

El equipo de desarrollo comienza con su diseño técnico tan pronto como se discuten los requisitos y cuando no hay puntos importantes pendientes. Lo que se hace en esta fase de nuevo difiere de una empresa a otra.

Esta fase puede incluir, entre otras, las siguientes tareas:

  • Decidir el enfoque de desarrollo
  • Preparando documento de diseño
  • Diseñar los diagramas de flujo
  • Estimando los esfuerzos
  • Averiguar el impacto de este nuevo requisito en cualquier funcionalidad existente
  • Necesita parchear datos existentes, etc.

El equipo de UX también puede involucrarse en esta fase cuando hay un cambio en la interfaz de usuario o se va a desarrollar una nueva pantalla. El equipo de UX ayuda al equipo de desarrollo y al equipo de pruebas con el prototipo de UI para la funcionalidad / característica en la discusión. Puede ser un documento de Photoshop, una imagen simple, una presentación de PowerPoint o cualquier otra cosa que haga que el equipo de desarrollo comprenda cómo se deben desarrollar las pantallas.

Nota: Idealmente, estas pantallas o al menos sus versiones preliminares, se muestran en la sesión de discusión de requisitos solo para ayudar al equipo a construir una mejor comprensión. Se etiqueta con el requisito original para que se pueda consultar en cualquier momento.

# 4) Diseño de escenario de prueba / caso de prueba

Escenario de prueba Fase de diseño

Paralelamente a la fase de diseño, el equipo de pruebas comienza con la creación de escenarios de prueba y / o casos de prueba basados ​​en los requisitos discutidos. Si los escenarios de prueba siempre se escriben primero y luego se dividen en casos de prueba es algo que nuevamente no es constante.

En mi opinión, ya sea que documente los escenarios de prueba o no, siempre están ahí antes de los casos de prueba. El escenario de prueba es su punto de viñeta que puede decir, lo guían para profundizar más en las cosas. Una vez que finaliza la redacción del caso de prueba, se puede compartir con el equipo de Desarrollo para darles una idea del alcance de la prueba y también pueden asegurarse de que el desarrollo que ha sucedido o está sucediendo satisface los casos de prueba escritos.

Una vez que finaliza la redacción del caso de prueba, se puede compartir con el equipo de Desarrollo para darles una idea del alcance de la prueba y también pueden asegurarse de que el desarrollo que ha sucedido o está sucediendo satisface los casos de prueba escritos.

Los casos de prueba, una vez escritos, idealmente son revisados ​​por un líder de prueba o un compañero desde muchos ángulos como:

  • Cobertura de requisitos
  • Gramática ortográfica
  • Estándares de escritura de casos de prueba (nada más que una plantilla que sigue un equipo / empresa)
  • Compatibilidad con versiones anteriores
  • Compatibilidad de plataforma
  • Referencias de datos de prueba
  • Tipos de pruebas dirigidas, etc.

Otras lecturas=> Redacción de casos de prueba a partir del documento SRS

Idealmente, solo después de la revisión y la modificación necesaria, se transmiten al equipo de desarrollo.

Cuando dije 'una vez que termine la escritura de casos de prueba', quise decir una vez 'todos los casos de prueba se escriben en función del conocimiento completo de un requisito dado y posibles escenarios de prueba descubiertos hasta ese momento en particular'. Es casi imposible tener una cobertura de casos de prueba del 100% a la primera.

Habrá defectos que encontrará en acciones aleatorias (pero intencionadas), en acciones puramente aleatorias (prueba de monos) y en algunos escenarios raros. Hay posibilidades de que se pierda algunos de estos. Y en algún momento podrías perderte incluso los más básicos, después de todo, eres humano. Pero aquí, al menos una buena revisión de casos de prueba y una forma estructurada de redacción de casos de prueba pueden salvarlo.

La mayoría de las veces, un evaluador o un equipo de pruebas sigue agregando más y más casos de prueba al fragmento existente a medida que descubren la verdad o piensan más en los requisitos.

Bueno, a estas alturas algunos de ustedes deben estar dudando de mi conocimiento de las pruebas de software, ya que todavía no uso alguna palabra (que se ha convertido en una norma en las pruebas de software). Plan de prueba, ¿verdad?

Déjame decirte algo sobre esto. Creo firmemente en la necesidad de la mayor parte de la información que se menciona en el Plan de prueba, pero documentarlos todos en el mismo lugar y hacerlo absolutamente obligatorio es algo que encuentro discutible.

De todos modos, ese es un tema completamente separado para discutir. Compartir una información 'adecuada para todos' sobre esto es difícil, pero déjame intentarlo.

Usted, usted con su cable de prueba o su cable de prueba preparan el Plan de prueba o documentan la información requerida en diferentes lugares.

Otras lecturas=> Cómo escribir el documento del plan de prueba

Información que debería estar absolutamente congelada en esta etapa:

  • El alcance de las pruebas: Requisito, compatibilidad con versiones anteriores, plataformas, dispositivos, etc.
  • Persona / Equipo que va a probar
  • Estimación del esfuerzo de prueba
  • Limitaciones: Cualquier suposición hecha o limitaciones aceptadas de antemano.
  • Las personas también documentan los criterios de entrada, los criterios de salida, el riesgo, etc., lo que creo que realmente no necesita una mención separada, ya que debería ser un entendimiento normal.
    • Criterio para entrar (Cuándo comenzar a probar): pocos comienzan cuando hay una parte comprobable de la funcionalidad disponible para probar. Pocos esperan a que se pueda probar la funcionalidad completa. Una vez que se determina que el flujo básico funciona, comienza la prueba.
    • Criterio de salida (Cuándo detenerse): cuando no hay bloqueador, se pueden detener los defectos críticos y mayores (sujetos a impacto) en las pruebas de etapa abierta. O, a mitad de camino, cuando se enfrentan demasiados defectos, las partes interesadas adecuadas pueden detener las pruebas.
    • Riesgo : Riesgo empresarial o riesgo funcional si las pruebas no se realizan según el plan documentado.

# 5) Fase de desarrollo

Fase de desarrollo de software

El equipo de desarrollo, después de la fase de diseño, comienza con el desarrollo real y las pruebas unitarias a medida que terminan con el desarrollo de fragmentos de requisitos comprobables. Pueden transmitir la funcionalidad para realizar pruebas en fragmentos a medida que se implementa o pueden transmitir toda la funcionalidad a la vez.

En un escenario ideal, la revisión formal del código y las pruebas de caja blanca ocurren antes de transferir la funcionalidad desarrollada para Pruebas. idealmente, el equipo de desarrollo también debería consultar los casos de prueba proporcionados por el equipo de pruebas, además de los requisitos y los documentos de diseño.

# 6) Fase de prueba

Como se mencionó anteriormente, el inicio de esta fase difiere de una empresa a otra, de un equipo a otro.

El equipo de pruebas comienza a probar cuando se puede probar (algo que se puede probar de forma independiente) cuando se desarrolla parte de todo el requisito o cuando se desarrolla todo el requisito.

jms preguntas y respuestas de la entrevista para experimentados

Permítanme profundizar más en esta fase y hablar sobre las tareas importantes:

  • El equipo de prueba / prueba comienza con la ronda de prueba (prueba exploratoria y ejecución de casos de prueba escritos) y los defectos de registro
  • El equipo de desarrollo los resuelve según su prioridad.
  • La nueva compilación (código) se toma en el entorno en el que se están realizando las pruebas
  • Los defectos resueltos son luego verificados por Tester / Testing Team y marcados como Fixed
  • Este ciclo continúa hasta que se alcanza el criterio de salida de tiempo.
  • Tenga en cuenta que, según sea necesario, los defectos también se marcan como no válidos, duplicados y también se pueden clasificar como mejoras.

Otra cosa que difiere de una empresa a otra es la cantidad de rondas de prueba que se deben realizar. Como en algunos casos, la primera ronda de pruebas se realiza en piezas de características pequeñas cuando están listas, seguida de una ronda de pruebas de un extremo a otro en otro entorno una vez que se desarrollan todos los requisitos. Pero, de nuevo, también he oído hablar de personas que realizan tres rondas de prueba completas adecuadas y la cuarta como ronda de cordura / humo.

La primera agenda detrás de la realización de múltiples rondas de prueba es probar la funcionalidad en diferentes entornos y la segunda, realizar pruebas de extremo a extremo una vez que se hayan desarrollado todos los puntos de la historia. La ronda de cordura suele ganar confianza rápidamente una vez que todas las historias de un lanzamiento se desarrollan y prueban de forma independiente.

Leer pasos detallados=> Fase de ejecución de la prueba

# 7) Revisión de analista de negocios (BA)

El analista de negocios revisa la funcionalidad solicitada, ya sea refiriéndose al resultado de la prueba o refiriéndose al resultado de la prueba, además de jugar con la aplicación para tener una idea real. Este paso nuevamente está sujeto a diferentes acciones entre empresas.

El BA puede revisar el alcance del lanzamiento completo de una sola vez o por partes. Dependiendo de lo mismo, este paso puede ocurrir antes de la prueba de cordura final o después de la ronda de prueba de cordura final por parte del equipo de pruebas.

Los 7 pasos anteriores suceden para que se cumplan todas las historias / requisitos de usuario, en particular la Liberación (Envío). Una vez que se completan todos estos pasos para todos los requisitos, se dice que la versión está lista para su envío.

# 8) Envío / Liberación

El lanzamiento está etiquetado como Listo para envío después de una revisión exitosa por parte del Analista de negocios.

Lectura recomendada=> Proceso de lanzamiento de prueba

Tipos de pruebas manuales (leídas en humanos)

Bueno, si tenemos que hablar sobre tipos generales de pruebas en números, entonces encontré en algún lugar 100 tipos de pruebas con diferentes nombres . Para ser honesto, no soy lo suficientemente inteligente como para comprender la distinción entre todos esos tipos (juego de palabras).

Es simple y directo: Probar la funcionalidad de la aplicación contra el requisito dado con esfuerzo e inteligencia humanos. Se divide aún más en algunos tipos según el alcance y la agenda de las pruebas. Tipos enumerados en el próximo párr.

Se divide aún más en algunos tipos según el alcance y la agenda de las pruebas. Tipos enumerados en el próximo párr.

Si se me permite, permítanme hablar algunas líneas de Pruebas en humanos (que animo a todos los probadores a hacer en lugar de pruebas funcionales manuales). Ahora no se confunda, en mi opinión, las pruebas funcionales manuales son un subconjunto de las pruebas en humanos. Porque hay tantas cosas que solo la mente humana puede hacer.

A continuación se muestra la lista con algunos de los tipos de pruebas más populares e importantes que se pueden clasificar en Pruebas en humanos:

  • Prueba funcional manual : Probar la funcionalidad de la aplicación contra el requisito dado con esfuerzo e inteligencia humanos. Además, se divide en bastantes tipos según el alcance y la agenda de las pruebas, como pruebas de sistemas, pruebas unitarias, pruebas de humo, pruebas de cordura, pruebas de integración, pruebas de regresión, pruebas de UI, etc.
  • Pruebas de rendimiento : Esto se clasifica en pruebas no funcionales, ¿verdad? Pero, nuevamente, es el humano quien lo implementa, aunque la ejecución la realiza un humano o una herramienta. El probador debería al menos hacer esta prueba en términos de tiempo de respuesta (para ver si es aceptable) si no se supone que debe usar ninguna herramienta para las pruebas de carga y todo.
  • Navegador / Prueba de compatibilidad de plataforma: La aplicación bajo prueba debe verse y funcionar como se espera (obviamente, puede haber una pequeña diferencia dependiendo del motor del navegador) entre navegadores y plataformas (o dispositivos si es una aplicación móvil).
  • Pruebas de usabilidad : Permítanme estar de acuerdo en primer lugar en que este es un tema enorme en sí mismo y generalmente es propiedad de especialistas en pruebas de usabilidad. Sigo creyendo que como tester deberíamos al menos informar o resaltar si encontramos algo menos utilizable, o deberíamos compartir nuestra opinión.
  • Pruebas de seguridad : Una vez más, un tipo de prueba muy grande y, por supuesto, requiere mucho conocimiento práctico. El evaluador debe intentar aprender y ejecutar al menos pruebas básicas como manipulación de URL, secuencias de comandos entre sitios, inyección de SQL, secuestro de sesiones, etc., según los conocimientos disponibles y donde corresponda.
  • Prueba de tenencia múltiple: Si su aplicación es multiinquilino, es decir, una única instancia que contiene datos de varios clientes, entonces esta prueba es imprescindible. Independientemente de la mención explícita en los requisitos, esto debe hacerse. La información de un cliente que se muestra a otro es una especie de delito de desarrollo y prueba.

Nota: Las vistas anteriores son mis opiniones personales. También te recomiendo que eches un vistazo a la extensa lista de tipos de pruebas para tu conocimiento y los sigas / utilices si lo consideras necesario. Durante años he entendido que si usas algo o no, crees en algo o no, aún debes tener algún conocimiento de conceptos ampliamente usados ​​en tu campo.

Eso es todo por esta parte. Gracias por leer. Comparta sus opiniones / comentarios en los comentarios.

En la próxima y última parte de este serie de tutoriales de pruebas manuales , Intentaré ayudarlos a todos con qué preparación debe hacer si desea ingresar al campo de las pruebas y cuáles son las posibles formas de hacerlo.

Lectura recomendada

^