De testers y code reviews

Hola, me llamo Mauri y yo también he ignorado las revisiones de código con la excusa de que son “terreno de los desarrolladores”.

¡Pero ya no! Desde que trabajo en Atlassian que me he dado cuenta que, para que la calidad escale con el desarrollo, hay que invertir esfuerzos en la prevención por delante del control o la mitigación, y un buen lugar para prevenir son las revisiones de código, que acostumbran a ocurrir antes de cualquier testing hands-on.

STASH13_PRactivity

Y no quiero oir a nadie diciendo cosas del estilo “pero yo no soy desarrollador” o “es que no sé leer código”, porque no hace falta ser un developercon213añosdeexperiencia para mirarse una revisión de código. Además, leer código es más fácil de lo que aparenta, y las revisiones de código son un buen lugar por donde empezar, ya que los cambios estan asociados a una funcionalidad o bugfix, de tal manera que el código se puede vincular fácilmente a su objetivo.

Listado de 5 cosas al azar que te interesan, como tester, de las revisión de código:

  1. Mayor conocimiento de los sistemas y aplicaciones: como tester más funcional, seguro que ya te conoces todos los recovecos de la interfaz de usuario, ¿por qué no ampliar ese conocimiento con nociones del funcionamiento de la cara interna de las aplicaciones?
  2. Inspiración para futuras fases de pruebas: dependencias inesperadas, secciones complejas, condicionales gigantes, dudas sin resolver expresadas en los comentarios… Este tipo de cosas son pistas invaluables para exprimir las aplicaciones durante la fase de pruebas. Este conocimiento, bien usado y con práctica, hace que el testing sea como jugar al Trivial Pursuit consultando la Wikipedia.
  3. Mejores tests automáticos: el input de un tester en las pruebas automatizadas que vengan con el código (tests unitários, de integración o de lo que sea) puede ser muy útil para que las nuevas funcionalidades nazcan con una cobertura exhaustiva e útil, más allá de los happy paths.
  4. Se cazan bugs también! Que sí, que sí, que se puede! Y no solo bugs, también comentarios confusos, errores de formato, secciones poco claras, tests unitarios que no testean nada… Las revisiones de código son el momento idóneo para corregir este tipo de problemas.
  5. Respeto: también puedes ganarte (más) el respeto de los desarrolladores con tu participación e interés en las revisiones de código, gracias a tus consejos y aportaciones en las mismas. Sabrás que estás por el buen camino cuando tu input sea solicitado en ellas o (todavía mejor) cuando algún desarrollador te pida consejo sobre qué casos de prueba automatizar ¡en la fase de codificación!

Estas son las mías, pero hay muchas más razones por las que, como tester, puede ser interesante participar en las revisiones de código. ¿Cuáles son las tuyas? ¡Cuéntamelo en los comentarios!

Anuncios

Qué haces tú para llevar el testing a la universidad?

La calidad, el testing, el Quality Assurance… nuestro campo está profundamente infra-representado en lo que se refiere a la educación reglada española. En parte porque nosotros, los profesionales del sector, dejamos que así sea y no hacemos la presión suficiente para cambiar esta situación que no hace más que entorpecer nuestra tarea: complica el reconocimiento profesional, ofusca el mercado laboral, dificulta el encontrar perfiles jóvenes con formación específica, etc.

Es muy fácil quejarse, muy fácil. Mucho más fácil que hacer algo al respecto, pero si todos aportamos nuestro granito de arena estaremos mejor que si no hacemos nada, con nosotros mismos para empezar, y tal vez demos un paso decisivo en la dirección de conseguir que la educación universitaria contemple el testing como una profesión en si misma.

Mi granito de arena (el primero y, hopefully, no el último) ha sido proponer, perseguir y, al final, colaborar con la Universitat Oberta de Catalunya (UOC) para que empiece a dar cobertura al testing como tal dentro de los estudios de Ingeniería Informática. El primer paso de esta, espero larga y fructífera, colaboración es en forma de un Crash Course de 5 semanas de duración titulado “Introducción a la calidad del software: Técnicas y métricas”, dirigido por Santi Caballé, donde actuaré como colaborador puntual.

Ahora pues, te toca a ti:

Qué vas a hacer tú para llevar el testing a la universidad?

Verano para autodidactas

Tras terminar el semestre universitario (por si alguien no lo sabe, estoy estudiando el Grado en Ingenieria Informática en la UOC) empieza el mejor periodo del año para los autodidactas: el Verano! Una estación donde solamente hay que trabajar (o ni eso, si tienes vacaciones) y se abre casi un trimestre para estudiar, investigar y aprender lo que uno quiera!

Personalmente, me gusta marcarme unos objetivos claros para no caer en la dispersión y agotar el tiempo sin haber hecho nada concreto. Tener unos objetivos y un plazo claros también te ayuda a ser consciente de tus progresos y del grado de esfuerzo necesario en cada momento. Así pues, mis objetivos en este verano para autodidactas 2013 son los siguientes:

Reflexionando mucho sobre este tema quiero realizar las siguientes tareas para mejorar mi profundidad técnica en lo que al testing se refiere:

Realizar el curso “Technical web testing 101” → Completed!

Fantástico curso para entender las diferencias entre testing técnico y testing de la superfície. Gratuito, breve pero intenso, on-line, con un profesor de nivel como Alan Richardson (The Evil Tester) y repleto de información, este curso (alojado en la plataforma de aprendizaje on-line Udemy) es ideal para principiantes y testers cero-técnicos con interés en barnizar su trabajo con una capa de mayor profundidad técnica a la hora de testear aplicaciones web. Es un curso de básicos con muchos punteros a información, recursos, herramientas, trucos y demás material para investigar por cuenta própia, con una filosofía muy del DIY, de conocer las herramientas que tienes a tu disposición (especialmente los navegadores y los proxies HTTP) y de encontrar la motivación dentro de uno mismo para investigar y preguntar hasta entender todo aquello que desconocemos, olvidándonos de la frontera entre lo que es técnico o no, lo que es testing y lo que no, en pro del conocimiento.

Os dejo el link del curso, en inglés (of course) → https://www.udemy.com/technical-web-testing-101/

Completar el track de jQuery en Codecademy → In progress

En mi dominio, tener nociones de HTML, CSS, JavaScript y jQuery es esencial, por ello me valgo de la fantástica plataforma  codecademy para alimentar esos conocimientos. En concreto ahora estoy en plena track de jQuery, el último que me falta, a terminar muy en breve, como puedes ver en mi perfil.

Adquirir nociones de Java → To start

Siempre he querido tener nociones de lenguajes de programación, y en mi trabajo disecciono diáriamente aplicaciones basadas en Java, así que ¿por qué no profundizar en este lenguaje? Para ello, cuento con este libro electrónico (también de Alan Richardson) llamado Java for testers, que parece un muy buen punto de partida para el nivel que quiero alcanzar (que no es el de ser un superdesarrollador, más bien el de entender los fundamentos para poder jugar con ellos).

Por otro lado, hace tiempo que quiero investigar sobre las posibles especializaciones dentro del testing (usabilidad, rendimiento, seguridad…) y aprovecharé este verano para…

Profundizar en el testing de seguridad → To start

Unas nociones superbásicas de este tema apasionante ya se tocan en el curso de “Technical web testing 101” del que ya os he hablado antes, y para profundizar más, tomaré este otro curso también en Udemy: Whitehat hacking and penetration testing, a ver cómo evoluciona!

Para terminar, y pensando en la charla que daré en la próxima edición de la conferencia QA&TEST 2013, quiero…

Mejorar mi inglés hablado! → In progress

Para ello, me he apuntado a un grupo de conversación en inglés que hay en mi barrio, un día cada dos semanas, para quitarle el óxido a esta habilidad cuya precisión depende totalmente del nivel de práctica que lleves encima.

Este es mi plan, y el tuyo? Qué te vas a auto-enseñar durante este verano? Cuéntamelo en los comentarios 😉

BBST Foundations course: superado!

BBST Foundations course: superado!

Pues sí, dado que en el mes de Agosto “sólo tenía que trabajar”, aproveché y me apunté a este curso llamado Black-box Software Testing Foundations, proporcionado por la Association for Software Testing (AST), una asociación americana con bastante renombre, fundada inicialmente por Cem Kaner y que cuenta entre sus afiliados con profesionales de máximo nivel como Ben Yaroch, Matt Heusser, Markus Gärtner…

Este curso es prerequisito para cursar otros dos cursos ofrecidos por la asociación: bug advocacy y test design y, una vez superados los tres anteriores, se puede realizar el curso de instructor para la AST.

El funcionamiento resumido del curso es el siguiente:

  • La duración es de 4 semanas
  • Se estructura en 6 lecciones, de 3-4 días cada una:
    • Conceptos básicos
    • Estratégia
    • Oráculos
    • Fundamentos de programación y cobertura
    • La imposibilidad del testing completo
    • Mediciones
  • Cada lección se compone de:
    • Un ejercicio de orientación (a responder primero y a comentar las respuestas de los otros después)
    • Videoclases impartidas por Cem Kaner (alrededor de 45 mins por lección)
    • Lecturas (algunas obligatorias y otras opcionales)
    • Un ejercicio colectivo sobre la lección (sí, colectivo, con gente, en plan foro). También aquí se requiere valorar el trabajo de otros grupos.
    • Un quiz (un mini-examen, de 10 a 15 preguntas de multirrespuesta)
  • Hay un examen final de tipo ensayo compuesto de 6 preguntas, sobre 20 posibles que son publicadas al inicio del curso, para que te lo vayas preparando (si puedes). Como la idea es aprender, el examen se debe hacer sin consultar materiales de ninguna clase aunque nada te lo impide; depende de ti engañar o no (engañarte a ti mismo por un aprobado, vaya).
  • Una vez hecho el examen, tienes que ofrecer tu opinión sobre el examen de 2 compañeros, para luego opinar sobre el tuyo tras reflexionar y mirar los materiales con detenimiento.
  • La nota final depende del desempeño durante el curso, así como del examen y de las correcciones de examenes de otros. Los quizzes no cuentan para nada, son para que uno mismo pueda saber como progresa.

La experiencia ha sido muy positiva, estoy muy contento de haber realizado este curso, y creo que opinaría lo mismo en caso de haber suspendido, aunque seguramente lo haría con un tono más tristón y apocado 😉

BBST slide sample

Captura de un slide dentro de una de las videoclases impartidas directamente por Cem Kaner

Cosas chachis del BBST Foundations course:

  • Cubre perfectamente las bases del tema: qué es el testing, porqué se testea, cuándo se acaba el testing, cómo se testea, cómo se puede medir el progreso…
  • Los materiales son de alta calidad, los slides que acompañan las videoclases son material oficial de la asignatura con el mismo nombre impartida en la Universidad de Florida Tech. Las lecturas incluyen textos básicos “para enmarcar” del propio Kaner, Michael Bolton, James Bach, Doug Hoffmann, Brian Marick…
  • El staff del curso (instructores y demás) es también de alto nivel. Los instructores de esta entrega del curso han sido John McConda, Iain McCowatt y Pete Walen, mas puntuales aportaciones de Michael Larsen como actual presidente de la asociación.
  • Un grupo de unos 30 testers de distintos orígenes, fases vitales, nuevos en el oficio o grandes veteranos… es siempre una experiencia.
  • Está bien de precio. El curso requiere ser miembro de la AST, en resumen, todo junto sale a unos 180 euros.

Cosas rollo del BBST Foundations course:

  • La carga de trabajo. MUY ALTA. He sufrido horrores para compaginar el curso con las 8/9 horas de rigor en el tajo más algo de vida conyugal (lo social quedó completamente descartado durante este tiempo)
  • La duración. Para asimilar bien todo y disfrutar el curso le falta, a mi entender, una semana más, y así no tener que hacerlo todo deprisa y corriendo. Al no ser así, la presión temporal es muy fuerte: Tener que reflexionar sobre un tema, mirar unos videos, leer un par de textos, hacer una parte de una tarea en grupo y hacer un quiz en 3-4 días ha sido de locos. Por no hablar de asimilar algo… Las lecturas opcionales, por ejemplo, ni tocarlas 😦
  • El trabajo en grupo. Ya se sabe. Hay gente agradable y otros que no lo son tanto; hay gente que trabaja y otros que figuran; tu zona horaria puede ser una ventaja o un inconveniente; habrá gente que esté en todo y otros que desaparezcan; habrá dinamizadores y bloqueadores de la evolución del trabajo… Lo que pasa en todas partes, vamos.
  • El contenido puede ser fácilmente tildado de “muy básico” por algunos. Ergo la obligación de pasar por este curso para hacer otros de más avanzados puede ser mal vista.
  • Si no tienes inglés, nada de nada. Dominar el idioma es vital para sobrevivir; por los materiales y examenes (obviamente) pero también por el trabajo colectivo, o tus compañeros no te van a entender ni tú a ellos.

En resumen, y ya me callo, para mi es un curso BÁSICO para todo aquél que guste de tener el testing como profesión y conocer sus fundamentos a fondo. Es edificante, se aprende, se disfruta y pone las bases para tu progresión como profesional. Eso sí, si volviera a hacerlo, me plantearía seriamente hacerlo durante las vacaciones 😛

¿Testing funcional o pruebas de caja negra?

¿Qué mejor que empezar un blog que se llama testing funcional con una definición de qué es el testing funcional propiamente?

Según el “Glosario estándar de términos utilizados en pruebas de software” publicado por el ISQTB y traducido por el SSQTB (obsequio por la asistencia al WinterTest 2011), las pruebas funcionales son pruebas diseñadas tomando como referencia las especificaciones funcionales de un componente o sistema (lo que vamos a testear, el software o una parte de él). Pruebas de funcionalidad, para comprobar si el software cumple las funciones esperadas. Queda claro en esta definición que la estructura interna del software o módulo testeado no se evalúa en estas pruebas, por lo que no afectará a la superación o no de las mismas.

En este mismo glosario, se sugiere como alternativa al concepto anterior el de pruebas de caja negra, pero si acudimos a la definición de este segundo concepto nos encontramos que las pruebas de caja negra…

  • …son ajenas a la estructura interna del objeto de las pruebas (en la estructura interna de los componentes se centran las pruebas de caja blanca)…
  • …pero no albergan solamente pruebas funcionales, sinó que también incluyen pruebas no funcionales.

¿?

Entonces… No son sinónimos? Las pruebas de caja negra incluyen a las de funcionalidad, no? Pero, ¿y qué son las pruebas no funcionales? Un poco reticente, busco si en el glosario hay una definición de este concepto, y me sorprendo encontrándola. Las pruebas no funcionales son pruebas que no se refieren a las funcionalidades (obvio), sinó a atributos transversales a la misma, como la usabilidad, la mantenibilidad, la eficiencia, etc.

Googleo un poco los cuatro conceptos (caja negra, caja blanca, funcional y no-funcional) y todas las fuentes confirman lo anterior, además descubro que se llaman pruebas de “caja negra” porque no se mira en el interior de lo que se prueba y se llaman pruebas de “caja blanca” (o de “caja de cristal”) por todo lo contrario.

Además de confirmar los conceptos del glosario, varias fuentes se refieren a la contraposición entre pruebas de caja negra (aspectos externos, en sentido amplio) y pruebas de caja blanca (aspectos internos), existiendo un fuerte debate sobre qué técnica es mejor. Intuyo que parte de este debate se origina en la histórica confrontación entre desarrolladores y QAs, dado que tradicionalmente las pruebas de caja negra son terreno de los testers, más orientados a la funcionalidad, mientras que las de caja blanca son terreno de los desarrolladores, con mayor capacidad técnica; de todas maneras, estos tópicos sobre “confrontaciones” y “terrenos” me parece que cada vez tienen menor validez en la dinámica y cambiante realidad del sector.

Mi opinión en este debate sobre qué tipo de pruebas es preferible es bastante fácil, ambas son deseables, puesto que nos llevan a la exhaustividad del testing. Las pruebas de caja negra nos aseguran que el software hace bien lo que tiene que hacer (el “qué), mientras que las de caja blanca aseguran que lo hace de un modo adecuado (el “cómo”).

Relación entre caja negra, caja blanca, funcional y no-funcional

Relación entre caja negra, caja blanca, funcional y no-funcional

Aunar estas dos pruebas no es tarea fácil, puesto que se requieren más recursos que si nos decantamos por una única metodología, además de perfiles más versátiles o equipos mayores (desarrolladores orientados a la calidad, QAs con conocimientos de desarrollo). Es fácil de ver que estos dos grupos de pruebas son complementarios y, en caso de combinarlos, tendremos aplicaciones mucho más robustas, pero si hay falta de tiempo o recursos y las aplicaciones tienen usuarios finales no técnicos, parece recomendable centrarse en las pruebas de caja negra, asegurando que lo que se tiene que hacer se haga, aunque no del modo idóneo desde el punto de vista más técnico.

Esto no es siempre así, todo el mundo barre para casa, entonces en cada empresa y según el perfil de los implicados o la metodología de trabajo seguida, el tipo de pruebas que domine un proceso de desarrollo de software será de un tipo o de otro. Si nos preocupa la calidad de lo que entregamos, debemos superar las estrecheces y acercar estas dos posturas, más preocupados por el objetivo final que es la producción de software de calidad total. Por ello es recomendable que los equipos de calidad tengan miembros con formación técnica, y que aquellos que no la tengan adquieran conocimientos básicos de la misma, idealmente guiados por los que sí la tengan. También facilita las cosas que el equipo de desarrollo se imponga como objetivo entregar buen código al equipo de calidad, previa comprobación exhaustiva del mismo, como por ejemplo defiende la escuela del Extreme Programming incluyendo entre sus prácticas el Test Driven Development.

Personalmente, soy más de caja negra y funcional, pero valoro las pruebas más técnicas y me alegro de tener compañeros concienciados y capacitados para hacerlas, además de estar entre mis objetivos el poder contribuir a este testing más técnico. Hay que reconocer que la dualidad de visiones es difícil de gestionar en algunos momentos, además de ser fuente de profundas confusiones y malentendidos, pero tengo esperanzas además de una clara convicción de que juntar las dos miradas es el camino a seguir para entregar aplicaciones excelentes. Y a por eso voy!