Menú

¿Cómo probar una aplicación sin requisitos?

how test an application without requirements

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Técnicamente no hay aplicaciones sin requisitos. Imagine un software que no hace nada específico, sino que se extiende línea tras línea de código. Será una escalera que no conducirá a ninguna parte.

Todo el software tiene requisitos y está dirigido a una tarea en particular; específicamente, es una solución a un problema. Asi que sin requisitos el software no es una posibilidad.

Sin embargo, el software sin requisitos documentados es una realidad que, lamentablemente, la mayoría de nosotros enfrentamos con más frecuencia que nos gusta. Lo único peor podría ser que la documentación sea insuficiente, inexacta o terriblemente desactualizada. Lamentablemente, esto también sucede.

prueba sin requisitos

Honestamente, realmente no hay sustituto para un documento de requisitos funcionales / del sistema bien documentado con casos de uso elaborados y pantallas simuladas. Aunque tenemos que admitir que esto se está convirtiendo en una rareza en la industria debido a los rápidos ciclos de desarrollo y un cambio de paradigma hacia una documentación mínima o nula.

Por lo tanto, este artículo es un intento de algunas prácticas que hemos seguido cuando nos encontramos en estas situaciones.

Leer también:

cómo abrir archivo clave en windows

Veamos primero algunos razones por las que podría no haber documentación, para empezar:

  1. Proyecto archivado que se reabrirá
  2. Documentación menos formato de trabajo- Proceso
  3. Es posible que exista documentación, pero puede que no sea detallada o completa
  4. Las versiones continuas y la información relacionada con la versión anterior no se han archivado, lo que genera una brecha en la comprensión de cómo reacciona la funcionalidad existente con la nueva.

Todos estos son impedimentos que los probadores tenemos que superar con valentía y emerger con éxito. Sin embargo, ¿cómo exactamente, verdad?

Estos son los 3 métodos principales para probar una aplicación sin requisitos:

Método 1:

Trabaje con la pequeña documentación que tenga en sus manos. Podría ser una acumulación básica simple (en proyectos ágiles), un archivo de ayuda, un correo electrónico, una versión anterior de BRD / FRD o casos de prueba antiguos (verifique estos en sus herramientas de ALM y es posible que los encuentre), etc.

Investigue, pregunte a su alrededor y siempre hay algún juicio documentado, incluso si es pequeño.

Cuando esto no funcione, no descarte su experiencia como usuario de software.Por ejemplo, si tiene que probar una operación de transferencia para una cuenta bancaria, nadie necesita decirnos cómo hacerlo, ¿no es así? Porque, como clientes de banca en línea, todos sabemos que necesitamos desde y hacia cuentas con una cantidad de fondos disponibles para ser transferidos.

Estuvo de acuerdo en que no todas las situaciones van a ser tan sencillas, pero de nuevo, podrían serlo también.

Método # 2:

Utilice la versión anterior / actual de la aplicación como referencia para probar la versión futura de un producto de software. Ahora, admito que esto es una negación de la regla, 'Nunca escriba casos de prueba usando la aplicación como referencia'. Sin embargo, cuando estamos trabajando en una situación menos que perfecta, tenemos que moldear las reglas para que se ajusten a nuestras necesidades.

Ayuda a mantener los siguientes aspectos en perspectiva al hacerlo:

  • La aplicación puede contener errores, por lo que si después del registro el sistema lo lleva directamente a Screen1 (una determinada pantalla hipotética por el bien de nuestro ejemplo), nunca asuma que ese es el comportamiento correcto. Además, si un campo toma caracteres alfanuméricos y es un número de teléfono, una pregunta, asegúrese de no tomar la aplicación como un ejemplo concedido para la funcionalidad esperada.
  • En las situaciones anteriores, use su juicio y tome la ayuda de la aplicación para comenzar, pero sea crítico para cuestionar que está funcionando.

Método # 3:

Habla con los miembros del equipo del proyecto:

  • Ofrezca asistir a sus reuniones.
  • Pregunte si puede participar en las etapas de prueba de unidad e integración.
  • De lo contrario, pregunte si el equipo de desarrollo puede compartir los resultados de las pruebas de integración y de unidad.
  • Organice un tiempo para la transferencia de conocimientos en un momento conveniente.

Ahora, apliquemos los métodos en un ejemplo:

Supongamos que hay un sitio de compras donde puede agregar artículos al carrito de compras. Idealmente, si hubiera documentación, debe decirnos cómo agregarle artículos, cuántos artículos puede tener en un momento dado, qué sucede cuando el artículo que ha agregado se agota repentinamente, cuál es el número máximo de los mismos artículos que puede comprar al mismo tiempo, etc. Nuestra situación es que NINGUNO de eso está disponible en este momento.

Aplicar el método # 1:

Encuentre toda la documentación que pueda. Pregúntele a su equipo de desarrollo si tienen pantallas de maquetas / miran en la herramienta ALM o algo en absoluto. Si encuentra algo, ese sería un buen punto de partida. Pero si este método no arroja nada, entonces puede usar su juicio / intuición del probador.

Todos sabemos cómo funcionan los carritos de la compra, así que haga sus suposiciones y llegue a algunos escenarios básicos como:

  • Los artículos se pueden agregar al carrito de compras después de navegar o buscar
  • Una vez que agregue artículos al carrito de compras, la lista de artículos debería actualizarse
  • El usuario debería poder seguir comprando incluso después de agregar algunos artículos al carrito
  • Agregar el mismo elemento dos veces hará que se incremente el recuento de elementos agregados
  • Los elementos se pueden actualizar
  • Los elementos se pueden quitar
  • El total debe ser equivalente a la suma de todos los precios agregados
  • Los impuestos deben calcularse en función del código postal ingresado
  • Los costos de envío deben agregarse en consecuencia

Podemos seguir adelante, pero estoy seguro de que te haces una idea.

Aplicar el método 2:

Si hay una versión anterior de la aplicación disponible, esto puede ser útil para escribir sus casos de prueba, ya que tendrá que escribir los pasos exactos de dónde hacer clic, dónde ingresar la entrada, qué verificar, etc. Capturas de pantalla / maquetas / cables- marcos: si están disponibles, también pueden ser excelentes sustitutos.

Como puede ver en la siguiente pantalla, estas cosas son evidentes: los nombres de los campos, los botones u otros elementos presentes, etc. (Pulsa sobre la imagen para agrandarla)

prueba sin requisitos

Ahora, en este punto, los evaluadores tienen algunas preguntas como:

  1. ¿Qué sucede cuando doy un char en el cuadro de cantidad?
  2. ¿Cuándo agrego demasiados elementos?
  3. ¿Cuál es el no máximo? de elementos que esto puede llevar? Etc.

Aplicar el método n. ° 3 :

Lleve su lista de preguntas al BA, Desarrollador o incluso al cliente y busque una aclaración. Una vez que se realiza el método 3, debería estar prácticamente equipado con toda la información que necesitará para escribir casos de prueba detallados y llevar a cabo sus pruebas con tanta confianza como lo haría cuando la documentación elaborada estuviera disponible.

Estuve de acuerdo en que son muchos más pasos y mucho más seguimiento, pero para garantizar las pruebas de calidad, estos pasos son inevitables.

En conclusión, no todo se pierde cuando la documentación no existe o es insuficiente. ¡Aún hay esperanza! Comparta sus experiencias en situaciones similares.

Sobre el Autor: Esta útil publicación está escrita por nuestro miembro del equipo de STH, Swati S.

Como siempre, sus comentarios, preguntas y sugerencias son bienvenidos.

Lectura recomendada

^