Introducción al trabajo del probador de software
¿Qué es lo primero que se te ocurre cuando piensas en un trabajo de prueba de software? ¿Un trabajo no codificador? ¿O una profesión que es muy fácil ya que le da la oportunidad de encontrar errores en el trabajo de otros (encontrar errores cuando en otros es la tarea más fácil para todos nosotros)? ¿O piensa que es la profesión que se ocupa de verificar la exactitud del producto? Todos estos pensamientos son correctos y son las actividades diarias para el trabajo de un probador de software. Sin embargo, las pruebas de software no se limitan solo a estas actividades.
Comprender la aplicación
La aplicación podría ser de cualquier dominio: salud, seguros, finanzas, etc. Aprender el dominio de la aplicación es muy importante para que cualquier trabajo de software abra las puertas a pensar desde varios ángulos y diversas perspectivas del usuario mientras prueba la aplicación. Descubrir y validar las rutas de aplicación obvias y no tan obvias es siempre la expectativa principal de esto. Tener un conocimiento profundo de la aplicación ayuda a validar el producto de manera efectiva al mismo tiempo que el probador puede convertirse en un activo para un proyecto donde él / ella es considerado como una de las principales fuentes de conocimiento con respecto al comportamiento del producto.
Si bien aprender dominio y funcionalidad es un proceso continuo para cualquier otro factor importante es tener conocimiento sobre el proceso de prueba.
Proceso de prueba
El proceso de prueba puede variar de una compañía a otra o incluso de un proyecto a otro. Hoy tenemos varios modelos de desarrollo de software como el modelo V, el modelo de prototipos o una metodología completamente diferente como el enfoque ágil del desarrollo de software. Con el cambio en el modelo de desarrollo, el enfoque de prueba a seguir también varía. Trabajar en un modelo V tendrá procesos bien definidos, mientras que se espera que este trabajo en una metodología ágil se pruebe en condiciones siempre cambiantes.
El trabajo aún no es fácil con tener un dominio de dominio aceptable y la comprensión del proceso de prueba, el próximo desafío que viene con la vida es aprender varias herramientas.
Herramientas
Las herramientas implican herramientas de gestión de pruebas, herramientas de registro de defectos, herramientas de gestión de bases de datos, etc.
Con varios programas de registro de defectos, cualidades y herramientas, algunos de código abierto y otros con licencia, siempre es una ventaja tener conocimiento de más de una herramienta. Le ayuda a realizar fácilmente la transición de proyectos o equipos siguiendo diferentes herramientas. Con un conocimiento adecuado del dominio, el proceso y las herramientas, hay más en la vida del trabajo de Software Tester que hace que sus días de trabajo sean desafiantes y emocionantes. La colaboración dentro de los equipos es uno de los factores importantes en el éxito de cualquier proyecto y, para una colaboración efectiva, la comunicación juega un papel muy importante.
Cursos recomendados
- Curso completo de J2EE
- Entrenamiento en línea de programación de R
- Ir al curso de programación
- Capacitación de certificación en línea en el programa Haskell
Comunicación
La comunicación juega un papel muy importante para las cualidades del software, ya que desde las fases iniciales del desarrollo del software, los miembros del equipo de prueba están involucrados (como una mejor práctica) en la discusión de los requisitos, cuestionando a los analistas de negocios en caso de consultas o lagunas en el requisito. Un medidor con habilidades de comunicación efectivas puede comunicar los riesgos de manera efectiva, puede comunicarse de manera efectiva con el equipo de desarrollo y puede comunicar de manera efectiva los resultados de la prueba y los informes de prueba.
Planificación de trabajos de prueba de software
Como su nombre indica, la planificación de la prueba es la fase donde se realiza la preparación para la prueba. La preparación para un tster implicará varios tipos de actividades que un tster realiza para que la aplicación sea efectiva. Esto ayudará a validar la aplicación y descubrir los defectos en la aplicación de manera efectiva. Para comenzar la planificación, un testículo pasa por los requisitos para comprender las expectativas.
1. Requisitos
Se podrían dar requisitos al equipo de prueba en forma de wireframes, guiones gráficos, hojas de Excel. El propósito de todos estos documentos es presentar los requisitos del cliente de una manera eficiente y fácil de entender. El documento de estructura metálica no es más que un documento que puede tener la forma de una presentación de PowerPoint que representa los requisitos del cliente. En la misma línea, los guiones gráficos generalmente representan el aspecto / diseño requerido de las pantallas. Hoy en día, hay varias herramientas disponibles en el mercado que se pueden utilizar para preparar los documentos requeridos. La creación de los documentos requeridos es responsabilidad principal de un analista de negocios. Se espera que un sabor entienda los requisitos a fondo. Para que el teste y los desarrolladores entiendan los requisitos correctamente, los analistas de negocios mantienen abierto el foro para que todos puedan plantear y obtener respuestas a las preguntas sobre cualquiera de los requisitos. La plataforma para discutir y comunicar las preguntas y consultas abiertas varía de un proyecto a otro. Podría ser la cadena de correos electrónicos o una llamada de conferencia o incluso un repositorio de unidades compartidas mantenido para realizar un seguimiento de todas las preguntas abiertas y sus respuestas según lo provisto por el analista de negocios.
La comunicación clara y el registro de la comunicación juegan un papel muy importante para una prueba. Una pequeña suposición en el requisito a veces puede conducir a un defecto importante en el producto. En cada etapa, se recomienda a un probador de software cualidades para mantener limpia la comunicación. La comunicación del software Tester Work podría ser con analistas de negocios o incluso dentro de un equipo. La comunicación clara ayuda a mantener alejadas las suposiciones durante la planificación y la ejecución. Al mismo tiempo, se recomienda tener un registro de comunicación (preferiblemente comunicación por correo electrónico). Tener una comunicación escrita sobre las consultas sobre los requisitos ayuda en las etapas posteriores de la ejecución de la prueba, donde la funcionalidad podría no haberse desarrollado según lo confirmado en la comunicación grabada.
2. Escenario
Una vez que se comprenden los requisitos, el probador comienza a documentar los escenarios en el documento Escenario de prueba. Un escenario como su nombre indica es un flujo de funcionalidad que el usuario sigue para realizar una tarea.
Ejemplos de escenarios :
- El usuario debe poder iniciar sesión correctamente.
- El usuario debe poder reservar tickets en el sistema.
- El usuario debe poder cancelar tickets en el sistema.
- El usuario debe poder ver / actualizar los detalles del perfil.
Estas son las tareas lógicas que realiza un usuario en el sistema. Estas tareas lógicas cuando se agrupan ayudan a que el probador tome nota de todos los escenarios posibles que se espera que realice un usuario. Estos escenarios generalmente se documentan en las hojas de Excel o, a veces, con algunas herramientas. Un comprobador prospera para extraer todos esos escenarios de los documentos de requisitos. Un documento que contiene tales escenarios se llama Documento de escenario de prueba (o en algún lugar como Documento de escenario de alto nivel). Este documento sirve como documento de entrada para redactar casos de prueba.
3. Caso
Este caso es la versión más detallada del escenario de trabajo de Software Tester, donde el escenario se desglosa en pasos más detallados que el usuario realmente realizará mientras usa la aplicación. Un ejemplo simple basado en los escenarios mencionados anteriormente es:
Escenario : el usuario debe poder iniciar sesión correctamente.
Casos de prueba:
- Verifique que el usuario pueda ingresar el nombre de usuario correcto.
- Verifique que el usuario pueda ingresar la contraseña.
- Verifique que al hacer clic en el botón Iniciar sesión después de ingresar el nombre de usuario y la contraseña correctos, el usuario pueda iniciar sesión correctamente.
Tal lista de estos casos puede incluir una verificación de validación en cada campo, verificar escenarios negativos, etc.
A continuación se presentan algunos de los ejemplos adicionales de estos casos:
- Verifique ese nombre de usuario cuando no se ingresa, el sistema arroja un error apropiado.
- Verifique esa contraseña cuando no se ingresó, el sistema arroja un error apropiado.
- Verifique que el nombre de usuario y la contraseña cuando no se ingresen, el sistema arroje un error apropiado.
- Verifique que al ingresar una contraseña incorrecta, el sistema arroje un mensaje de error apropiado.
- Verifique que al ingresar un nombre de usuario incorrecto, el sistema arroje un mensaje de error apropiado.
4. Matriz de trazabilidad de requisitos (RTM)
La matriz de trazabilidad de requisitos, como su nombre lo indica, ayuda a comprobar e incorporar la cobertura de los requisitos según lo dispuesto por Business en los documentos de prueba, como escenarios y casos de prueba.
Como práctica recomendada, este es un documento separado que muestra el mapeo del número de requisito con el de los escenarios / casos que incorporan ese requisito.
Este documento puede no ser utilizado por todo tipo de proyectos, pero cuando se usa ayuda de manera sólida a rastrear el mapeo de escenarios de alto nivel a los requisitos. Indica la cobertura y se puede utilizar para verificar la presencia de al menos uno de estos casos contra cada requisito. La creación y el mantenimiento del documento RTM se considera la mejor práctica, sin embargo, no todos los tipos de proyectos (como Agile) usan el documento de trabajo de prueba de software. Cuando los requisitos cambian con mucha frecuencia, se puede escuchar el mantenimiento de este documento. Para evitar esta sobrecarga y al mismo tiempo tener una forma de rastrear los requisitos, algunos proyectos incorporan la parte de trazabilidad en el caso de trabajo de Software Tester o en su propio documento de escenario.
El aspecto importante es tener una forma de rastrear escenarios / casos a los requisitos y viceversa. Los requisitos bien documentados hacen que la tarea de Prover sea más fácil de crear y mantener estos documentos. Los requisitos ambiguos, los requisitos siempre cambiantes hacen que la vida de los probadores sea más desafiante y pueden conducir a tener documentos entregables inconsistentes que resultan en perder alguna validación y, por lo tanto, un defecto en el producto final.
El viaje hasta ahora para un probador estaba planeando y preparándose para la prueba. Como la preparación para la guerra es parte de la guerra, lo mismo se aplica aquí. Cuanto más concisos se creen estos documentos, es más fácil para el probador validar la funcionalidad y descubrir casi todos los defectos. La siguiente fase del viaje del probador es Ejecución.
Ejecución de trabajos de prueba de software
Esta es la fase en la que se utilizan todos los documentos mencionados anteriormente. Los requisitos se usaron para crear un escenario, el escenario se usó para crearlo. Casos. este documento de caso es el documento autosuficiente aquí para comenzar a validar la aplicación. Prover comienza a validar la aplicación ejecutando pasos a partir de este documento de caso. Varios de estos casos podrían usarse para validar un solo escenario o incluso un solo caso de prueba puede corresponder a un solo escenario de prueba. Todo depende de la complejidad de los escenarios o, a veces, del estándar seguido en el equipo de prueba. Por lo tanto, un solo documento de caso de prueba puede contener 20-50 casos de prueba o puede tener 100-120 casos de prueba. Estos números son solo para fines de explicación, pueden variar enormemente de un proyecto a otro. El resultado de esta fase son los defectos de prueba. El número de defectos válidos planteados en esta fase da una buena idea sobre la estabilidad de la aplicación, la calidad de las pruebas, la calidad de construcción y muchos factores que afectan directamente al producto. Esta fase es la fase más importante ya que el probador prospera para cubrir todos los casos de prueba (validando casi todas las rutas de usuario requeridas) y al mismo tiempo generar tantos defectos válidos como sea posible. Toda la preparación, habilidades de comunicación, consultas solicitadas para el negocio entra en acción en esta fase de prueba.
Defectos del probador de software funciona
Mientras se ejecuta este caso, cualquier comportamiento que no sea igual al resultado esperado se genera como el Defecto. Cada caso de prueba tiene una Descripción, Resultado esperado y una columna para el Resultado real. Mientras que estos documentos de planificación de Software Tester Work tienen una descripción y resultados esperados y una columna en blanco para los resultados reales. Al ejecutar los casos de prueba, se supone que el probador debe llenar la columna de resultados real. Al mismo tiempo, si real no es igual al resultado esperado, se registra el defecto. Registrar un defecto simplemente no significa informar al desarrollador sobre el problema. Es nuevamente un proceso formal que generalmente se realiza con la ayuda de una herramienta. Actualmente, existen varias herramientas en el mercado, algunas de código abierto y otras con licencia. Cualquier herramienta de registro de defectos tiene los siguientes campos:
- Proyecto / Nombre de lanzamiento
- Resumen de defectos
- Descripción detallada del defecto
- Severidad del defecto
- Prioridad de defecto
- Fase se encontró el defecto
- Asignado a
- Archivos adjuntos
Como podemos ver, el propósito de todos estos campos es tener un proceso formal con detalles sabios del problema encontrado. Esto ayuda a los desarrolladores a reproducir el defecto en su entorno y corregirlo. A continuación se muestra la breve descripción de todos estos campos:
- Nombre del proyecto / versión : nombre de la versión donde se encontró el defecto, por lo general, el proyecto tiene varias versiones y el mismo proyecto puede tener múltiples subproyectos. Este campo ayuda a plantear un problema para una versión específica.
- Resumen de defectos : una breve descripción del defecto encontrado.
- Descripción detallada del defecto : esta es la descripción detallada del defecto, debe incluir detalles como el entorno donde se encontró el defecto y los datos de prueba utilizados, los resultados reales previstos y la información adicional que agrega información más valiosa para que las partes interesadas comprendan defecto.
- Severidad del defecto : significa la gravedad del defecto. Por lo general, tiene valores similares a los valores críticos, altos, medios, bajos o numéricos como 4, 3, 2, 1.
- Prioridad de defecto : significa la urgencia de corregir el defecto.
- Fase en la que se encontró el defecto : como hay muchas fases en las que se puede registrar un defecto, fase de prueba de la unidad, SIT (prueba de integración del sistema), UAT (prueba de aceptación del usuario) o incluso fase de producción.
- Asignado a : nombre del desarrollador o líder de desarrollo.
- Archivos adjuntos : esto le da una opción al probador para adjuntar la instantánea de la pantalla donde se encontró el problema.
La ejecución de pruebas y el registro de defectos es la fase en la que hay muchos desafíos que un probador podría enfrentar. Algunos de ellos se están comunicando efectivamente con los desarrolladores. ¿Podríamos argumentar que registrar un defecto con toda la información necesaria no es suficiente para que los desarrolladores entiendan el defecto?
Es y, en algunos casos, requiere una explicación / discusión adicional con los desarrolladores. Hay casos en los que un probador encuentra un comportamiento inesperado del que no está seguro si es un defecto. Estas circunstancias generalmente se enfrentan a probadores que son nuevos en el equipo, que tienen un conocimiento de dominio limitado o que tienen ambigüedad en los requisitos. Bueno, no se debe culpar al probador aquí si hay plazos ajustados y hay requisitos siempre cambiantes y, en la mayoría de los casos, los probadores aprenden sobre el dominio mientras planifican y ejecutan casos de prueba. Como podemos ver, el camino de un probador no es tan fácil como se percibe. Requiere una actitud de aprendizaje constante, buenas habilidades de comunicación, buenas habilidades de colaboración y ganas de ajustarse en condiciones donde hay cambios en los dominios, herramientas y procesos utilizados. Si bien hablamos sobre el viaje de los probadores manuales, el proceso general se aplica también a los probadores de automatización. La automatización, por otro lado, tiene cambios significativos en el proceso ya que el alcance de las pruebas y la planificación, la ejecución varía significativamente.
Considerando el viaje del probador como se discutió anteriormente, ¿podemos decir que el trabajo de las cualidades del probador de software es más fácil que el de un desarrollador?
Se puede decir que más que comparar los roles de desarrollador de tester v / s, será más útil tener una discusión sobre cómo la colaboración de dos puede conducir a un gran éxito del producto en su conjunto. A veces olvidamos que el trabajo del probador es encontrar problemas en la aplicación y no señalar errores de los desarrolladores. Cuando olvidamos la idea misma de nuestro trabajo, a veces nos lleva a discusiones innecesarias. Sin embargo, se ha observado que hay equipos de desarrollo y pruebas igualmente buenos donde todos entienden que el objetivo final es hacer que la aplicación funcione como se espera. ¡Esperemos que todos vean el lado positivo del trabajo de prueba como un papel que ayuda a limpiar el producto y no como el que solo encuentra errores!
Artículos recomendados
Esta ha sido una guía para descubrir y validar las rutas de aplicación obvias y no tan obvias siempre es la expectativa principal del trabajo de un probador de software. Estos son los siguientes enlaces externos relacionados con el trabajo del probador de software.
- Ciclo de vida de defectos en pruebas de software
- Las 6 preguntas más sorprendentes de la entrevista de prueba de software
- Carreras en pruebas de software