Decálogo de un Tester – 10 normas básicas que todo Tester debería seguir

El arte de probar software requiere de ciertas habilidades y metodologías necesarias para asegurar de manera confiable la calidad del software. Este decálogo define, de manera general, las 10 normas básicas que todo probador de software debería tener en mente

1. Escepticismo

Nunca piense que los desarrolladores entregan un software que probablemente funcione bien. Muchas veces te dices a ti mismo… han tenido tiempo, no es un desarrollo complicado, se trata de gente con experiencia… seguro que esta entrega funciona bien y tiene pocos fallos… Error! así no se tiene la mente preparada para encontrar fallos…  siempre tienes que pensar que el código está lleno de defectos y luchar por encontrarlos… Otra lectura de esta premisa es que cuando se encuentre un comportamiento raro, por insignificante que sea, nunca se debe de pensar… bueno, será por cosas de entorno, será algún compañero que ha tocado algo… siempre, detrás de estas pequeñas cosas puede estar ese error que finalmente sale en producción y pone la cara colorada del que lo dejó pasar.

2. Priorizar las pruebas

Lo ideal sería que a la hora de escribir las pruebas se marcara de alguna manera la prioridad. Si esto no es así, es muy importante que a la hora de la ejecución se aplique la inteligencia necesaria para identificar los escenarios o casos de uso más importantes o los más sensibles. Para cumplir este punto lo mejor es preparar una buena colección de smoke tests, y luego categorizar el resto de pruebas en Critical, Medium y Low.

3. Nunca prometer el 100% de cobertura

Por definición, llegar al 100% de cobertura es imposible, o muy difícil… por lo tanto si alguien pregunta (incluido clientes) nunca asegurar una cobertura del 100%, porque estarás siendo demasiado optimista.

4. Pensar desde la perspectiva de los usuarios

Al final cada producto software está destinado a un tipo de usuario determinado, de una edad concreta, de un segmento determinado, etc… pues el buen tester siempre se intenta poner en la piel del usuario final e intenta empatizar con él y con sus necesidades por muy lejos que estén de las suyas propias. Haciendo esto las pruebas pueden tomar un planteamiento totalmente diferente.

5. Comenzar cuanto antes a probar

Cómo ya hemos repetido alguna vez se debería empezar a probar desde bien temprano en el proyecto, justo desde el momento en el que los requisitos están definidos. Cuanto antes se empiece a analizar los requisitos, la estrategia de pruebas, el análisis, preparar los planes de pruebas, empezar la ejecución, etc, pues mucho mejor para el proyecto… ya que cuanto antes se empiecen a encontrar fallos y cosas que no cuadran mucho mejor. Cuanto antes se encuentre un fallo, tendrá menos impacto económico en el proyecto.

6. Desarrollar la capacidad de análisis

El trabajo de un tester no sólo debería quedarse en encontrar un fallo, también si hay tiempo y el proyecto lo permite lo ideal sería llegar al fondo del problema, encontrar la causa y las posibles soluciones. Para esto es esencial una capacidad de análisis muy alta. No solo se trata de encontrar un defecto, hay que descubrir la manera en la que se intento implementar algo para entender completamente el fallo.

7. Reportar errores eficientemente

Una de las tareas más delicadas dentro del trabajo de un tester es reportar los errores. Lo más importante a la hora de reportar un error es describirlo adecuadamente y transmitir su importancia e impacto. Un tema complicado a la hora de reportar errores es la comunicación con el equipo de desarrollo. En teoría parece fácil; encuentras un error, lo reportas, lo arreglan y solucionado. Pero en ocasiones no es tan fácil, te puedes encontrar, por parte de desarrollo, una actitud cerrada a aceptar fallos y te pueden intentar convencer que realmente no es problema de su código, que viene del entorno, de tus herramientas de testing, etc… Para esto, lo más importante es tener siempre paciencia infinita e intentar transmitir de la mejor manera posible el error para no dejar lugar a dudas.

8. Datos de Prueba Reales

En la medida de lo posible probar siempre con datos y maquetas lo más parecidos al entorno de producción. De nada vale hacer cientos de pruebas con datos irreales si al final, cuando el producto vaya a campo, se va a enfrentar a circunstancias completamente diferentes.

9. Nunca fiarse de la política de tierra quemada

Siempre, antes de dar por finalizada la fase de testing y entregar a cliente es aconsejable realizar unos smoke tests que garanticen que lo mínimo de la funcionalidad se cumple. En un proyecto de pruebas donde hay varios ciclos, si en el primer ciclo se prueba un módulo y no está planificado volver a probarlo… Es muy recomendable, antes de entregar, hacer una mínima prueba de la funcionalidad básica. No vaya a ser que en el resto de ciclos se haya estropeado algo.

10. No dejarse llevar por la pereza

Muchas veces se tienen sospechas de que algo pasa, y te das cuenta que la única manera de llegar al fondo del asunto es hacer ciertas pruebas que ves que te van a llevar más de lo que te gustaría o pudieras dedicarle. Ante estas situaciones nunca hay que dejarse llevar por la pereza y dejar de hacer esas comprobaciones, lo importante es que tú o alguno de tus compañeros, si tu no puedes, las realice. O incluso si por motivos en el proyecto no es posible realizar estas pruebas una solución podría ser hablarlo con los responsables del proyecto y analizar si conviene declarar, en la entrega del producto, el riesgo de no haber probado ciertos escenarios por falta de tiempo o de recursos. Espero que este listado de cosas a tener en cuenta cuando te dedicas a probar software te sea útil y te ayude a que no se te escape nada.

 

Fuente: Tester House (link al articulo original: https://testerhouse.com/decalogo-de-un-tester/)

Leave A Comment

At vero eos et accusamus et iusto odio digni goikussimos ducimus qui to bonfo blanditiis praese. Ntium voluum deleniti atque.

Melbourne, Australia
(Sat - Thursday)
(10am - 05 pm)
X