archivo

Archivos diarios: octubre 21, 2011

Es un concepto sobre el que hay muchísima bibliografía y en cierto modo es algo curioso, ya que el negative testing es el proceso de buscar incidencias en el artefacto que se verifica o se valida, es decir, la diferencia con el testing ordinario es que este encuentra los errores mediante la comprobación de si un artefacto cumple las expectativas, si tomamos por ejemplo en el propio producto software, el testing ordinario se centraría en validar si se cumplen o no los requisitos funcionales y no funcionales y las incidencias se encontrarían mediante ese proceso.

El negative testing busca errores y no se centra (por lo menos no es su objetivo principal) en comprobar si el producto funciona.

¿Dónde podemos aplicar negative testing? En muchas áreas, por ejemplo, cuando se detecta una incidencia en una funcionalidad o módulo del sistema que sospechamos que se puede extender a otros, cuando hacemos testing exploratorio, etc…

Anuncios

Otro de los grandes problemas que tenemos los desarrolladores de software es que consideramos que la forma en que hacemos las cosas es la mejor y que es el entorno, el cliente, el proveedor o cualquier otro agente externo el que impide, tal vez, que trabajemos de otra manera. Eso lo pensamos incluso cuando hemos empezado en esto y nos acompaña, pese a que nos damos cuenta de que siempre es posible mejorar, a lo largo de nuestra carrera profesional.

No son muchos los años, en comparación con otras ingenierías, los que se lleva desarrollando software, gestionando servicios TIC, etc…, pero sí los suficientes para que se hayan detectado (y estén en mejora continua) una serie de buenas prácticas. No todas valen en todos los contextos, eso es importante tenerlo en cuenta, pero sí que resulta de interés conocerlas y aplicarlas cuando es conveniente.

No tener en cuenta las buenas prácticas es como querer ir a ciegas en este mundillo y no tener en cuenta la experiencia de otros que probablemente se hayan enfrentado a problemas parecidos a los nuestros.

Siempre digo que cada proyecto es un mundo diferente, pero eso no quiere decir que no tenga elementos comunes con otros y que se puede aprovechar estrategias, técnicas y prácticas que han funcionado para otras personas, en otros trabajos.