Ciclo de vida del defecto: como ya sabrá, la ejecución de la prueba es la fase en la que el probador realmente estaría ejecutando los scripts de prueba. El proceso de ejecución de los scripts de prueba varía de una compañía a otra y también puede ser diferente en diferentes proyectos dentro de la misma compañía.
Hoy en día hay herramientas disponibles para la ejecución de pruebas, herramientas como: Quality Center, Microsoft Visual Studio, etc. El proceso de ejecución real de realizar cada paso para comparar el resultado real y el esperado sigue siendo el mismo para el probador funcional, independientemente de las herramientas utilizadas.
- ¿Qué pasa si el comportamiento real no es igual al comportamiento esperado?
Cuando un probador encuentra que el resultado real de la prueba no es igual al resultado esperado, se registra un defecto.
- ¿Cómo registrar un defecto?
Hay muchas herramientas disponibles hoy en día, algunas de las herramientas de registro de defectos son ClearQuest de IBM, el Centro de calidad de HP, herramientas de código abierto como el ciclo de vida de defectos en JIRA, etc.
Hay algunos de los campos obligatorios que son comunes en las diversas herramientas de registro de defectos, estos campos son:
- Descripción del ciclo de vida del defecto
- Resumen del ciclo de vida del defecto
- Defecto registrado por
- Defecto asignado a
- Severidad del defecto
- Prioridad de defecto
- Instantáneas adicionales
- Número de lanzamiento / Nombre
Defecto ciclo de vida
Defecto El ciclo de vida comienza desde el registro de un nuevo defecto. Cada vez que se registra un defecto, pasa al estado "Nuevo".
Probador - Nuevo defecto
¿A quién asignar un nuevo defecto?
Un probador puede asignar un defecto a un desarrollador o un líder de desarrollo. Esta decisión de asignación de defectos varía de un proyecto a otro. En algunos lugares de trabajo existe un proceso de ciclo de vida de defectos para asignarlo directamente a un desarrollador respectivo y en algunos lugares el defecto se asigna primero a un líder de desarrollo y el líder de desarrollo a su vez lo asigna a un desarrollador.
Asignación de defectos (nuevo): desarrollador de ciclo de vida de defectos
Asignación de defectos (nuevo) - Dev Leadà Developer
Análisis de defectos
El desarrollador analizará el defecto para verificar si es reproducible. Aquí, la contribución más importante del probador es incluir todos los detalles necesarios en el defecto. Resumen del defecto, la descripción detallada del defecto son los campos que ayudan a las partes interesadas a comprender el defecto de una vez. Resumen de defectos siempre debe tener solo la información de alto nivel del defecto. Al mismo tiempo, debe tener información suficiente para describir la descripción general del defecto en una línea.
La descripción del defecto es el lugar donde se espera que el probador incluya toda la información necesaria, como el entorno, el escenario, los datos de prueba utilizados, el resultado esperado, el resultado real, la referencia a archivos / datos y la referencia a la instantánea.
Aquí está la breve descripción de varios elementos de la Descripción detallada del defecto:
Ambiente
Pruebe el entorno donde se encontró el defecto. A menudo, los proyectos tienen múltiples entornos de prueba donde el equipo de prueba realiza las pruebas. Por ejemplo: AT (entorno de prueba de ensamblaje), PT (entorno de prueba de producto), UAT (entorno de prueba de aceptación del usuario), etc. El propósito de tener varios entornos es que proporciona flexibilidad dentro del equipo de desarrollo y prueba para implementar el código en cualquiera de los entornos disponibles para comenzar las pruebas a tiempo.
Hay momentos en que la prueba del producto (también llamada prueba del sistema) y las pruebas de UAT se superponen, por lo tanto, es necesario tener múltiples entornos para continuar las pruebas en paralelo.
Hay casos en que el equipo de desarrollo necesita un entorno adicional para depurar los problemas informados por el equipo de prueba. Además, el equipo de desarrollo tiene un entorno dedicado para la tarea de prueba de la unidad.
Por lo tanto, con múltiples entornos, es necesario mencionar en el defecto un entorno particular donde se encontró el problema.
Guión
El escenario es el conjunto de pasos realizados por el probador que condujo a un defecto. Aquí se espera que un probador mencione todos los pasos que el desarrollador puede realizar para reproducir el defecto. A menudo hay ocasiones en que el probador informa el defecto, pero el desarrollador no puede replicarlo y, por lo tanto, el defecto se rechaza. Esto puede suceder debido a pasos incorrectos / pasos faltantes mencionados en la descripción. Los pasos claros ayudan a todos a comprender el defecto y replicarlo sin tener la dependencia de comunicarse con un probador para obtener entradas. Un escenario bien documentado tiene pasos fáciles de leer, fáciles de entender y precisos que se deben seguir para replicar el defecto.
Datos de prueba
Se supone que un probador debe mencionar los datos utilizados durante el flujo de las pruebas que condujeron a un problema. Esta información le da al desarrollador la oportunidad de usar datos similares para reproducir el defecto y encontrar la causa raíz del mismo.
Hay algunos escenarios en los que un probador encuentra un defecto usando datos específicos, pero el mismo problema no es reproducible usando datos similares. Esto puede ocurrir debido a la corrupción de datos, por lo tanto, ingresar datos da la oportunidad de descubrir la causa raíz del defecto. Un desarrollador podría no excavar hasta el nivel de código si el caso es corrupción de datos. Este tipo de defecto se puede convertir en defecto de datos.
Resultado esperado y real
Este es el punto culminante del campo de descripción detallada donde un probador prueba que el error encontrado es de hecho un defecto. Mencionar claramente el resultado esperado aclara las cosas para que cada parte interesada considere el error como un defecto. ¡Imagine que se registra un defecto con todos los detalles pero no especifica el resultado esperado del escenario!
Por lo general, un probador ingresa solo el resultado esperado, puede estar en una línea o dos, sin embargo, es muy importante mencionar la fuente del resultado esperado. Fuente aquí referencia al documento donde se menciona el resultado esperado. Esto podría ser un documento de requisitos o una referencia de guión gráfico.
Referencia a archivos / datos
A veces, el defecto implica la generación de un archivo o entrada como un archivo. En este tipo de escenarios, se supone que el probador proporciona información del archivo que se utilizó y que causó el problema en la aplicación. Estos archivos se pueden adjuntar utilizando la herramienta de gestión de defectos o se puede proporcionar la referencia para los mismos. Estas ubicaciones de referencia deben ser accesibles para todos los interesados.
Referencia a la instantánea
Las instantáneas juegan un papel muy importante cuando desea mostrarles el mensaje exacto de error de salto de página tal como se muestra en la pantalla o cuando desea mostrar los detalles de navegación de la pantalla. Instantánea da una idea rápida sobre el defecto encontrado, la pantalla en la que se encontró el defecto, los datos utilizados en la pantalla, etc. Todas las herramientas de gestión de defectos tienen disposiciones para adjuntar las instantáneas. A veces, el probador también puede adjuntar las hojas de cálculo de Excel o documentos de Word.
Estos fueron los diversos componentes del registro de defectos y las mejores prácticas para cada uno de ellos. Volviendo al ciclo de vida del defecto, una vez que el defecto se asigna a un desarrollador, él / ella lo analizará utilizando los datos proporcionados en el elemento del defecto. Si según el análisis, el problema registrado es de hecho un defecto, el desarrollador "abrirá" el defecto para trabajar en su solución.
Cursos recomendados
- Paquete de entrenamiento de servicios web en Java
- Capacitación sobre desarrollo de juegos en C ++
- Entrenamiento de piratería ética completa
- Vegas Pro 13 Cursos de formación
Nuevo abierto
Un defecto en el estado Abierto muestra que está en la placa de desarrollo y los desarrolladores están trabajando en su solución. En caso de que el análisis descubra que el problema registrado no es un defecto, esto puede suceder cuando hay una brecha de comprensión en el comportamiento esperado del sistema. Si el análisis dice que el defecto no es válido, el desarrollador rechazará el defecto. La terminología es "Rechazada" o "Regresar a las pruebas".
Nuevo: volver a las pruebas.
¿Cómo debe validar el probador si el defecto fue realmente un defecto no válido?
Este es el escenario en el que un documento de requisitos precisos ayuda a todos los miembros del equipo a llegar a una conclusión si el defecto registrado es inválido o válido. Hacer referencia a los documentos de requisitos ayuda al evaluador y al desarrollador a llegar a la misma conclusión y realmente facilita el proceso de discusión.
Hay escenarios en los que se cuestiona la exactitud del diseño y los documentos de requisitos al referirse a estos documentos en momentos de discusiones de defectos, en esos momentos volver a Business Analyst se considera la mejor opción para aclarar las consultas.
Como práctica recomendada, los documentos de requisitos y diseño siempre deben estar actualizados para poder remitirlos sin ambigüedades.
En el estado "Abierto", el equipo de desarrollo trabaja en la reparación del defecto, una vez que el defecto se arregla, el estado cambia a "Listo para la implementación".
Abierto - Listo para el despliegue
La implementación es el proceso donde los cambios se cargan en el servidor para que el equipo de prueba pueda trabajar en la versión fija del código. Por lo general, cada proyecto tiene un equipo de implementación separado para esta tarea.
Entonces, en un nivel alto, un equipo de software consiste principalmente en estos 3 grupos:
- Desarrollo
- Defecto del ciclo de vida en las pruebas
- Despliegue (o a veces llamado como equipo de construcción)
Una vez que se despliega la compilación y el defecto vuelve a estar disponible para volver a probar, se asigna a un probador apropiado para la tarea de reevaluación.
Defecto asignado a - Cable de prueba.
Test Lead - Probador individual.
Defecto asignado - Probador individual.
En algunos lugares de trabajo, el defecto se asigna primero al Líder de prueba y él / ella a su vez lo asigna al probador individual; sin embargo, en algunos lugares, el defecto se asigna directamente al probador que lo probaría o al que lo había planteado.
El estado aquí cambia de Listo para el despliegue - Listo Prueba SIT.
Ahora el defecto está en la placa del probador. El equipo de prueba validará el defecto y hay 2 posibilidades, la solución funcionaría correctamente o el mismo problema se encuentra nuevamente. Dependiendo del defecto del resultado puede pasar a los siguientes estados:
Listo Prueba SIT - Cerrado
Listo Prueba SIT - Reabrir
En ambos escenarios anteriores, se requiere que el probador agregue los comentarios de las pruebas realizadas. Esto incluye mencionar los escenarios probados y los datos utilizados. Si se vuelve a abrir el defecto, el probador debe proporcionar los pasos exactos realizados que nuevamente condujeron al error.
El estado de reapertura es el mismo que el estado de defecto "Nuevo".
Una vez que el defecto se vuelve a abrir, seguirá el mismo ciclo nuevamente.
Defectos del ciclo vital
- Decidir sobre la gravedad del defecto: este es uno de los temas comunes de discusión (a menudo peleas) entre los probadores v / s desarrolladores.
- El defecto no es reproducible en el sistema del desarrollador.
- Defecto planteado en el escenario que no se menciona en los requisitos y documentos de diseño.
- Se encuentra el defecto pero no se puede plantear lo mismo ya que la ocurrencia del escenario en el entorno de producción no es factible.
¿Cómo un probador debe superar los desafíos anteriores?
- La gravedad es directamente proporcional al impacto que el defecto está causando en la aplicación, si el probador no puede continuar debido al defecto, seguramente está marcado con la mayor severidad.
- Si existe una solución alternativa para continuar con las pruebas, debe marcarse como de gravedad media. Además de considerar el impacto de otras pruebas del ciclo de vida del defecto, la gravedad también se puede decidir considerando la situación en la que falla un módulo completo, en este caso, aunque la prueba de otro módulo se puede llevar a cabo pero la gravedad del módulo actual es alta entonces el defecto debe ser marcado con la mayor severidad.
- Si un defecto no es reproducible en el sistema del desarrollador, hay posibilidades de que el entorno de desarrollo y prueba no estén sincronizados. Un defecto reproducible en el sistema de prueba siempre se considera un defecto válido.
- Hay situaciones en las que se registra un defecto teniendo en cuenta el escenario comercial general, pero el escenario directo no se menciona en los requisitos o en el documento de diseño. Siempre se considera una práctica recomendada considerar los escenarios empresariales reales en lugar de simplemente seguir los pasos de la prueba. La comunicación con analistas de negocios y otras partes interesadas del producto juega un papel importante para registrar tales defectos.
- Hay situaciones en las que un probador descubre una brecha en la lógica empresarial durante la fase de prueba. Encontrar estas brechas nuevamente se considera una gran ventaja para un probador. Las brechas de diseño generalmente se manejan a través de mejoras.
- Mejora: si es necesario cambiar un comportamiento durante la fase de prueba del ciclo de vida del software, se crea una mejora que puede tomarse en la versión actual o en la próxima teniendo en cuenta los plazos y el ancho de banda de los equipos de desarrollo y prueba.
- Hay algunos escenarios que un probador podría probar durante las pruebas ad-hoc que podrían ser escenarios inválidos, considerando la posibilidad de que ocurran en la producción.
¿Quién es el mejor amigo del probador?
¿A dónde debe ir un probador en caso de ambigüedad? La respuesta depende del tipo de consulta, si una consulta está relacionada con los requisitos, es aconsejable discutir primero dentro del equipo para que la comprensión correcta del sistema se realice consultando a los miembros superiores. El siguiente punto de contacto deben ser los analistas de negocios.
Si la consulta está relacionada con el proceso de prueba, es aconsejable comunicarse con el jefe de prueba o el administrador de prueba.
Si la consulta se refiere a la comprensión de los tecnicismos de la aplicación, el miembro del equipo de desarrollo podría ser la persona adecuada.
Dado que las pruebas son un proceso que requiere una comprensión general del sistema, la comunicación ayuda al evaluador a obtener respuestas rápidas a las consultas, solo depende de hacer las preguntas correctas a las personas correctas. Evitar hacer preguntas en el momento adecuado podría conducir a un defecto que se filtre al entorno de producción.
¿Qué importancia tiene el papel de un probador en la empresa actual?
Hay proyectos en los que el equipo de prueba es tan importante como el equipo de desarrollo y, en algunos casos, hay más dependencia del equipo de prueba que del equipo de desarrollo. El escenario posterior es raro pero existe en algunos lugares de trabajo. Esto ha sucedido a lo largo del tiempo y podría ser durante un período de tiempo específico cuando el equipo de desarrollo no tiene mucha experiencia en comparación con el equipo de prueba. Hay personas que entienden el flujo general y la funcionalidad mejor que la mayoría de los otros miembros del equipo. Tal individuo podría ser parte del equipo de prueba / desarrollo. Este es uno de los factores que decide la dependencia de un equipo / individuo para el proyecto específico.
¿Cuál es el camino profesional para un probador?
Una persona puede tomarse un tiempo para comprender el proceso de prueba general, el dominio y otras tareas en las que se espera que trabaje en la vida diaria. En base a esta comprensión, es aconsejable tomar la decisión de explorar más áreas que un probador podría ocupar. Siempre hay oportunidades en el proceso para automatizar varios flujos. Crear pequeñas utilidades también puede ayudar al equipo a lo grande. Si un probador es bueno para programar, se considera una gran ventaja. Esto abre oportunidades para roles de automatización. Las pruebas de rendimiento también son una de las carreras profesionales para los evaluadores. Analista de negocios es otra opción. Un buen conocimiento del dominio con buenas habilidades de comunicación son los conjuntos de habilidades necesarios para ser analistas de negocios. Las pruebas abren muchas oportunidades para que los evaluadores trabajen en varios dominios, herramientas, procesos, etc. Solo depende de un individuo para recoger y comenzar a profundizar en una de las áreas centrales de prueba. Existen muchas certificaciones específicas para diversas herramientas para especializarse en una de las áreas de prueba. Tener la certificación del proveedor estándar es una ventaja para impulsar la carrera, pero el certificado por sí solo no puede ayudarlo a largo plazo si no se combina con la experiencia laboral correcta.
Artículos recomendados
Aquí hay algunos artículos que lo ayudarán a obtener más detalles acerca de las Pruebas de software, así que simplemente vaya al enlace.
- Las 6 preguntas más sorprendentes de la entrevista de prueba de software
- Carreras en pruebas de software
- Cómo obtener un mejor crecimiento profesional en el trabajo del probador de software