Existe una considerable variedad entre los escritores y consultores de pruebas de software sobre lo que constituye una prueba de software responsable. Los defensores de un enfoque basado en el contexto [1] consideran que gran parte de lo escrito sobre pruebas de software es doctrina, mientras que otros creen que esto contradice el estándar de documentación IEEE 829. [2]
Los defensores del enfoque basado en el contexto creen que no existen mejores prácticas de prueba, sino que las pruebas son un conjunto de habilidades que permiten al evaluador seleccionar o inventar prácticas de prueba que se adapten a cada situación particular. James Marcus Bach escribió que "no existe ninguna práctica que sea mejor que todas las demás prácticas posibles, independientemente del contexto". [3] Sin embargo, algunos profesionales de las pruebas no ven ningún problema con el concepto de "mejores prácticas" y no creen que ese término implique que una práctica sea de aplicación universal. [4]
A partir de 1990, un nuevo estilo de escritura sobre pruebas comenzó a desafiar lo que había venido antes. El trabajo seminal en este sentido es ampliamente considerado como Testing Computer Software , de Cem Kaner . [5] En lugar de asumir que los evaluadores tienen acceso completo al código fuente y especificaciones completas, estos escritores, incluidos Kaner y James Bach , argumentaron que los evaluadores deben aprender a trabajar en condiciones de incertidumbre y cambio constante. Mientras tanto, una tendencia opuesta hacia la "madurez" del proceso también ganó terreno, en la forma del Modelo de madurez de capacidad . El movimiento de pruebas ágiles (que incluye, pero no se limita a, formas de prueba practicadas en proyectos de desarrollo ágiles ) tiene popularidad principalmente en círculos comerciales, mientras que el CMM fue adoptado por proveedores de software gubernamentales y militares.
Sin embargo, decir que los "modelos de madurez" como CMM ganaron terreno o se opusieron a las pruebas ágiles puede no ser correcto. El movimiento ágil es una "forma de trabajar", mientras que CMM es una idea de mejora de procesos.
Pero hay que tener en cuenta otro punto de vista: la cultura operativa de una organización. Si bien es cierto que los testers deben tener la capacidad de trabajar en un mundo de incertidumbre, también es cierto que su flexibilidad debe tener una dirección. En muchos casos, las culturas de testeo son autodirigidas y, como resultado, pueden producirse resultados infructuosos e improductivos. Además, proporcionar evidencia positiva de defectos puede indicar que se ha encontrado la punta de un problema mucho mayor o que se han agotado todas las posibilidades. Un marco de trabajo es una prueba de Testing. Proporciona un límite que puede medir (validar) la capacidad de nuestro trabajo. Ambas partes han defendido y seguirán defendiendo las virtudes de su trabajo. Sin embargo, la prueba está en todas y cada una de las evaluaciones de la calidad de la entrega. De poco sirve hacer pruebas sistemáticas si se tiene un enfoque demasiado estrecho. Por otro lado, encontrar un montón de errores no es un indicador de que los métodos Agile hayan sido la fuerza impulsora; es posible que simplemente haya tropezado con un trabajo obviamente deficiente.
Las pruebas exploratorias implican el diseño y la ejecución simultáneos de las pruebas, con énfasis en el aprendizaje. Las pruebas con guiones implican que el aprendizaje y el diseño de las pruebas se realizan antes de la ejecución de las pruebas y, con frecuencia, el aprendizaje debe repetirse durante la ejecución de las pruebas. Las pruebas exploratorias son muy comunes, pero en la mayoría de los escritos y cursos de formación sobre pruebas apenas se mencionan y, por lo general, se malinterpretan. Algunos autores las consideran una práctica primaria y esencial. Las pruebas exploratorias estructuradas son un compromiso cuando los evaluadores están familiarizados con el software. Se redacta un plan de pruebas vago, conocido como carta de pruebas, que describe qué funcionalidades deben probarse, pero no cómo, lo que permite a los evaluadores individuales elegir el método y los pasos de las pruebas.
Existen dos desventajas principales asociadas con un enfoque de pruebas principalmente exploratorias. La primera es que no hay oportunidad de prevenir defectos, lo que puede suceder cuando el diseño de pruebas por adelantado sirve como una forma de prueba estática estructurada que a menudo revela problemas en los requisitos y el diseño del sistema. La segunda es que, incluso con cartas de prueba, es difícil demostrar la cobertura de las pruebas y lograr la repetibilidad de las pruebas utilizando un enfoque de pruebas puramente exploratorias. Por este motivo, a menudo se utiliza un enfoque combinado de pruebas exploratorias y con guiones para aprovechar los beneficios y mitigar las desventajas de cada enfoque.
Algunos autores creen que la automatización de pruebas es tan cara en relación con su valor que debería utilizarse con moderación. [6] Otros, como los defensores del desarrollo ágil , recomiendan automatizar el 100 % de todas las pruebas. Un desafío con la automatización es que las pruebas automatizadas requieren oráculos de prueba automatizados (un oráculo es un mecanismo o principio por el cual se puede reconocer un problema en el software). Estas herramientas tienen valor en las pruebas de carga de software (al iniciar sesión en una aplicación con cientos o miles de instancias simultáneamente) o en la verificación de errores intermitentes en el software.
El éxito de las pruebas automatizadas de software depende de una planificación completa e integral de las pruebas. Las estrategias de desarrollo de software, como el desarrollo basado en pruebas, son muy compatibles con la idea de dedicar una gran parte de los recursos de pruebas de una organización a las pruebas automatizadas. Muchas grandes organizaciones de software realizan pruebas automatizadas. Algunas han desarrollado sus propios entornos de pruebas automatizadas específicamente para el desarrollo interno y no para la reventa.
[ sin sentido ]
Si las pruebas de software consisten en recopilar información sobre un producto o programa para las partes interesadas, no se deduce que haya una elección entre probar la implementación o el diseño; es decir, se trata de una suposición errónea. [ Aclaración necesaria ] Lo ideal sería que los evaluadores de software no se limitaran solo a probar la implementación del software, sino también a probar el diseño del software. Con esta suposición, el papel y la participación de los evaluadores cambiarán drásticamente. En un entorno así, también cambiará el ciclo de pruebas. Para probar el diseño del software, los evaluadores revisarían los requisitos y las especificaciones de diseño junto con el diseñador y el programador, lo que podría ayudar a identificar errores en una etapa más temprana del desarrollo del software.
Un principio en las pruebas de software se resume en la clásica pregunta latina planteada por Juvenal: Quis Custodiet Ipsos Custodes (¿Quién vigila a los vigilantes?), o se conoce de manera informal como el concepto de " Heisenbug " (un error común que confunde el principio de incertidumbre de Heisenberg con el efecto del observador ). La idea es que cualquier forma de observación es también una interacción, que el acto de probar también puede afectar aquello que se está probando. [7]
En términos prácticos, el ingeniero de pruebas prueba software (y, a veces, hardware o firmware ) con otro software (y hardware y firmware). El proceso puede fallar de maneras que no son el resultado de defectos en el objetivo, sino más bien el resultado de defectos en la herramienta de prueba (o en las características previstas de esta).
Se están desarrollando métricas para medir la eficacia de las pruebas. Un método consiste en analizar la cobertura del código (esto es muy controvertido), donde todos pueden ponerse de acuerdo sobre qué áreas no están cubiertas en absoluto y tratar de mejorar la cobertura en esas áreas.
También se pueden introducir errores en el código a propósito, y se puede predecir la cantidad de errores que no se han encontrado en función del porcentaje de errores introducidos intencionalmente que se encontraron. El problema es que se supone que los errores intencionales son del mismo tipo que los no intencionales.
Por último, está el análisis de las tasas de detección históricas. Al medir la cantidad de errores detectados y compararlos con las cifras previstas (basadas en la experiencia previa con proyectos similares), se pueden hacer ciertas suposiciones sobre la eficacia de las pruebas. Si bien no se trata de una medida absoluta de la calidad, si un proyecto está a mitad de camino y no se han encontrado defectos, es posible que sea necesario realizar cambios en los procedimientos que emplea el control de calidad.