Hace mucho tiempo vi un breve documental sobre pruebas de software. En él había ingenieros y gente de la NASA, el ejército de los EE. UU. Y probablemente algunas grandes corporaciones. Creo que algunas personas de Acdemia también (no recuerdo y la película no se encuentra en ninguna parte en YouTube).
Dos cosas quedaron en mi mente de esta película:
- Un dicho que para cada línea de código de programa hay entre 3 y 7 líneas de código de prueba
- En algunas áreas, el riesgo de no realizar pruebas correctamente es demasiado alto y es por eso que tenemos humanos controlando el lanzamiento de misiles nucleares y no software
Esos dos combinados han demostrado ser ciertos hasta ahora en mi carrera de prueba de más de 10 años.
- ¿Existe un mercado para desarrollar software de bioinformática?
- ¿Cuáles son algunos buenos ejemplos de software de mercado vertical?
- ¿Me puede recomendar un buen software 3D para diseñar hardware?
- ¿Qué solicitud de función le daría prioridad al número 1?
- Quiero hacer Electro Music. ¿Qué software y hardware necesito para esto?
Puede ser difícil y complejo crear programas que resuelvan problemas en un dominio particular, pero en mi opinión, es aún más complejo y difícil crear pruebas para ellos. Y luego vienen las preguntas existenciales: ¿cómo sabemos que estamos probando correctamente? ¿Cuántas pruebas son suficientes? ¿Estamos probando lo correcto (primero definamos lo correcto) y lo más importante de todos los que están probando las pruebas?
Creo que las pruebas de software y la garantía de calidad son el dominio más complejo en la industria de la ingeniería de software.
ACTUALIZAR:
Como mencionó Joe Two Crows en un comentario a esta respuesta, un probador de software esencialmente necesita ser un buen desarrollador más
b) las habilidades de comunicación para expresar problemas a un público tanto técnico como no técnico,
c) la capacidad de interpretar los requisitos de tal manera que demuestre a satisfacción del desarrollo y la gestión la idoneidad (o falta) del software bajo prueba,
d) la idea de cómo el software es o será utilizado por el cliente, y
e) el temperamento para hacer frente a las críticas increíblemente duras de todos los interesados.
Estoy completamente de acuerdo con el comentario de Joe y también agregaré
f) la capacidad de evaluar adecuadamente el riesgo comercial causado por problemas técnicos. Esto está directamente relacionado con d) pero requiere la comprensión tanto de los clientes como de la organización y el negocio del empleador. Por ejemplo, la documentación mal escrita o los escenarios no obvios / no intuitivos pueden generar muchas llamadas de soporte para el negocio (alto riesgo), pero pueden resolverse con un esfuerzo de desarrollo relativamente pequeño (y no ser una prioridad para el equipo de desarrollo )
