Cómo probar sin una especificación

Hay especificaciones incluso cuando no hay especificaciones.

Hay dos tipos de especificaciones:

• Especificaciones explícitas
• Especificaciones implícitas

Por ejemplo, en documentos financieros, los números de secuencia son únicos, nunca se usan dos veces. Para un contador esto es absolutamente claro. Para un programador, no tanto. Esto debe enunciarse y se convierte en una especificación explícita para el programador. Si el programador tiene conocimiento de dominio, este bit de información permanecerá implícito.

El software y los sistemas de telecomunicaciones se prueban mejor por ingenieros de telecomunicaciones. Solo toma 6 años adquirir los principios que guían los protocolos y las redes. El dominio es demasiado vasto y algo que puede expresarse en un par de palabras y que parece funcionar para los no iniciados puede ser profundamente defectuoso.

Utilizamos el conocimiento del dominio y el sentido común cuando tratamos con requisitos faltantes del tipo explícito.

Con o sin especificación, para poder realizar buenas pruebas necesita reunir la información necesaria para poder definir lo siguiente:

• ¿Qué cliente realmente necesita?

Entonces obtienes los requisitos del cliente. El software que no puede satisfacer las necesidades del cliente o no puede resolver el problema del cliente es inútil. Nadie le pagará dinero por eso y está fuera del negocio.

La especificación se puede incluir en esto, ya que la especificación es para responder a la pregunta de “¿Cómo se diseña o desarrolla el software para cumplir con los requisitos?

Los casos de prueba se basarán en información que pueda reunir en torno a los requisitos.

• ¿Qué está dentro del alcance de las pruebas? y ¿Qué está fuera de alcance?

El tiempo y los recursos siempre son limitados. No podemos pasar el tiempo probando para siempre y necesitamos saber exactamente qué se debe probar. ¿Qué no es importante?

• ¿Qué son las prioridades?

No todo es importante. Deberíamos pasar la mayor parte del tiempo en cosas que son cruciales para los negocios.

• ¿Cuánto tiempo tenemos? ¿Cuáles son esos recursos que podríamos usar?

Al saber esto, podríamos planificar nuestras estrategias para ofrecer lo mejor a tiempo.

• ¿Cuáles son esas informaciones que necesitas averiguar? ¿Quiénes son los que necesitan información?

El trabajo de Software Tester es recopilar información adecuada para partes interesadas específicas para tomar una decisión adecuada. La información debe recopilarse, analizarse e informarse de manera adecuada.

Estos también serán sus objetivos de prueba, ya que necesita encontrar la respuesta a las preguntas de las partes interesadas.

Sin especificación: no hay problema.

Habría interesados ​​con los que trabajará. Traiga un documento y vaya a discutir con ellos para averiguar la información que necesita. Todos los que sean relevantes para el proyecto ayudarían (Gerente de proyecto, Cliente, Desarrollador, Usuario, Líder del equipo de desarrollo, Líder del equipo de prueba, Otros probadores, Quien tenga experiencias en la aplicación)

Siga buscando la información que necesita hasta que pueda obtener la información adecuada para realizar el trabajo.

Puede hacer lo mejor que pueda solo con el tiempo y los recursos disponibles. Y no comience nada sin objetivos y plan.

Sea claro sobre lo que hará ?, su plan y su actualización de estado.

Todo estará bien y divertido 🙂

Por cierto, las pruebas basadas en la estructura, si son relevantes para las PRUEBAS DE CAJA NEGRA, son mapear las características / componentes del software en una estructura específica (ver cómo se unieron) y luego planificar la prueba de acuerdo con eso. También podría aplicar esto, pero es mejor que redacte primero la lista de Características / Componentes antes de comenzar a hacer cualquier cosa.

No todo el tiempo las pruebas basadas en estructura serían la mejor solución.

Pero normalmente, el término se usa para WHITE BOX TESTNG y se usa para Cobertura de prueba y Diseño de caso de prueba cuando conoce la estructura del código.

Dado que no tiene especificación, no tendrá idea del mapeo.

Debe conocer el producto y cuál es su propósito. Supongo que tiene alguna comprensión sobre cómo operar el sistema para explorarlo.

A partir de ahí, vea que hace lo que se supone que debe lograr. piense en las formas en que se puede usar para romperlo. consulte con marketing / producto sobre cómo esperan que los clientes lo usen. Piense en cuáles deberían ser las limitaciones del producto: volúmenes, interacciones con otros componentes, entradas …

También puede seguir las pruebas exploratorias, lo que significa que dedicará una cantidad X de tiempo a probar una sola idea a través del producto. ¿Qué volúmenes puede contener? ¿Es buena la IU? Hay ideas para preguntas que circulan por Internet.

Las especificaciones son una guía. Utilice los criterios de aceptación que debería haber recibido. Si no hay ninguno, hable con el equipo para obtener más información sobre las características que se están desarrollando.

En ágil, el equipo posee la calidad, por lo tanto, hágales poseerla para que puedan crear una especificación de algún tipo de documento de diseño para usar para construir y ejecutar sus casos de prueba.

Puedes probar cualquier cosa como prueba de exploración