LIZZON ANDRÉS BECERRA MOYA

§ Prueba, por definición según la RAE es: Acción

de probar a alguien o algo para conocer sus
cualidades, verificar su eficacia, saber cómo
funciona o reacciona, o qué resultado produce.
§El error es una acción humana que produce
un resultado incorrecto.
§El defecto, también llamado falta, es la
manifestación de ese error en el código.
§La falla es la manifestación del defecto al
usar el sistema.
§ Según Cem Kaner es una investigación técnica realizada
para proveer información a los stakeholders sobre la
calidad del producto o servicio bajo pruebas.
§ Según Glenford Myers, software testing es un proceso
diseñado para asegurar que el código hace lo que se
supone que debe hacer y no hace lo que se supone que no
debe. Se trata de un proceso en el que se ejecuta un
programa con el objetivo de encontrar errores.
§ se trata de un proceso en el que se ejecuta un programa
con el objetivo de encontrar errores.
§ Cuando hablamos de fallos o bugs nos referimos en
un sentido muy amplio que puede incluir desde
errores, diferencias con la especificación,
oportunidades de mejora desde distintos puntos de
vista de la calidad: funcional, performance,
usabilidad, estética, seguridad, etc., etc.
§ La forma en la que estaremos aportando calidad es
principalmente buscando fallos.
§ Encontrar la mayor cantidad de errores.
§ Dar seguridad a los usuarios, enfocando el testing en
los escenarios más usados por los clientes.
§ Más allá de cada uno de los métodos específicos
que sin duda enriquecerán ampliamente nuestras
aptitudes y rendimiento, permitiéndonos diseñar
casos de prueba, ejecutar pruebas exploratorias,
realizar pruebas automatizadas y mucho más,
resulta indispensable contar con una colección de
principios esenciales que nos servirán de guía y
serán de gran utilidad en nuestro afán por realizar
nuestro trabajo con seriedad y dedicación.
§ El testing nos permite demostrar la existencia de
incidentes en un producto, no su ausencia. Tras el
reporte de un incidente y su consecuente
restauración, es posible reducir la probabilidad de
que incidentes aún no descubiertos persistan en el
sistema, pero la inexistencia absoluta de incidentes
no sólo resulta imposible de comprobarse sino que
además es una posibilidad sumamente improbable.
Exceptuando casos puntuales, probar cada combinación
posible de datos y acciones en todas las
funcionalidades de un software generalmente no es una
opción viable, ya sea por cuestiones de tiempo, costos o
recursos.
Por este motivo, al estructurar nuestras estrategias y
diseñar los casos de pruebas, resulta muy conveniente
considerar estos factores, para poder enfocarnos en
ejecutar las verificaciones más significativas y que
tengan mayor impacto.
Cuando el proceso de testing comienza en las
etapas más tempranas del desarrollo de software,
esta alianza resulta extremadamente beneficiosa,
pues permite detectar incidentes en los albores del
producto. El costo de reparación de estos incidentes
sería significativamente más elevado si recién fueran
detectados en fases posteriores.
§ Generalmente, hay ciertos módulos y funcionalidades que son más
proclives a presentar incidencias (de mayor prioridad) en
comparación al resto de las partes que conforman un producto. Este
fundamento está relacionado con la Regla 80/20, que afirma que
aproximadamente el conforme 80% de las consecuencias emergen
del 20% de las causas.
§ En términos más precisos, esto podría traducirse de la siguiente
manera: no todos los componentes de un software poseen el mismo
nivel de relevancia, por lo que el enfoque más propicio en el
momento de elaborar nuestra estrategia de pruebas es concentrar
nuestros esfuerzos justamente en esas partes más cruciales, para
detectar aquellos incidentes que puedan resultar más urgentes de
resolver.
§ Ejecutarlos mismos tests en una misma parte estable de un sistema
repetidas veces es una práctica que tiende a dificultar la detección
de nuevos incidentes que aún no han sido descubiertos.
§ Porconsiguiente, para aumentar las posibilidades de detección de
incidentes, es imprescindible revisar y actualizar de manera
constante nuestra estrategia de pruebas y asegurarnos de explorar
las diversas partes que componen el producto con mayor
profundidad.
§ Laestrategia y el tipo de pruebas serán seleccionados en función del
sistema y a los entornos que se pretenden verificar. Por ejemplo, un
software médico no será probado de la misma forma que un sistema
de e-commerce.
§ Losprocedimientos estructurados, así como los casos diseñados,
serán seleccionados teniendo en consideración todos y cada uno de
estos factores.
§ Supongamos que todos los incidentes detectados en un sistema dado
son corregidos. A continuación, se realiza un nuevo ciclo de pruebas,
tras el cual no se detecta la presencia de nuevos incidentes.
§ La ausencia de nuevos errores detectados no implica
necesariamente que el software sea útil, ya que la utilidad del mismo
no es indicada por este parámetro, sino por la satisfacción de las
expectativas del cliente que el producto pueda brindar.
§ Los factores internos serían, por ejemplo, la capacidad de mantenimiento y todo
lo que tenga que ver con la calidad del código. Se denominan factores internos
porque tienen que ver con el funcionamiento interno del producto justamente
porque que el usuario no los puede percibir a primera vista.
§ Los factores externos son aquellos de los que el usuario puede experimentar
directamente, tales como:
§ Performance: los usuarios se ven afectados cuando el sistema, la web o la
aplicación se ejecuta lentamente.
§ Funcionalidad: Cuando hay demasiados errores, el usuario se ve impedido al no
poder interactuar o realizar transacciones.
§ Usabilidad: Los usuarios sufren cuando el producto digital no es suficientemente
amigable.
§ Porotro lado, estos factores externos e internos no siempre son tan
excluyentes. Hay muchos que son ciertamente internos y externos
como la seguridad.
§ Otroaspecto que es realmente interesante, es que factores internos
como la mantenibilidad pueden volverse externos en cualquier
momento. ¿Cuándo? Pues bien, cuando el cliente solicita un pequeño
cambio y el equipo de desarrollo tarda meses en implementarlo
finalmente.
§ Es entonces cuando un incidente interno puede volverse
externo. Esto podría deberse a una mala calidad del código, un mal
diseño del sistema, un alto acoplamiento y baja cohesión, una mala
arquitectura, un código que no es fácil de leer ni entender, etc. Estas
cosas dificultan mucho la realización de cambios, lo que afecta
negativamente la experiencia del cliente.