Puede que ya seas un tester experimentado o que apenas estés iniciando en el mundo de las pruebas, quizá ya tengas interiorizados los conceptos brindados por ISTQB u otros como TDD, BDD, Dev Ops, Agilísimo o que para ti estos sean conceptos desconocidos, pero en cualquiera de los casos llegará el momento en el que dentro de tu proyecto evidencies que el cliente quiere sacar su producto al mercado lo más rápido posible.
En el afán que acarrea el panorama anterior, el equipo de trabajo se convierte en un grupo de personas dispuestas a realizar los sueños del cliente y a verlo feliz, más allá de lo que haya que sacrificar (como lo son las buenas prácticas de desarrollo y calidad), y particularmente el tester se convierte en una “maquinita” que únicamente diseña y ejecuta casos de prueba, o incluso lo hace sin un diseño previo.
Es por esta razón, que desde Sofka Technologies queremos compartir contigo una serie de preguntas que no deberías pasar por alto al momento de tener ceremonias como el refinamiento, pre-refinamiento o planeación, en pro de que en ese momento de la carrera contra el tiempo, la claridad de los requerimientos sea la más alta posible, y el equipo evite reprocesos, redefiniciones o altos en el camino; sumado a que no deberíamos olvidar que como Testers somos los encargados de hacer la mayor cantidad de preguntas posibles por más sencillas o complejas que parezcan (QA – Question Asker).
Al realizar pruebas de componentes
Las preguntas obligadas siempre serán:
- ¿Qué campos son obligatorios?
- ¿Cuál será el mínimo y máximo de caracteres que permitirá el campo?
- ¿Si se ingresa un dato errado como se le informará al usuario?
- Campo texto
- ¿Qué tipo de caracteres aceptará el campo (por ejemplo, solo letras, números, espacios)?
- ¿Se permitirá el uso de caracteres especiales, como signos de puntuación o símbolos?
- ¿Se omitirán los caracteres que dan entrada a la inyección de código o scripting malicioso (comillas simples, comillas dobles, barras invertidas, caracteres nulos)?
- ¿Tendrá alguna máscara de entrada? ¿Se realizará alguna validación sobre el campo al cambiar el foco o presionar la tecla “Entrar”?
- ¿Se podrá copiar y pegar contenido sobre el campo o solo debe ser digitado por el usuario?
- Campo fecha
- ¿Qué formato de fecha manejará el campo?
- ¿Contará con calendario de ayuda?
- Campo numérico
- ¿Admite valores menores o iguales a cero?
- ¿Se tendrá algún rango específico?
- ¿Se manejan decimales?
- ¿Permitirá el ingreso de signos?
- Campo lista
- ¿Tendrá algún valor por defecto?
- ¿Se pueden llegar a seleccionar varios valores de la lista?
- ¿En qué orden se mostrará la información de la lista?
- ¿Se tendrá un máximo de opciones a visualizar?
- ¿El usuario podrá ingresar información y esta se autocompletará?
- Campo tipo de identidad/DNI para cada país o región los requisitos del documento de identidad de las personas pueden variar, entonces:
- ¿Permitirá el ingreso de letras?
- ¿Se tendrá un algoritmo de validación para el dígito de control o verificación (si aplica)?
- Campo número teléfono
- ¿Se deberá ingresar el prefijo nacional/internacional?
- ¿Cuál será el signo de separación del prefijo si aplica?
- ¿Los caracteres ingresados se deberán agrupar?
- Botón
- ¿Manejará estados como habilitado/deshabilitado?
- ¿Se almacenará información al seleccionarlo o a medida que se ingrese información?
- ¿Se mostrará algún mensaje luego de que el botón active alguna funcionalidad?
- ¿Se tendrá algún tiempo límite de respuesta luego de seleccionar el botón?
- ¿Se realizará la validación de campos al seleccionar el botón o al ir ingresando la información?
- Grids
- ¿Se permitirá el ordenamiento?
- ¿Hasta cuántos registros se podrán visualizar?
- ¿Se tendrá paginación?
- ¿Se podrá filtrar o realizar búsquedas específicas?
- ¿Se podrá seleccionar una o varias filas?
- ¿Se podrá eliminar/editar las filas?
- ¿La tabla debe ser responsiva y adaptarse a diferentes tamaños de pantalla?
Al realizar pruebas sobre APIS
- Control de errores
- ¿Qué códigos de errores debe retornar?
- ¿Qué validaciones se realizan sobre los datos de entrada?
- ¿Se emite el error apropiado si se solicita mal el tipo de contenido?
- ¿Se bloquearán los usuarios después de emitir el mismo tipo de error en varias ocasiones consecutivas?
- ¿Hay llamadas asíncronas?
- ¿Qué pasa frente a una caída del sistema durante la transacción,
- ¿cómo podría recuperarse?
- ¿Qué error tendría que dar?
- Paginación
- ¿La API devuelve una lista?
- ¿Cuál es el tamaño de la lista?
- ¿Soporta paginación?
- ¿Tiene tamaño por defecto para la paginación?
- ¿Puedo controlar el número de resultados que obtengo en cada página?
- ¿Podría ser diferente para cada usuario?
- ¿Cómo obtiene la API esta información para el usuario?
- ¿Hay alguna restricción para diferentes consumidores de la API, tales como web, móvil o tableta?
- ¿Cuál es el formato de la salida
- Autenticación
- ¿Quién puede acceder a esta API?
- ¿Cómo se autentican?
- ¿Cómo se mantiene la autenticación para llamadas posteriores?
- ¿Soporta múltiples sesiones para los mismos usuarios?
- ¿Qué hay de varias autenticaciones desde la misma máquina?
- ¿Qué debe suceder si el usuario se desconecta de un dispositivo o del navegador?
- ¿Cuántas veces un usuario puede fallar la autenticación?
- ¿Por cuánto tiempo la autenticación permanece válida/activa?
- Autorización
- ¿Quién puede acceder a esta API?
- ¿Cómo se limita el acceso?
- ¿Cómo puedo obtener acceso privilegiado?
- ¿Cuál es el riesgo de que alguien obtenga acceso no autorizado?
- ¿Hay jerarquía de acceso o un acceso diferente para diferentes roles?
- ¿Cuántos niveles de autorizaciones hay?
- ¿Cómo se hace cumplir la autorización a nivel del sistema?
- Comportamiento
- ¿Cuál será la carga esperada y el tiempo de respuesta?
- ¿Qué tipo de contenido soporta?
- ¿La prueba es para XML, JSON o ambos?
- ¿Está presente la cabecera?
Al realizar pruebas en diversas funcionalidades, como la búsqueda de datos, la autenticación de usuarios o la carga de archivos, es importante plantearnos una serie de preguntas adicionales. Estas preguntas, basadas en nuestro conocimiento y experiencia como testers, combinadas con un enfoque sólido de pruebas, como el desarrollo guiado por ejemplos o comportamientos, contribuyen a garantizar que la historia de usuario o requerimiento esté completa, clara y cuente con criterios de aceptación bien definidos. Esto proporciona mayor claridad al equipo. Además, nos ayuda a identificar cualquier posible brecha o incongruencia en el funcionamiento de la funcionalidad en cuestión.
Por último, no olvides el panorama general: Adapta las pruebas a las necesidades y especificaciones de la aplicación o sistema, y considera cualquier otro requisito específico que pueda ser relevante.
En Sofka We make IT simple, We make QA simple.
We generate value through clear content, focused on the software development industry.
