Pruebas de software: mitos

A continuación se muestran algunos de los mitos más comunes sobre las pruebas de software.

Mito 1: Las pruebas son demasiado caras

Reality- Hay un dicho, paga menos por las pruebas durante el desarrollo del software o paga más por el mantenimiento o la corrección más adelante. Las pruebas tempranas ahorran tiempo y costos en muchos aspectos; sin embargo, reducir el costo sin probar puede resultar en un diseño incorrecto de una aplicación de software que inutilice el producto.

Mito 2: Las pruebas requieren mucho tiempo

Reality- Durante las fases de SDLC, las pruebas nunca son un proceso que requiera mucho tiempo. Sin embargo, diagnosticar y corregir los errores identificados durante las pruebas adecuadas es una actividad productiva que requiere mucho tiempo.

Mito 3: solo se prueban productos completamente desarrollados

Reality- Sin duda, las pruebas dependen del código fuente, pero revisar los requisitos y desarrollar casos de prueba es independiente del código desarrollado. Sin embargo, el enfoque iterativo o incremental como modelo de ciclo de vida de desarrollo puede reducir la dependencia de las pruebas en el software completamente desarrollado.

Mito 4: Es posible realizar pruebas completas

Reality- Se convierte en un problema cuando un cliente o evaluador piensa que es posible realizar pruebas completas. Es posible que el equipo haya probado todas las rutas, pero nunca es posible que se realicen pruebas completas. Puede haber algunos escenarios que el equipo de prueba o el cliente nunca ejecutan durante el ciclo de vida del desarrollo del software y que pueden ejecutarse una vez que se haya implementado el proyecto.

Mito 5: Un software probado no tiene errores

Reality - Este es un mito muy común en el que creen los clientes, los gerentes de proyecto y el equipo de administración. Nadie puede afirmar con absoluta certeza que una aplicación de software está 100% libre de errores, incluso si un evaluador con excelentes habilidades de prueba ha probado la aplicación .

Mito 6: Los defectos perdidos se deben a los probadores

Reality- No es un enfoque correcto culpar a los probadores de errores que permanecen en la aplicación incluso después de que se han realizado las pruebas. Este mito se relaciona con el tiempo, el costo y los requisitos que cambian las restricciones. Sin embargo, la estrategia de prueba también puede resultar en que el equipo de prueba pase por alto errores.

Mito 7: los probadores son responsables de la calidad del producto

Reality- Es una mala interpretación muy común que solo los probadores o el equipo de prueba deben ser responsables de la calidad del producto. Las responsabilidades de los probadores incluyen la identificación de errores para las partes interesadas y luego es su decisión si corregirán el error o lanzarán el software. Lanzar el software en ese momento ejerce más presión sobre los probadores, ya que serán culpados de cualquier error.

Mito 8: La automatización de pruebas debe usarse siempre que sea posible para reducir el tiempo

Reality- Sí, es cierto que Test Automation reduce el tiempo de prueba, pero no es posible iniciar la automatización de pruebas en ningún momento durante el desarrollo del software. El autómata de prueba debe iniciarse cuando el software se haya probado manualmente y sea estable hasta cierto punto. Además, la automatización de pruebas nunca se puede utilizar si los requisitos siguen cambiando.

Mito 9: Cualquiera puede probar una aplicación de software

Reality- Las personas ajenas a la industria de las tecnologías de la información piensan e incluso creen que cualquiera puede probar un software y probarlo no es un trabajo creativo. Sin embargo, los probadores saben muy bien que esto es un mito. Pensando en escenarios alternativos, intentar bloquear un software con la intención de explorar posibles errores no es posible para la persona que lo desarrolló.

Mito 10: La única tarea de un evaluador es encontrar errores

Reality- Encontrar errores en un software es tarea de los probadores, pero al mismo tiempo, son expertos en el dominio del software en particular. Los desarrolladores solo son responsables del componente o área específica que se les asigna, pero los evaluadores comprenden el funcionamiento general del software, cuáles son las dependencias y los impactos de un módulo en otro módulo.