Así como convivimos con personas y procesos, también convivimos con errores del software que debemos testear: identificados y no informados, identificados y asignados para corregir, identificados y en proceso de corrección, identificados y corregidos, identificados y en proceso de ser testeados, identificados y testeándose, identificados y testeados OK, identificados y testeados KO, y por supuesto aquellos que aún no han sido identificados y están «latentes» a la ocurrencia de un evento en particular dentro del proceso de negocios.
Nos deberíamos detener por un instante, en evaluar los errores que nosotros como Testers cometemos también, ¿no te parece?
Qué podemos hacer frente a este panorama?
Enriquecernos de ellos y mejorar nuestra actividad, a mi modo de ver.
Claro está que muchos entienden a un error desde un punto de vista distinto al que puede llegar a tener un Tester, ¿qué esta bien y qué esta mal? te lo dejo a tu criterio.
Indudablemente ésto tiene que ver con la parte humana, y por ende, tiene que ver con una equivocación que ha cometido una persona, algo que se ha olvidado o dejado pasar, o algo que no quiso hacer en muchos casos.
Todas estas situaciones dan lugar a que haya seguimiento y control de muchas formas, para ir monitoreando el grado de avance en las actividades.
Claro que siempre se «cuelan» errores y pasan por convertirse en defectos y luego en fallos (con clara presencia en el ambiente productivo).
Hay personas que aún consideran que esta mal que aparezcan errores y ni que hablar, que se haga público. Por supuesto que gran parte de este tipo de personas, invierte parte de su tiempo en buscar a la persona que originó el error en vez de enfocarse en el problema en si mismo y atacarlo.
Nosotros los Testers, debemos «ver» todos estos temas e identificar/tratar la mayor parte de los errores antes enumerados, ya que son una parte fundamental de nuestra actividad.
Ahora bien, y hecha esta introducción, «Podemos aprender de los errores»?
En mi opinión te diría que sí, que hay muchos aspectos que podemos rescatar de ellos y que nos sirvan de lecciones para después aplicar en los proyectos que tengamos.
Todos los miembros del equipo nos pueden ayudar, desde los programadores, analistas, y los otros miembros técnicos, hasta el usuario final mismo, a través del cual podemos aprender mucho.
No hay que «cerrarse» a nada, yo creo y hay que «ser de mente abierta».
«Bienvenidos sean los errores», en algún lado lo leí. El tema está después en gestionarlos y aprender a sacar el mayor provecho de los mismos para nuestro testing.
Respecto de los errores que nosotros como Testers también cometemos.
1. No asumir
2. Nunca olvidar de ver el panorama general
3. No ceder
4. No ignorar la intuición
5. No preocuparse por los errores que se cometan
1. No asumir
Si bien parece claro el concepto, no lo es para muchos.
La idea que nos debe dar este concepto es que no debemos asumir nada de lo que nos digan hasta tanto hayamos considerado todos los aspectos que a nuestro criterio merecen ser tenido en cuenta. Muchas veces uno debe aprender de cero una aplicación, para lo cual comienza toda una serie de investigaciones, reuniones, y encuestas que nos originan muchas dudas y consultas, y que debemos necesariamente, buscar una respuesta.
2. Nunca olvidar de ver el panorama general/completo
Para tener un concepto claro de entrada, te puedo decir que nunca olvides de tener el punto de vista del usuario final, además del punto de vista técnico si puedes, y nó a la inversar.
Al «usuario final» no le interesa cuánta cobertura has podido probar utilizando las diversas técnicas de «caja blanca», lo único que le importa es que las páginas a las que accede a diario no se cuelguen, funcionen en el tiempo y en la forma correspondiente, que los campos desplegables funcionen bien y muestren los respectivos datos, que pueda enviar a imprimir lo que necesita y nó lo que quiere la aplicación, que pueda navegar y trabajar/estudiar sin ningún inconveniente. ¿O acaso no somos también usuarios de muchas aplicaciones y también exigimos lo mismo?
3. No ceder
Este punto tiene que ver con los errores que se van identificando y los riesgos inherentes a los mismos, su severidad y criticidad. En este punto es muy importante que por lo menos informes toda esta data lo más pronto posible y de la mejor forma como para que quienes tienen la responsabilidad de tomar decisiones, lo puedan hacer lo más pronto posible y de la mejor forma, contando con elementos que lo ayuden a ello.
4. No ignorar la intuición
Intuición, Experiencia, conocimiento desde la práctica misma, años de recorrer proyectos, es un poco un todo de lo mismo. Lo importante aquí es «escuchar» nuestra intuición de Testers, y saber el camino por el cual nos tenemos que conducir.
5. No preocuparse por los errores que se cometan
Hay un refrán que dice: «el que trabaja, se equivoca»!, en realidad apunta a que los errores se cometen cuando uno realmente trabaja por una cuestión lógica, caso contrario, no se presentan.
Y claro está que cometeremos errores en cada uno de los proyectos en los que estemos a cargo o asignados, ya que es una cuestión de lógica. El tema estará en aprender de ellos e intentar no cometerlos repetidas veces. Este punto va de la mano del anterior ya que a partir de la experiencia que uno vaya adquiriendo, irá mejorando su «intuición» en la actividad.
También deberíamos pensar en que muchos de esos errores son parte de nuestros hábitos de trabajo/estudio, y que sobre varios de ellos por ser triviales, no queremos perder el tiempo en corregirlos.
¿Acaso no te ha pasado de recibir los mismos errores por parte del Desarrollador? somos seres humanos al fin y al cabo.
No me estoy refiriendo únicamente a los errores de ortografía que pueden ser resueltos mediante varias herramientas a las que tenemos acceso, sino a errores de procedimientos y que forman parte de un workflow que debemos seguir a diario.
Hasta aquí, como podrán notar, no hice ningún comentario acerca de la manera de registrar los «errores» en la herramienta que estemos utilizando, ni mencioné al JIRA, Bstriker, Zephyr, Kanoah Test, Practitest, Testlink, qTest, TestLodge, Redmine, Bugzilla, y tantos otros que muchos de nosotros ha usado y/o utiliza a diario, y que tienen la posibilidad de que otros lo sigan al ser colaborativo.
¿El tema de estar manejando un proyecto en otro idioma provoca la ocurrencia de mayor cantidad de errores? ¿Qué piensas al respecto?
Lo que sí, en cada una de estas situaciones el factor «comunicacional» y «actitudinal» tiene un papel muy importante para ir enfrentándose y resolviendo cada uno de los errores que se nos vayan presentando.
.
Fuentes de inspiración
Errors: bugs, boo-boos and blunders
https://s3.amazonaws.com/titlepages.leanpub.com/errors/hero?1455684749
5 Mistakes not to make as a Software Tester
https://www.linkedin.com/pulse/20140709122703-258688987-5-mistakes-not-to-make-as-a-software-tester
Why learning from mistakes is (sometimes) so hard
http://www.softwaretestingclub.com/profiles/blogs/why-learning-from-mistakes-is
