Depende de demasiados factores para generalizar. Trabajando en un entorno ágil (a nivel de unidad), he encontrado una docena de errores al día, sin embargo, desarrollé una relación con el desarrollador en el que cortó el código y (básicamente) lo depuré en un marco de prueba que ideé.
En el otro extremo, una corporación me pidió que auditara el código escrito por los contratistas. No pude encontrar ningún error sustancial (solo pequeños errores molestos) pero el código no funcionó. La falla fue rastreada hasta la etapa de especificación; los codificadores habían implementado ciegamente la especificación para un producto de capa de comunicación que tenía fallas fundamentales (y que requería una reescritura sustancial).
En el medio, he visto varios casos de excelentes programadores contra cuyo código tal vez podría encontrar un error funcional en 2,000 líneas de código ejecutable (que a menudo me llevó hasta una semana analizar completamente).
- ¿Qué es la modernización de software? ¿Por qué es importante para cualquier software? ¿Cuáles son las herramientas disponibles para la modernización del software?
- ¿Qué papel, en todo caso, desempeñará Dassault Systemes en la prometedora industria de la impresión 3D?
- ¿Existen instituciones financieras que realizan una integración continua o incluso una entrega continua?
- ¿Dónde está un software / programa de modelado matemático sin código?
- ¿Cómo puedo encontrar empleados en el área de la bahía (principalmente ingenieros de hardware y software, desarrolladores de sistemas)?
A veces, los errores son obvios, por ejemplo, una falla en una página web. Otras veces, el error es lo que se conoce como “caso de esquina” y solo ocurre cuando golpeas el código con tiempo crítico, tamaño de datos, secuencia de estado, etc. Como probador, el truco para encontrarlos es analizar el requisito, deducir el caso de esquina , luego idear un medio para probarlos. Este enfoque funcionó particularmente bien para la transmisión de medios.
Espero que vean que no se trata solo de cuántos errores encontramos; a veces es la “calidad” del error lo que cuenta. Encontrar los errores oscuros a menudo requiere un amplio conocimiento del dominio en el que está trabajando (los medios, por ejemplo, la concurrencia de la base de datos sería otra). los requisitos reales del producto y una visión sólida de cómo funciona el código. ¡Este último factor rompe el concepto de “caja negra” de pruebas que las personas inexpertas a veces se adhieren ciegamente!
En un caso, durante la investigación del código de funcionamiento deficiente, pude diseñar una nueva arquitectura de software para esa parte del producto, que fue implementada por un ingeniero de clase y posteriormente no generó más problemas.
Finalmente, el peor de los casos fue un protocolo de tarjeta de cable que me pidieron que depurara. ¡Me di por vencido con alrededor de 180 errores encontrados solo con la lectura de código! Al final me pidieron que volviera a escribir completamente el producto, desde cero, lo que me llevó casi seis meses.
Las pruebas se realizan en diversos momentos y en diversos niveles de sofisticación. Creo que, como ingeniero de validación, mi primer trabajo es “probar” la especificación para validar que es correcta y suficiente para formar la base para un trabajo constructivo. También probamos el código a nivel de unidad, nivel de integración y finalmente a nivel de sistema. Generalizando, cuanto más tarde encontramos errores, más cuestan arreglarlos (ya sea en términos de demora o satisfacción del cliente).