Incluso los probadores profesionales desde hace mucho tiempo, respetados, le dirán: es un arte más que una ciencia.
Mi truco para diseñar nuevos casos de prueba comienza con los diversos tipos de pruebas que menciona, y debe incluir todos los que sean exhaustivos, pero trato de encontrar una lista de todas las formas en que puedo interactuar con el código/producto .
Para el ejemplo de máquina expendedora, hay toneladas de partes, por dentro y por fuera.
prueba simple, ya que el producto está diseñado para trabajar, da un montón de casos
- ¿Da el cambio correcto
- ¿Qué tan rápido puede procesar la solicitud
- Qué pasa si un artículo está fuera Stock de
- ¿y si se llena excesivamente
- ¿Qué pasa si el cajón está lleno cambio
- ¿Qué pasa si los artículos son demasiado grandes, o ABVD y acumuló
- ¿Qué pasa si el usuario pone en muy poco dinero
- Lo que si está fuera del cambio
Luego están los casos interesantes, que los usuarios normales no pensar.
- ¿Qué pasa si se intenta volcar
- Darle una moneda falsa
- robar de que
- Poner una moneda en una cadena de
- Darle cantidades divertidos del cambio
- Déle billetes medio rasgados
- Pry it open con una barra de cuerno
- Alimentarlo mal potencia/oscurecimiento
- Lo apago en medio de varias operaciones
La manera de pensar como un probador es averiguar todas las formas posibles que puede atacar a él, de todos los "casos divertidos" en escenarios habituales, a toda la métodos que están completamente fuera de cómo debería usarse. Cualquier punto de entrada, incluidos los que creas que los desarrolladores/propietarios tienen control, son un juego justo.
También puede utilizar muchas herramientas de prueba automatizadas, como selección de prueba por pares, kits de herramientas de prueba basados en modelos, o para software, diversas herramientas de estrés/carga y seguridad.
Siento que esta respuesta fue un buen comienzo, pero ahora me doy cuenta de que era solo la mitad de la historia.
Proceder de todas las formas en que puede probar el sistema es importante. Debe aprender a estirar los límites de su imaginación, sus habilidades de descomposición de problemas, su comprensión de las cadenas de funcionalidad/falla y su conocimiento de dominio sobre lo que está probando. Este es el punto que estaba tratando de hacer arriba. Con la mentalidad correcta y con la suficiente vigilancia, estas habilidades comenzarán a mejorar muy rápidamente, dentro de un año o en unos pocos años (dependiendo de la complejidad del dominio).
El segundo nivel para convertirse en un examinador muy competente es determinar qué pruebas debe tener en cuenta. Siempre podrás romper todos los sistemas de muchas maneras diferentes. Si esas fallas son importantes o no es una pregunta más interesante, y a menudo es mucho más difícil de responder. El beneficio de responder a esta pregunta, sin embargo, es doble.
En primer lugar, si sabe por qué es importante reparar piezas del sistema que se rompen (o omitir su fijación), entonces puede comprender dónde debe enfocar sus esfuerzos. Ya sabe lo que puede permitirse pasar menos tiempo probando y en qué debe dedicarle más tiempo.
En segundo lugar, y lo que es más importante, ayudará a su equipo a exponer dónde deben concentrarse sus esfuerzos. Comenzarás a descubrir cosas que se llaman "incógnitas de segundo orden". Tu equipo no sabe lo que no sabe.
El truco principal que le ayuda a lograr esto es siempre preguntar "¿por qué?", Hasta que lo que está preguntando está perplejo.
Un ejemplo:
Q: ¿Por qué esta prueba?
A: Porque quiero ejercer toda la funcionalidad en el sistema.
Q: ¿Por qué funciona este sistema de esta manera?
A: Debido a las decisiones que tomó el programador, según las especificaciones del producto.
Q: ¿Por qué las especificaciones de nuestros productos lo solicitan?
A: Porque la empresa para la que estamos escribiendo el software tenía la obligación de que el software funcione de esta manera.
Q: ¿Por qué esa empresa que contratamos lo agrega como requisito?
A: Debido a que sus usuarios tienen que hacer: cosa:
Q: ¿Por qué tienen que hacer los usuarios: cosa :?
A: Debido a que están tratando de lograr: xyz:
Q: ¿Por qué necesitan para llevar a cabo: xyz:
A:, ya que ahorran dinero al hacerlo: abc :
Q: ¿Por qué eligieron: xyz: para resolver: abc :?
A: ... buena pregunta.
Q: ¿Qué podrían hacer en su lugar?
A: ... ahora que lo pienso, ¡hay un montón de opciones! Tal vez uno de ellos funciona mejor?
Con la práctica, comenzará a saber qué preguntas específicas de "por qué" hacer y en qué concentrarse. También aprenderá a comenzar más profundo en la cadena, y será menos mecánico en su enfoque.
Esto ya no se trata solo de asegurar que el producto cumpla con las especificaciones que el desarrollador, el cliente final o el usuario final proporcionaron. También ayuda a determinar si la solución que está brindando es la solución de mayor calidad que su equipo podría proporcionar.
Un requisito oculto de esto es que debe aprender que la mitad de su trabajo como probador es hacer preguntas todo el tiempo. Puede pensar que sus compañeros de equipo estarán molestos con esto, pero espero haber demostrado que es crucial para su desarrollo y la calidad del producto que está probando. Compañeros de equipo inteligentes y curiosos que se preocupan por el producto (que no están ocupados y frustrados) amará sus preguntas.
Wiki de la comunidad? –
@Praveen S: Probablemente. La pregunta/tema es muy subjetivo –