Acerca de… El Tester

  • RSS
  • Add To My MSN
  • Add To Windows Live
  • Add To My Yahoo
  • Add To Google

Statistics

  • Entries (17)
  • Comments (38)
Posted by Cristian Aroca Sunday, September 11, 2011 3:28:00 PM Categories: Calidad de Software
Rate this Content 7 Votes

A lo largo de estos últimos años se ha visto más evidente la necesidad de incluir a equipos que se dediquen a hacer la validación de productos de software, los que comúnmente conocemos como “testers”, de igual forma se ha podido relacionar el grado de éxito de un proyecto con el software testing.

Me gustaría hablar un poco de las personas que se dedican a realizar la actividad de pruebas y debo empezar por algo que me parece un poco injusto,  en el mundo del desarrollo o en el mundo del software (como lo prefieran llamar) ser tester es considerado a veces como un trabajo insignificante, en el recorrido de mi experiencia académica y laboral he escuchado varias veces decir frases como: “el tester es un programador frustrado”  o “el tester es el ingeniero que no pegó en nada” comentaré a continuación algunas de las características que tienen (o deben tener) las personas que se dedican a esta actividad. Y espero con esto cambiar un poco ese pensamiento

Como habilidad principal, debe ser una persona con gran capacidad de análisis su trabajo no es sólo probar que el software funciona, además es hallar errores o defectos en el software, también debe involucrarse con el negocio y de esta forma hallar ambigüedades o contradicciones en las reglas de negocios, generando posibles escenarios en los que pudiera ser funcional el producto de software y en los que pudiera fallar. En ocasiones es posible que analice fragmentos de códigos para dar una justificación o poder sugerir solución (en el caso que se le permita) y en este sentido deberá estar en la capacidad de entender el lenguaje de programación y más aún, entender la lógica de la persona que lo desarrolló (algo que no es sencillo).

En contraste con lo anterior y siendo una característica común en las personas que les gusta el tema de tecnología, deben tener “hambre” por el conocimiento, tener un sentido de la curiosidad y un poco de creatividad.

También debe ser una persona que tenga habilidades de comunicación, recordemos que los “testers” están enfrentados tanto a diálogos con arquitectos, desarrolladores, programadores, DBA’s, etc. como a líderes de proyectos funcionales o técnicos, gerentes de proyectos y (seguramente) hasta usuarios finales (en los casos en que guíen o apoyen las pruebas de aceptación de usuario UAT). Al estar relacionados con varios roles dentro de un proyecto debo decir que el ser objetivo es algo que cuenta mucho, también se ha visto que en los proyectos se arman “bandos” algunos que están en pro de algo y otros en contra, unos defienden y otros atacan (no sé las razones pero es algo inevitable) en este caso, la objetividad es nuestra arma.

Cada proyecto trabajado por un tester es un proyecto del cual aprende temas o técnicas que pueden ser usadas en proyectos futuros. El tester debe ser capaz de ser humilde (en lo que sabe) y no tomar estos conocimientos como los únicos y absolutos, recordemos que cada proyecto es diferente y es debido a esto que no podemos abordar los temas de la misma forma que lo hemos hecho anteriormente. 

En este punto debo confesar que soy un amante a la planeación y personalmente creo que es importante que se tenga la habilidad de planear las actividades que se van a realizar, así como las herramientas que se van a utilizar y en lo posible las características de los casos de pruebas que se tomarán en cuenta. Normalmente debemos definir cuales serán nuestros criterios de aceptación o rechazo del producto (con ayuda del que esté liderando el proyecto) el alcance que se tendrá, módulos o ítems a cubrir en las pruebas y el tiempo estimado en que se realizará. Esto nos ayuda para ir realizando análisis de los casos cubiertos, ir monitoreando las acciones y realizando una retroalimentación al equipo y también para tomar decisiones en las actividades futuras, debemos ser consiente que el plan no es estático y puede cambiar en el transcurso del proyecto.

Así como me gusta mucho la planeación también me gusta crear casos de pruebas derivados de los resultado que obtengo ejecutando algún otro o crear casos  basado en sospechas que pueda tener en algún punto del producto analizado. Tal vez esto que esté diciendo pueda estar en contra a lo que dije anteriormente pero considero que ser tester no es solo ejecutar un caso y comparar el resultado con algún resultado esperado, debemos ir más allá y debemos saber equilibrar qué tantos casos podemos crear derivados de otros para que no afecte en gran medida nuestro tiempo estimado y pueda generar desfases grandes en el proyecto.

Por último me gustaría comentar varias cosas en calidad de consejos:

Consejo 1: Preguntarse siempre “que tal si…”  lo escuché en una conferencia hace poco relacionada con temas de emprendimiento, pero creo que aplica completamente en esta actividad y ayudará mucho a las personas que están empezando con el tema, no recuerdo quien la dijo (Perdón por no citar) si alguien la ha escuchado, espero que me ayude con la cita 

Consejo 2: Eliminar la frase “esto está malo” o reducirla al máximo, esta frase genera confrontaciones entre personas y se crea un mal clima. Ser más diplomático en ese sentido ayudará a conservar las relaciones y la colaboración entre los integrantes

Consejo 3: No se debería justificar un fallo sólo porque se piensa que lo es (pecamos mucho en este aspecto), si se identifica un fallo es porque somos capaces de justificar que no está de acuerdo con un requisito, regla de negocio o ley y por ende degrada la calidad que percibe el cliente.

Consejo 4: El tester no es el responsable de la calidad, él no la crea ni la quita, sólo la evidencia. La calidad viene de la personas que desarrollan el producto y debemos trabajar junto a ellos  (no en contra) para poder sacar como resultado un producto de calidad para el cliente, recordemos que somos un equipo y no estamos jugando unos contra otros.

Trataré de recomendar algún contenido sobre el tema cada vez que escriba, por ahora recomendaré un libro. Fue el que me recomendaron cuando quería involucrarme en esta actividad.

Lesson Learned in Software Testing (Cem Kaner, James Bach, Bret Pettichord)

Imagen tomada de: http://www.competence.co.in/Certifications.html

Comments

Sunday, September 11, 2011 5:34:57 PM

re: Acerca de… El Tester

Me gusta mucho tu post, evidentemente, como lo dices "debería ser", lastimosamente creo que no todas las criticas alrededor de los tester se basan en un parecer, tipicamente al menos en esta ciudad, sucede que las personas que en la universidad no resultaron ser buenos para programar, resultan en compañias de pruebas de software. Ahora, no se trata de mirarlos, como "los malos" que nunca aprendieron a programar, se trata de entender que además de gustos hay personas que tienen diferentes habilidades, y que si bien ellos pudieron no ser buenos para lo abstracto de programar, quizá encontraron su rol en ser tester, un rol que por cierto no enseñan en los programas de pre-grado.

Como todo es cuestión de no verlo bajo ninguna óptica cerrada, y espero que no solo los programadores y demás roles se cuestionen sobre sus criticas a los tester, también que los mismos testers se cuestionen sobre si tienene habilidades para ejercer este tipo de roles.

 

Sunday, September 11, 2011 9:10:50 PM
Hernan Guzman
View User Profile for Hernan Guzman

re: Acerca de… El Tester

Muy interesante el artículo y la temática!... aquí algunos apuntes mios sobre el tema:
  • Un tester SI es responsable de la calidad, lo que pasa es que no es él solo. La calidad debe ser compromiso de todo el equipo de un proyecto, incluyendo el cliente.
  • El tester debe aprender a entenderse tanto con su equipo de proyecto, como con el cliente, para así poder entender lo que él quiere. Esto es importante a mi modo de ver.
  • Si bien estamos de acuerdo que se debe tener una planificación de las pruebas, en mis clases del tema con @betancur aprendí que "tiempo que se pase documentando es tiempo que no se pasa probando", por lo que debe haber un equilibrio en esto, y el tester debe ser proactivo como para explorar más allá de lo que dice su plan de pruebas.
Sunday, September 11, 2011 11:08:43 PM

re: Acerca de… El Tester

Comparto una 100% lo que dice hernan que el tester si es responsable de la calidad al igual que el esto del equipo sino fuera así, entonces pa que un tester??? y por que se llama Calidad al area de los testers???  la verdad no entiendo eso.

y lo que el tester no es valorado me imagino que depende de la empresa yo trabaje en un adonde le pagan a los tester 3 veces mas que al desarrollador y eran mas valorados 

 

Sunday, September 11, 2011 11:08:43 PM

re: Acerca de… El Tester

Comparto una 100% lo que dice hernan que el tester si es responsable de la calidad al igual que el esto del equipo sino fuera así, entonces pa que un tester??? y por que se llama Calidad al area de los testers???  la verdad no entiendo eso.

y lo que el tester no es valorado me imagino que depende de la empresa yo trabaje en un adonde le pagan a los tester 3 veces mas que al desarrollador y eran mas valorados