Dos estrategias se pueden aplicar para identificar defectos en los productos de software, las revisiones técnicas y las pruebas del software. Mientras que las primeras pueden aplicarse desde etapas tempranas del proceso de desarrollo de software, inclusive desde la especificación de requisitos, las últimas requieren que exista el código del software para ejecutarlo y mostrar los defectos que podrían haber detectado los casos de prueba aplicados. Un problema asociado a la prueba dinámica del software son los problemas que surgen con el tamaño del software y las distintas alternativas de código que deberían ejecutarse. Dada la complejidad de los sistemas de software modernos, es imposible probar todas alternativas que se presentan en el producto (Humphrey, 2008).
La calidad del software se debe evaluar en los productos que se desarrollan en etapas tempranas del ciclo de vida. Para ello, se pueden emplear distintos tipos de revisiones técnicas. Las revisiones técnicas pueden incluir aquellas informales, que se discuten cuando se toma un café, hasta aquellas altamente formales, en donde se definen roles, se levantan actas y se consensa la lista de defectos encontrados.
Las revisiones informales se caracterizan por no tener documentado un proceso, el objetivo de la reunión no está centrado en la detección de faltas y en general, se realizan de manera improvisada. Por tanto, es difícil determinar su efectividad, en términos de la cantidad de defectos encontrados (Laporte y April, 2018).
Las revisiones formales pueden ser desde revisión personal, revisión de escritorio, caminata e inspección (Laporte y April, 2018). A continuación se presenta la descripción de dos de ellas. Ambas son métodos efectivos para detectar errores y, si éstos se corrigen, podrían mejorar significativamente la calidad del producto.
Revisión de escritorio. Esta revisión sirve para detectar, en los productos de software bajo evaluación, anomalías, omisiones, mejoras al producto o descubrir alternativas. La implementación de esta revisión no es costosa y es fácil de implementar. Para cada tipo de producto que se revisará, se necesita una lista de chequeo específica que haya sido desarrollada (o adaptada por la organización). El producto por revisar y la lista de chequeo se envían a uno o varios revisores. Después, los revisores analizan el producto tomando en cuenta la lista de chequeo y reportan las inconsistencias que hayan detectado. Los reportes de los revisores se analizan por el autor del producto, quien se encarga de registrar todas aquellas observaciones relevantes. Si el autor del producto considera que las observaciones tendrían un impacto mayor en el producto, puede realizar una reunión presencial con los revisores. Al final el autor del producto corrige los defectos encontrados y genera la lista de defectos corregidos. En cada producto de la revisión generado se debe registrar el esfuerzo invertido en el análisis del producto (Laporte y April, 2018)
Inspección. El propósito de la inspección es detectar e identificar anomalías en el producto de software, incluyendo errores y desviaciones de estándares y especificaciones. Es un proceso formal en el cual se definen los roles de cada uno de los participantes (de 3 a 6 desarrolladores de software), en donde un moderador entrenado se encarga de llevar la sesión presencial. En general, el tamaño del producto que se revisa es pequeño y el equipo de revisión debe usar estándares y/o listas de chequeo para verificar el producto. La inspección tiene tres etapas, pre-revisión, revisión, post-revisión. En la etapa de pre-revisión, los revisores analizan de forma individual el producto, durante la revisión, moderador, autor del producto y revisores se reúnen para discutir los hallazgos de cada uno de los revisores. El valor de esta reunión es encontrar otros defectos por el efecto sinérgico de las interacciones que se establecen entre los revisores. Al final de la reunión se obtiene una lista de errores que deberían ser atendidos por el autor del producto bajo revisión. En la etapa de post-revisión, el moderador verifica que el autor haya corregido el producto.