Proposito del nuevo año, aprender a programar!

On 3 enero, 2012, in Cursos, by twiindan

Como ya he comentado en algún articulo anterior, uno de los puntos que valoro generalmente en los testers son los conocimientos de programación. Siempre he sido defensor de que nuestra disciplina, es una disciplina no solo funcional si no también técnica por lo que valoro que estas personas tengan una base de programación.

Como ya comenté en el articulo “Han de saber programar los testers“, no es necesario que tengan unos conocimientos profundos sobre programación, pero si que tengan unos mínimos que le permitan leer código o analizar arquitecturas, al igual que realizar scripting o Bases de Datos.

Es por ese motivo, que hoy me gustaría compartir con vosotros una muy buena iniciativa que he encontrado y que podéis seguir de forma gratuita.

La iniciativa tiene el nombre de “Code Year” y consiste en un pequeño curso de programación online en el que nos podemos suscribir para que nos manden de forma semanal nuevas lecciones para poder aprender a programar desde el principio y poder así mejorar nuestras skills de programación.

El curso es totalmente gratuito, y el único dato necesario para el registro es la dirección de correo electrónico donde te mandaran posteriormente las lecciones y los ejercicios.

De momento ya hay más de 60.000 personas registradas, por lo que la iniciativa parece ser que ha tenido bastante éxito. Si aun no has realizado los propósitos para este año 2012, puede que esta iniciativa pueda ayudarte a definir uno de ellos!

Tagged with:  

Durante mi presentación en Valencia, expuse en una slide que era importante que los testers tuvieran programing o coding skills. Esta frase provoco una serie de murmuros, y note que decenas de ojos empezaban descuartizarme en su cabeza…

Efectivamente en cuanto acabe la presentación, todas las preguntas fueron hacia esa slide, ya que la mayoría de gente no estaba de acuerdo en que realmente un tester deba saber de programación. La pregunta abierta a debate es… Realmente un tester debe saber de programación? Porque existe tanto miedo a aprender a programar?

Aquí expongo mi opinión, pero no es más que eso, una opinión al respecto y por supuesto puede diferir de la de mucha gente:


PROGRAMAR O NO PROGRAMAR, ESA ES LA CUESTIÓN:

Parece ser que existe una gran reticencia de mucha gente que se dedica a la calidad de software y al testing (sobretodo estos últimos) a no tener que saber nada sobre programación. Esto en parte se debe a dos motivos (entre otros muchos): El primero de ellos es que mucha gente se ha dedicado al software testing por casualidad, y es gente reciclada de otros trabajos como soporte, o gente de la capa de negocio o más funcional. El segundo motivo es que otro gran porcentaje de testers son gente que se metieron en este sector porque justamente no querían programar y les pareció una alternativa sencilla para seguir dentro de las IT sin tener que saber programar.

Pero realmente sirve para algo saber de programación para ser tester?

 

Testing triangle

A mi siempre me ha gustado mostrar una pequeña figura como la siguiente donde localizo el testing entre dos mundos que casi están separados, la capa de negocio y la parte de desarrollo o parte técnica.

Para mi el tester ha de ser comunicador entre ambas partes (junto otros roles implicados en el desarrollo), ya que entre ellas la comunicación puede llegar a ser muy complicada.

Como podéis observar el tester toca tanto la parte de negocio como de desarrollo. Todo el mundo tiene muy claro que el tester ha de saber sobre la capa de negocio para hacer bien su trabajo, sin embargo poca gente tiene en cuenta que también es importante el trabajo con los programadores. Por lo tanto para mi un tester ha de tener parte de negocio, parte técnico y añadirle otras skills intermediaria.

Entonces, para que le puede servir programar a un tester? Principalmente por varios motivos:

  1. Para entender los problemas que puede tener una aplicación. Desde la capa de negocio se pueden encontrar muchos defectos, pero si realmente sabemos como esta construido el software, si sabemos como esta diseñado y creamos un modelo mental de este, sabremos como toma las decisiones, de donde obtiene los recursos, que partes del código son más susceptibles de tener más errores.  Obtenemos una gran fuente de información para mejorar en la realización de las pruebas!
  2. Automatización! Si lo se… existen maravillosas herramientas que haciendo clicks puedes automatizar… pero lo que realmente aporta valor es atacar sobre la lógica de la aplicación (a nivel funcional). Que seamos capaces de automatizar una API sin interfaz gráfica, capaces de regenerar datos mediante scripts, crear scripts para configurar la aplicación…
  3. La más importante para mi… para comunicarse con los programadores… aprendemos la capa de negocio para hablar con los clientes, para discutir con ellos, para proponerles cosas, informes etc. Sin embargo no somos capaces de comunicarnos con la gente técnica porque no hablamos su idioma… como queremos entonces que nos respeten??? Si queremos captar su atención tenemos que saber ayudarles, darles apoyo, hablar con ellos, mejorar su día a día, y esto solo lo podemos conseguir si sabemos como trabajan.

Gente que se dedica al testing y al QA, debemos recordar una cosa… nuestra disciplina se encuentra dentro de la Ingeniería de Software! Si queremos sacar todo el potencial de nuestra profesión tenemos que trabajar desde su base.

Con esto no quiero decir que tengas que tener un nivel de programación excelente, ni mucho menos, si yo soy tester y el de mi lado es programador es principalmente por dos motivos… el primero porque el trabaja 8 horas programando y yo no. El segundo es porque a el le motiva programar, a mi probar y hacer de QA. Pero si que es necesario que si me enseña un diagrama UML lo entienda, que si me muestra una arquitectura, podamos discutirla, que si me da un trozo de código (bien programado) pueda decirle que hace y proponer seguramente alguna mejora y si no lo entiendo pedirle que me lo explique. De esta forma, la otra persona ve que aporto valor a su trabajo, que realmente puedo serle de utilidad, en lugar de ser alguien que lo único que le dice es que ha hecho algo mal. A partir de ese momento, me podré integrar mejor con ellos e intentar internamente que mejoren la calidad de su código ayudandoles a hacerlo y ofrenciendoles todo el soporte necesario para ello ya que el objetivo de ambos es el mismo.

Esta condenado el tester funcional a desaparecer?

A mi parecer no. Hay una gran herencia en los últimos años, aunque creo que con la entrada del agilismo esta tendencia esta cambiando. Igualmente existe una gran cantidad de testers que son muy buenos realizando su trabajo, gracias al knowhow que tienen de la capa de negocio, y gracias a que se ha ido autoformando dentro del mundo del tester teniendo un gran background de heurisiticas que puede utilizar.

Conozco grandes testers exploratorios, y de testing manual, mucho mejor que algunos que sepan programar, gente a la que admiro, pero también creo que aprender un poco de programación no les hará daño. Insisto, ambas formaciones no son contradictorias, sino al contrario, son complementarias y nos ayudaran a realizar mejor nuestra profesión.

Al final nuestro objetivo es el mismo que el resto del equipo, entregar un software de calidad a nuestro cliente, por lo que hemos de aportar un valor diferencial respecto a nuestros clientes, y respecto a los programadores, ese es el status quo del tester.

Ahora ya podéis uniros al grupo de facebook de “quiero despellejar al que dice que los testers necesitan programar!”

Tagged with:  

Resumen VLC Testing 2011

On 14 noviembre, 2011, in Conferencias, Eventos, by twiindan

Resumen VLC Testing 2011El día 10 de Noviembre tuvo lugar la jornada de calidad de software y testing VLC Testing 2011 en la ciudad de Valencia. La universidad de Valencia junto con el ITI ha querido recuperar estas jornadas despues de varias años sin realizarlas y la verdad que fueron todo un éxito.

Al final 120 asistentes pudieron asistir a las jornadas donde solo había un único tema entre los asistentes, el testing!

La jornada empezó con la presentación del director del Area de calidad del software del ITI (si, existe un area de calidad de software dentro de una universidad!) realizando una ponencia introductorio bastante divertida utilizando un juego de palabras sobre el testing (probado, reprobado, re-probado). Posteriormente Dario Ferrater hizo una ponencia sobre la experiencia del testing en los juegos olimpicos (Atos lo está realizando). A mi parecer una ponencia muy comercial, y que se tendría que haber enfocado más en el caso práctico de los JJOO ya que parecían muy interesantes.

Seguidamente tuve la ocasión de presentar mi ponencia sobre “skills” del tester, que podéis descargar en la sección de “Conferencias y articulos” y dar el feedback que queráis! Después vino mi compañero Javier Fernandez Pello que realizó también una gran ponencia sobre como tienen montado todo el departamento de QA dentro de su empresa, y explico todos los procesos que realizaban desde QA para intentar mejorar el proceso día a día. A mi parecer una gran ponencia que dió un toque diferencial a las conferencias ya que es un tema del que generalmente se habla poco.

Después de otra ponencia de caracter muy publicitaria a mi parecer de Jorge Castelló de Bull, llego otra gran ponencia de manos de Antonio Calero sobre métricas de software, donde explicaba las principales métricas que utilizaban con casos prácticos de análisis y números que dejaban mucho que desear sobre el software que se está produciendo actualmente.

Por la tarde destacar también la ponencia Maite Tamayo sobre un sistema metrológico, ya que mostraba que existían muchas complicaciones a la hora de testear software embedido y mostraba la solución que habían adaptado para solucionarlos. Posteriormente Jordi Sanchez hizo una ponencia sobre uno de los grandes “olvidados” en el software, la usabilidad.

Ya para acabar la jornada pudimos ver una presentación sobre sistemas críticos (que recuerdos!) y otra sobre testing combinatorio mostrando algunas herramientas que pueden ser de gran utilidad a la hora de realizar Data Driven Testing.

En general las jornadas han sido muy interesantes, y hubo variedad de ponencias, muchas de ellás con muchas cosas para aprender. Lo malo de las conferencias? Hubo alguna de ellas puramente comercial (como la de Atos o Bull) y por otra parte los tiempos eran excesivamente ajustados (11 conferencias en un día son muchas conferencias). Aún así el balance de las conferencias ha sido muy positivo. La organización cumplió con creces mis expectativas y hubo conferencias con mucha calidad por parte de los ponentes por lo recomiendo el próximo año asistir sin ninguna duda!

Felicidades a la organización por retomar este evento que ayudará a difundir la calidad del software y el testing por nuestro país!

Tagged with:  

Infested testers

On 15 febrero, 2011, in Consejos, skills, by twiindan

Ayer llego a mis manos un muy buen post en el blog del CES acerca de como contratar un tester. En el blog, se indicaban ciertos consejos a tener en cuenta cuando se esta en un proceso de selección de testers para la nueva plantilla.

Hay un punto en especial que me gustaría destacar del articulo que me llamo mucho la atención y es lo de contratar gente “infectada” según el articulo “The Art of Recruiting” de Apple Guy Kawasaki . Este termino de “infectada” se refiere especificamente a la pasión.

La problematica principal es, como podemos medir la pasión por su profesión de un candidato? No es una facil respuesta pero algunas de las cosas que se pueden medir son:

  • Que el candidato tenga un blog sobre testing donde exponga sus problematicas, los temas que va aprendidendo, sus casos reales, sus inquietudes… Algo que he aprendido a medida que he ido realizando este blog, es que he aprendido mucho más explicando algunas cosas, que cuando las he leido, ya que el poder hablar de ello ha incrementado mi retención de conocimiento.
  • Que haya leido libros. En un mundo profesional donde practicamente no existen cursos, o programas educativos especificos del testing, es muy importante aprender de los libros de los expertos ya que son una fuente de conocimiento para un aprendizaje continuo.
  • Persona activa en la comunidad del testing. Es muy importante ver si la persona ha participado en comunidades como Software Testing Club , foros, blogs, twitter y ha expuesto sus dudas y debatido sus puntos de vista.
  • Participar en eventos online como WeekendTesting o en algún concurso de testing como los Bugbattles de utest. También se puede valorar que haya participado como tester en algúna aplicación OpenSource.
  • Haber realizado algún articulo o conferencia en algún evento o revista especializada en Testing.
  • Pertenecer a alguna organización sobre testing.
  • Que haya realizado algún proyecto personal sobre testing fuera de su ámbito laboral.

Esto son solo algunos ejemplos de como podemos medir la pasión de un posible candidato cuando estamos en medio de un proceso de selección de testing. Como podéis ver la mayoria de puntos requieren que las personas realicen trabajo fuera de su tiempo laboral aunque no es necesario en otros muchos.

Tenéis realmente pasión por vuestra profesión? Conocéis algún método más para evaluar la pasión sobre el testing?

Tagged with: