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 😉

QA & Test Bilbao 2013, allá vamos!

For the first time, presentaré una sesión dentro de la conferencia internacional QA & Test Bilbao 2013 en calidad del software y sistemas embebidos. La charla que daré se llama “Testing beyond software: a case study”, en la que pretendo explicar un caso práctico de aplicación de procesos de testing más allá del desarrollo de software, en un escenario de uso operativo del software, un ejemplo perfecto de calidad aplicada a la producción.

Nos veremos allí? 🙂

Trucos de Selenium IDE – Intro, recording, waiting

Trucos de Selenium IDE – Intro, recording, waiting

Hasta ahora, Selenium IDE me ha salvado mi vida de tester suficientes veces como para decidir lo siguiente:

  1. Profundizar en esta herramienta esencial para los testers, con la intención de entender propiamente qué es, qué es lo que he estado haciendo con Selenium IDE, cómo puedo sacar mayor beneficio de la misma, etc.
  2. Difundir la palabra sobre esta herramienta (a veces) minusvalorada, defendiendo su honor y ayudando y animando a otros a profundizar, aprender e inspirarse de ella.

Qué mejor manera de hacer esto que blogear? Así que he desarrollado una pequeña serie de posts sobre Selenium IDE, explicando algunos trucos que hago servir, escribiendo porqué y cómo los uso, ya que… To blog is to learn!

Este primer post pretende introducir la serie, explicándonos qué es Selenium IDE y algunos conocimientos básicos sobre la misma. Allá vamos!

Qué es Selenium IDE?

Según SeleniumHQ (el site oficial del proyecto), Selenium IDE es un “add-on para Firefox que hace un sencillo Record-and-playback de interacciones con el navegador”. A partir de esta definición, concentrémonos en algunos conceptos:

  • IDE: IDE son las inciales de “Integrated Development Environment”, y esto quiere decir que estamos delante de una aplicación que nos ayudará a desarrollar utilidades relacionadas con el software.

  • Firefox: sí, Selenium IDE solamente está disponible para Firefox, así que no nos va a ayudar en la ejecución de cross-browser testing, pero es una herramienta ligera e inestimable para automatizar testing funcional de carácter general en navegador.

  • Add-on: un add-on para un navegador (también llamado una extensión del mismo) es un complemento instalable que añade funcionalidades o amplía las que tiene el navegador por defecto. Esto es lo que Selenium IDE nos ofrece, añade funcionalidades de record-and-playback de interacciones con el navegador a nuestro Firefox.

  • Record-and-playback: esto quedaría mejor com record and/or playback. Puedes grabar o no, pero en lo que estamos interesados es en el playback, en la reproducción, porque es lo que realmente nos porporciona capacidades automatizadoras, la reproducción de…

  • Interacciones con el navegador: este es el tema, esto es lo que Selenium IDE hace fantásticamente. Con este add-on podemos grabar, generar, gestionar y ejecutar interacciones von el navegador, simulando los clicks, selecciones, movimientos, escritura… de un usuario real en páginas web y su contenido.

Pues, para resumir esta sección con palabras sencillas, Selenium IDE es un pequeño complemento para nuestro navegador Firefox que nos permite simular interacciones de usuario vía navegador en páginas web. Con él, seremos capaces, entre otras cosas, de ejecutar testing funcional automatizado en navegador web.

Cuándo es Selenium IDE una buena elección para testing automático?

Con Selenium IDE podemos almacenar y organizar casos de test y suites, así que es posible tener una suite de suites automatizada a ejecutar con esta herramienta. Selenium IDE es potente (más de lo que parece), pero limitada; es una gran herramienta para casos de test sencillos pero no tan apropiada para casos más complejos (con muchas ramas, condicionales, casos y demás). Además, tal y como hemos dicho antes, sólo funciona con Firefox, así que si se necesita una herramienta para cubrir casos más complejos y/o funcionando en distintos navegadores, es mejor echarle un vistazo a Selenium Webdriver o Watir. Hay herramientas comerciales que también podrán satisfacer estas necesidades.

Personalmente, yo la uso para ejecutar testing automático ligero, para repetir tareas tediosas pero simples durante una iteración o proyecto, pero sin el objetivo de almacenar o mantener esta automatización; haciendo esto, las pruebas se pueden desarrollar más rápido (aunque seguramente de forma sub-óptima), pero muy efectivas para el coste que implican. Además, Selenium IDE es un fantástico “facilitador” de testing no automático, ya que te puede ayudar en ejecutar rápida y robóticamente pasos tediosos y largos que dejan tu aplicación web lista para ser testeada, en un estado que  sea aburrido de conseguir. Automatizando el camino hasta este punto no estarás cansado ni enfadado, pero sí listo para ejecutar tu mejor testing en él! 🙂

El recording como inicio fácil…

La manera más fácil de empezar un caso de test con Selenium IDE es ejecutarlo manualmente con el botón de grabado a “on”; lamentablemente, hay muchas cosas que se escaparán de este grabado (eventos en background, esperas implicitas que ejecutamos como humanos sin darnos cuenta, cosas así). Por ejemplo, vamos a grabar una simple búsqueda en un motor de búsquedas, buscaremos el término “Software Testing” y veremos si luego aparece un link a la página de la Wikipedia sobre Software Testing en los resultados. Este es el código que obtengo tras grabar esto con Selenium IDE: 

open http://duckduckgo.com/
type id=search_form_input_homepage Software Testing
clickAndWait id=search_button_homepage
verifyElementPresent link=More at Wikipedia

Este test se puede reproducir sin ninguno de los problemas antes mencionados, ya que el grabado de Selenium IDE es suficientemente listo como para convertir mi gesto de “click” en el botón de búsqueda en un comando “clickAndWait”. La referencia implícita (esta pestaña se encuentra en la consola del IDE) de este comando dice…

clickAndWait(locator)

Generated from click(locator)

Arguments:

     * locator – an element locator

Clicks on a link, button, checkbox or radio button. If the click action causes a new page to load (like a link usually does), call waitForPageToLoad. 

Así que, virtualmente, el ejemplo anterior se corresponde al siguiente…

open http://duckduckgo.com/
type id=search_form_input_homepage Software Testing
click id=search_button_homepage
waitForPageToLoad 30000
verifyElementPresent link=More at Wikipedia

…donde el 30000 es simplemente un número arbitrário de milisegundos para llamar a un timeout una vez se hayan superado y la página no se haya cargado aún. El comando “clickAndWait” usa el timeout por defecto especificado en el menú “Options” del IDE, mientras que en “click” + “waitForPageToLoad” tenemos que especificarlo manualmente, luego puede ser mayor o menor que el timeout por defecto.

Podemos alcanzar algo similar usando el comando “pause” del siguiente modo: 

open http://duckduckgo.com/
type id=search_form_input_homepage Software Testing
click id=search_button_homepage
pause 30000
verifyElementPresent link=More at Wikipedia

Ejecutando este trozo de código podemos ver que la ejecución de este test SIEMPRE se espera 30 segundos (30000 milisegundos), sin importar si la página se cargó hace 20 segundos, cosa que suena mucho menos eficiente que las anteriores versiones. El tema es que necesitamos que se haga algo justo después de accionar el botón que nos asegure que la página (o recurso, o botón…) se haya cargado antes de seguir en nuestras comprobaciones, puesto que si tuviéramos el siguiente caso de test…

open http://duckduckgo.com/
type id=search_form_input_homepage Software Testing
click id=search_button_homepage
verifyElementPresent link=More at Wikipedia

…nuestro test seguramente fallaría ejecutándolo a la máxima velocidad, ya que le estamos diciendo a Selenium IDE que verifique justo después de hacer click, cuando resulta que este click provoca la carga de una página nueva, entonces verificar inmediatamente cosas sin esperar a que la página esté completamente cargada nos llevará fácilmente a que Selenium IDE verifique algo que todavía no puede encontrar, retornando un mensaje…

[error] false

…en la pestaña de log de la consola del IDE mientras ejecutaba el comando “verifyElementPresent”, puesto que cuando Selenium IDE está ejecutando este comando no hay link a la Wikipedia en la página (ya que esta no se ha cargado completamente todavía).

Final learnings

Grabar la ejecución de nuestros test cases nos ayudará a definir su esqueleto. Una vez hayamos hecho esto, conviene hacer debugging sobre los mismos (los breakpoints y las ejecuciones paso a paso nos ayudarán con ello) haciéndolos suficientemente robustos como para ser ejecutados a la máxima velocidad sin problemas, sin importar si la red de la oficina parece más lenta de lo normal.

Gracias por leer hasta el final y… nos vemos en el siguiente post de esta serie sobre Selenium IDE!

QA&Test 2012

QA&Test 2012

Por segunda vez este año, he tenido la suerte de ganar una entrada gratis para la conferencia QA&TEST 2012 celebrada en Bilbao los días 17, 18 y 19 de Octubre. Quiero reiterar el tema de “la suerte”, porque ahora que hace menos de 72 horas que se ha terminado el evento puedo decir oficialmente (de nuevo) que ha sido una experiencia…

FANTÁSTICA!

Amantes del testing de España y de todo el mundo, sintámonos afortunados de tener en nuestro territorio un evento de orfebrería como éste, una auténtica delicatessen de conferencia.

Honestamente, el QA&TEST 2012 me ha robado el corazón, por muchas razones, por ejemplo:

  • El pequeño formato que defiende la organización. El total de asistentes entre ponentes y público roza las 100 personas y se organiza en 2 tracks simultáneos que van cambiando de temática durante la conferencia, esto hace que sea un evento en el que impera la…
  • Cercanía. Hay algo en el ambiente de esta conferencia que te hace sentirte bien, como en família, la calidez está por todas partes, de principio a fin, desde la organización hasta los…
  • Contenidos. Un poco de todo, tocando todos los palos, ponentes de todo tipo, ponencias muy concretas junto a otras más generales, rigurosidad en la selección y mucha información que requiere de una correcta…
  • Duración. 3 días de conferencia, suficientes para cubrir temas con holgura, sin que sea corto y estresante ni largo e injustificable, para tratar los temas con todo lujo de…
  • Detalles. La calidad está en los detalles, el trabajo se nota en los detalles. Las cosas, los eventos, no salen a la perfección si no hay mucho trabajo detrás y no se atiende a las pequeñas cosas, por ejemplo los cuadernos con los slides de las ponencias impresos, las comidas fantásticas en los que se podía catar lo mejor de la cocina Vasca, el banquete en la histórica sociedad bilbaina con una copa posterior pagada por la organización, y un largo etcétera.

En resumen, un 10 para la organización 🙂

Entrando más en profundidad en lo que al testing se refiere, el QA&TEST de Bilbao no tiene nada que envidiar al “cartel” más mediático de ponentes de su pariente lejana ExpoQA, como prueba de ello están las ponencias y keynotes de Lynn Mckee, Nancy Kelln, Derk-Jan De Grood, Jan Jaap Cannegieter, Julian Harty, Shmuel Gershon… Pero no depende todo de eso; sin presentaciones de “relleno”, todos los temas de la conferencia se tocaban con mucha profesionalidad y la variedad de las temáticas de los tracks (QA, management, el testing en sectores industriales, automatización, mobile, organización de equipos, nuevas técnicas…) permite que, en global (y seguro en particular), sea una conferencia interesante y de valor añadido para todos los asistentes con interés en el testeo de software, la calidad y relacionados.

Mesa redonda sobre el futuro del testing con Bryan Bakker, Jan Jaap Cannegieter y Lynn Mckee

Me quedo con toda la experiencia, con todas las ponencias y keynotes, con todas las charlas e interacciones, creo que he aprendido muchas cosas en esta conferencia y, para resumirlo en citas sin cansar al personal, sugiero que pensemos seriamente en las siguientes ideas, puesto que pueden cambiar nuestra visión de la profesión:

“El testing se puede llevar a cabo sin casos de test” @nkelln

“Puedes transformar tu organización” @lynn_mckee

“Concéntrate en aportar valor a la gente de business@derkjandegrood

“Puedes hacer más de lo que te crees capaz” @jjcannegieter

“Porque el futuro del testing está en nuestras manos” @mauri_edo

Nos vemos en el QA&TEST 2013!!!

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!