Existe una variedad considerable entre los escritores y consultores de pruebas de software sobre lo que constituye una prueba de software responsable. Los miembros prominentes de la Escuela de Pruebas Controladas por el Contexto [1] consideran que gran parte de los escritos sobre pruebas de software son doctrina, mitología y folclore. Algunos sostienen que esta creencia contradice directamente estándares como el estándar de documentación de pruebas IEEE 829 y organizaciones como la Administración de Alimentos y Medicamentos que los promueven. La réplica de la escuela basada en el contexto es que las lecciones aprendidas en las pruebas de softwareincluye una lección que apoya el uso de IEEE 829 y otra que lo opone; que no todas las pruebas de software ocurren en un ambiente regulado y que las prácticas apropiadas para tales ambientes serían ruinosamente costosas, innecesarias e inapropiadas para otros contextos; y que, en cualquier caso, la FDA generalmente promueve el principio del enfoque menos gravoso.
Algunas de las principales controversias incluyen:
Mejores prácticas
Muchos miembros de la Escuela de pruebas basada en el contexto creen que no existen las 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 única. James Bach escribió "... no hay práctica que sea mejor que todas las demás prácticas posibles, independientemente del contexto". [2] Sin embargo, algunos profesionales de las pruebas no ven un 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. [3]
Ágil vs.tradicional
A partir de 1990, un nuevo estilo de escritura sobre pruebas comenzó a desafiar lo que había venido antes. El trabajo fundamental en este sentido es ampliamente considerado como Pruebas de software de computadora , por Cem Kaner . [4] 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, también ganó terreno una tendencia opuesta hacia la "madurez" del proceso, en la forma del modelo de madurez de la capacidad . El movimiento de prueba ágil (que incluye, entre otros, formas de prueba practicadas en proyectos de desarrollo ágil ) tiene popularidad principalmente en los 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 considerar otro punto de vista: la cultura operativa de una organización. Si bien puede ser cierto que los probadores 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, los cultivos de prueba son autodirigidos y, como resultado, pueden producirse resultados infructuosos e improductivos. Además, proporcionar evidencia positiva de defectos puede indicar que ha encontrado la punta de un problema mucho mayor o que ha agotado todas las posibilidades. Un marco es una prueba de prueba. Proporciona un límite que puede medir (validar) la capacidad de nuestro trabajo. Ambas partes han discutido 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 probar sistemáticamente si estás demasiado concentrado. Por otro lado, encontrar un montón de errores no es un indicador de que los métodos ágiles fueron la fuerza impulsora; es posible que simplemente se haya topado con un trabajo obviamente pobre.
Exploratorio frente a guion
Las pruebas exploratorias significan el diseño y la ejecución de pruebas simultáneas con énfasis en el aprendizaje. Las pruebas con guiones significan que el aprendizaje y el diseño de la prueba ocurren antes de la ejecución de la prueba y, con frecuencia, el aprendizaje debe realizarse nuevamente durante la ejecución de la prueba. Las pruebas exploratorias son muy comunes, pero en la mayoría de los escritos y entrenamientos sobre pruebas apenas se mencionan y generalmente se malinterpretan. Algunos escritores lo consideran una práctica primaria y esencial. Las pruebas exploratorias estructuradas son un compromiso cuando los probadores están familiarizados con el software. Se redacta un plan de prueba vago, conocido como estatuto de prueba, que describe qué funcionalidades deben probarse pero no cómo, lo que permite a los probadores individuales elegir el método y los pasos de prueba.
Hay dos desventajas principales asociadas con un enfoque de prueba principalmente exploratorio. 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 la prueba y lograr la repetibilidad de las pruebas utilizando un enfoque de prueba puramente exploratorio. Por esta razón, a menudo se utiliza un enfoque combinado de pruebas exploratorias y programadas para obtener los beneficios y mitigar las desventajas de cada enfoque.
Manual vs automatizado
Algunos escritores creen que la automatización de pruebas es tan cara en relación con su valor que debería utilizarse con moderación. [5] 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 mediante el cual se puede reconocer un problema en el software). Dichas herramientas tienen valor en el software de prueba de carga (al iniciar sesión en una aplicación con cientos o miles de instancias simultáneamente) o al verificar errores intermitentes en el software. El éxito de las pruebas de software automatizadas depende de una planificación de pruebas completa y completa. Las estrategias de desarrollo de software, como el desarrollo impulsado por pruebas, son altamente compatibles con la idea de dedicar una gran parte de los recursos de prueba de una organización a las pruebas automatizadas. Muchas grandes organizaciones de software realizan pruebas automatizadas. Algunos han desarrollado sus propios entornos de prueba automatizados específicamente para el desarrollo interno y no para la reventa.
Diseño de software frente a implementación de software
[ non sequitur ]
Si las pruebas de software recopilan información sobre un producto o programa para las partes interesadas, entonces no se sigue que haya una opción entre probar la implementación o el diseño, es decir, esta es una suposición errónea. [ aclaración necesaria ] Idealmente, los probadores de software no deberían limitarse 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 tal entorno, el ciclo de prueba también cambiará. Para probar el diseño de 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 antes en el desarrollo de software.
¿Quién vigila a los vigilantes?
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 alternativamente se le conoce informalmente como el concepto de " Heisenbug " (un concepto erróneo común que confunde el concepto de Heisenberg ). principio de incertidumbre con efecto 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 lo que se está probando.
En términos prácticos, el ingeniero de pruebas está probando software (y en ocasiones hardware o firmware ) con otro software (y hardware y firmware). El proceso puede fallar en formas que no son el resultado de defectos en el objetivo, sino que son el resultado de defectos en (o características intencionadas de) la herramienta de prueba.
Se están desarrollando métricas para medir la efectividad 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 se cubren en absoluto y tratar de mejorar la cobertura en estas áreas.
Los errores también se pueden colocar en el código a propósito, y la cantidad de errores que no se han encontrado se puede predecir en función del porcentaje de errores colocados intencionalmente que se encontraron. El problema es que asume que los errores intencionales son el mismo tipo de error que los involuntarios.
Finalmente, está el análisis de las tasas de hallazgo históricas. Al medir cuántos errores se encuentran y compararlos con los números predichos (según la experiencia pasada con proyectos similares), se pueden hacer ciertas suposiciones con respecto a la efectividad de las pruebas. Si bien no es una medida absoluta de la calidad, si un proyecto está a medio camino y no se han encontrado defectos, es posible que se necesiten cambios en los procedimientos empleados por QA.
Referencias
- ^ context-driven-testing.com
- ^ Bach, James (8 de julio de 2005). "Sin mejores prácticas" . Consultado el 5 de febrero de 2018 .
- ^ Colantonio, Joe (13 de abril de 2017). "Mejores prácticas frente a buenas prácticas: despotricar con Rex Black" . Consultado el 5 de febrero de 2018 .
- ^ Kaner, Cem ; Jack Falk; Hung Quoc Nguyen (1993). Prueba de software informático (tercera ed.). John Wiley e hijos. ISBN 1-85032-908-7.
- ^ Un ejemplo es Mark Fewster, Dorothy Graham: Software Test Automation. Addison Wesley, 1999, ISBN 0-201-33140-3