Menú

6 habilidades básicas que todo evaluador (principalmente más nuevo) debería tener

6 basic skills that every tester should have

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Software Testing o QA es la mejor plataforma para que los recién llegados ingresen a la industria de TI a pesar de la idea errónea de que es un trabajo con menor o menor salario.

La habilidad más importante que necesita un evaluador es la capacidad para encontrar errores . Y, si usted es el tipo de persona a la que le encanta encontrar errores, entonces le encantará y crecerá en este campo.

Dicho esto, hay algunas habilidades más que pueden ayudarlo a encontrar errores y trabajar mejor con los procesos de control de calidad.

Este es el artículo que mostrará el proceso de control de calidad como se sigue en la mayoría de las empresas y proporcionará a los nuevos probadores aclaraciones sobre las pruebas.

En detalle, aprenderá el proceso de documentación y los estándares, el trabajo previo del evaluador, las pruebas basadas en restricciones, las pruebas durante el desarrollo parcial y finalmente el proceso de aprobación.

habilidades de prueba básicas

Vamos a empezar.

Lo que vas a aprender:

# 1. Documentación

La documentación es esencial para las pruebas. La mayoría de las empresas asignan esta tarea a los recién llegados. Para tener éxito, debe tener buen vocabulario porque el resto de cosas, como los estándares de documentación, etc., no están bajo su control y dependen de los procesos del equipo y de la empresa.

Además, asegúrese de ver el valor del proceso de documentación. Las ventajas son muchas: le ayudan a realizar un seguimiento de los cambios en los requisitos, a seguir los pasos de la prueba, a registrar su trabajo, etc.

Lectura recomendada=> Por qué la documentación es importante en las pruebas de software

# 2. Examen de preparación

De todos los documentos disponibles, no se pueden descuidar los siguientes. Estos también se denominan documentos entregables y unen la comprensión del cliente, el desarrollador y el evaluador.

mejor limpiador de registro para windows 7

a) Plan de prueba: traza el flujo de prueba de principio a fin .

El plan de prueba describe el alcance y las actividades de la fase de prueba. Creado por el líder de QA, el equipo tiene que contribuir y mantenerse actualizado sobre todo lo que está escrito en el plan de prueba.

Algunos equipos tienen varios niveles de planes de prueba: plan maestro y planes por fases.

Un plan de prueba debe tener:

  • Nombre y versión del proyecto
  • Identificadores del plan de prueba: creador, número de borrador, fecha de creación, etc.
  • Introducción: descripción general del proyecto, objetivo y limitaciones
  • Referencias: lista de referencias utilizadas como entrada (asegúrese de utilizar las últimas y precisas versiones)
  • Elementos de prueba: módulos, versión, alcance, fuera del alcance, etc.
  • Enfoque de prueba general / Estrategia de prueba: herramientas a utilizar, proceso de seguimiento de defectos, niveles de prueba a realizar, etc.
  • Criterios de elementos de aprobación / reprobación: directrices de ejecución de pruebas
  • Criterios de suspensión y reanudación
  • Entregables de prueba: caso de prueba, informes de prueba, informe de errores, métricas de prueba, etc.
  • Detalles del entorno de prueba
  • Lista del equipo con información de punto de contacto. para cada módulo o tipo de prueba
  • Estimaciones de prueba: tiempo y esfuerzo. Los detalles del presupuesto son confidenciales y no los encontrará aquí
  • Planes de mitigación y riesgos
  • Aprobaciones
  • Otras pautas

También leer=>

mis preguntas y respuestas de la entrevista sql

b) Escenarios de prueba:

Una línea indica 'qué probar' según cada requisito y, por lo general, se documenta y se realiza un seguimiento a través de hojas de cálculo.

La mayoría de ellos contienen:

  • Nombre del módulo / componente / función (inicio de sesión, administrador, registro, etc.)
  • El ID del escenario es de referencia (por ejemplo: TS_Login_001)
  • Descripción del escenario: 'Qué probar' Por ejemplo: validar si el inicio de sesión permite a los usuarios con credenciales válidas iniciar sesión correctamente.
  • Importancia del escenario: priorizar en caso de tiempo insuficiente: alta / media / baja
  • Id. De requisito: para la trazabilidad

Otras lecturas=>

c) Casos de prueba:

Los casos de prueba precisos dan resultados de prueba precisos. Las hojas de cálculo siguen siendo el medio popular para la redacción de casos de prueba, especialmente para principiantes, aunque algunas empresas adaptan herramientas de gestión de pruebas. La base para la redacción de casos de prueba es el documento SRS / FRD / Req. Pero, a menudo no es suficiente, por lo que tendrá que usar muchas suposiciones y discusiones con los equipos de BA / Dev.

Escribir casos de prueba efectivos es la calificación más importante que debe tener un evaluador. Por lo general, todos los casos de prueba se clasifican como positivos / negativos. Caso de prueba positivo está dando aportes válidos y obteniendo resultados positivos. Caso de prueba negativo está dando entradas no válidas y recibiendo el mensaje de error exacto.

Para obtener más información sobre estos, consulte:

Algunos de los atributos comunes que tienen todos los casos de prueba son:

  • ID de escenario: tomado del documento de escenario de prueba
  • ID de caso de prueba: para identificación y seguimiento únicos. Por ejemplo: TC_login_001
  • Descripción de la prueba: breve explicación de la condición de prueba probada
  • Pasos a ejecutar: instrucciones detalladas paso a paso sobre cómo realizar la prueba
  • Datos de prueba: datos suministrados a los pasos de prueba
  • Resultado esperado: resultado esperado
  • Resultado real: respuesta del AUT cuando se ejecuta la prueba
  • Estado: Pasa / No pasa / No se ejecuta / Incompleto / Bloqueado: describe el resultado de la prueba
  • Comentarios - Para detalles adicionales
  • Ejecutado por: nombre del evaluador
  • Fecha de ejecución: fecha en la que se ejecuta la prueba
  • ID de defecto: defecto registrado en el caso de prueba, en caso de falla de la prueba
  • Detalles de configuración: sistema operativo, navegador, plataforma, información del dispositivo (opcional)

Lectura recomendada=>

# 3. Proceso de prueba: ¿Qué pruebas realizar?

Hay una gran cantidad de tipos de prueba, pero no todos se pueden realizar en ese AUT. El tiempo, el presupuesto, la naturaleza del negocio, la naturaleza de la aplicación y el interés del cliente son los actores clave en la elección de qué pruebas realizar en la aplicación.

Por ejemplo: Si se trata de un portal de comercio en línea, las pruebas de estrés y las pruebas de carga son obligatorias. Sin embargo, algunos de los tipos de pruebas que no deben perderse son:

# 4. Prueba en la etapa de desarrollo parcial

Generalmente, con empresas de nivel medio y de nueva creación, el tiempo y los recursos son limitados. Los probadores aquí pueden comenzar su proceso de prueba antes de la integración del módulo, lo que significa que podríamos estar haciendo pruebas de integración de unidades e intermedias.

Es importante tener en cuenta que los resultados de estas etapas no se pueden contar como precisos, por lo que es posible que deba planificar una prueba general de caja negra una vez que todo esté listo para comenzar. Pasar por alto esa parte puede resultar costoso y de prueba, ineficaz.

# 5. Documento de informe de error

En la práctica, este es el documento de control de calidad más importante que jamás podrá realizar.

Los siguientes son los campos que debe tener un buen informe de errores:

cómo abrir archivos swf con adobe flash player
  • ID de defecto: normalmente un número de serie
  • Descripción del defecto: explicación de una línea del problema
  • Ubicación: módulo / área de la AUT donde se encuentra el problema
  • Número de compilación: versión y código de compilación no.
  • Pasos para reproducir: lista de pasos que lo llevan al problema.
  • Severidad: establezca un nivel para describir la gravedad del problema: bajo, medio, alto, bloqueador, etc.
  • Prioridad: establecida por los desarrolladores para determinar el orden en el que se solucionará el defecto (P1, P2, P3, etc. P1: el más alto)
  • Asignado a: propietario del defecto en ese momento
  • Informado por: nombre del evaluador
  • Estado: estado diferente para representar la etapa del ciclo de vida del error
    • Nuevo: se encuentra un error y se acaba de informar
    • Abierto: validado por el líder de control de calidad
    • Asignado: enviado al líder de desarrollo para su asignación al desarrollador respectivo
    • En progreso / Trabajo en progreso: el desarrollador comenzó a trabajar en él
    • Fijo / resuelto: el desarrollador ha terminado de trabajar en él
    • Verificado / Cerrado: el equipo de control de calidad ha vuelto a realizar la prueba y ha encontrado el error corregido
    • Volver a probar: el equipo de control de calidad no está de acuerdo con la resolución de Dev y sigue avanzando con el error para volver a trabajar
    • Duplicado: ya existe un error similar
    • Diferido: error válido, pero se solucionará en versiones posteriores
    • No válido: no es un error o no es reproducible o no hay suficiente información

Otras lecturas=>

# 6. Proceso de aprobación

cerrar sesión y el envío de la documentación final es tarea del líder / gerente de control de calidad. Sin embargo, el equipo tiene que enviar los documentos anteriores (escenario de prueba, caso de prueba y documento de registro de defectos) para revisiones finales y auditoría.

Asegúrate de revisarlos todos y enviar las versiones finales.

También leer=>

Conclusión

Este es el proceso que he presenciado y experimentado de primera mano cuando era tester y espero que esto le haya dado algunos consejos útiles.

Finalmente, una carrera en las pruebas ha sido una alegría absoluta para mí y espero que también lo sea para ti.

¡Todo lo mejor para tu carrera!

Lectura recomendada

^