Características de la calidad del software

A veces, el idioma (en este caso, el inglés) es una barrera que separa a las personas de la información que necesitan o les puede ser útil. Por ello, he pensado en ocasiones en traducir material de otros relativo al testing y a la calidad del software, pero es un trabajo árduo, no soy un profesional de la traducción y está el tema de los derechos de autor…

Sin embargo, a veces, el destino te pone las oportunidades en bandeja, por ejemplo: http://thetesteye.com/blog/2013/06/translations-of-quality-characteristics/

Soy un gran seguidor de thetesteye.com en general y del trabajo de Edgren, Emilsson y Jansson en particular, ambos altamente recomendables. A partir de ahí, y contando con la inestimable colaboración de Núria Cardona y Marcel Puchol, después de unos meses de idas y venidas, hoy os traigo las traducciones de su gran “Software quality characteristics” al Español

Características de la calidad del software (ES)

…y al Catalán:

Característiques de la qualitat del programari (CAT)

Ambas traducciones publicadas oficialmente en thetesteye.com en este link. Espero que las disfrutéis!

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 😉

expoQA 2012

expoQA 2012

Inesperadamente, he asistido a la edición de este año del expoQA. Digo inesperadamente porque no tenía intención de asistir (las conferencias en general son muy caras, y tal y como está el patio, me parece muy bien que la empresa donde trabajo sea cauta en este aspecto), pero resulta que fui el afortunado ganador del sorteo de una entrada gratis entre los lectores del Testing Planet, revista-diario trimestral muy molona sobre testing, fabricada por la gente del Software Testing Club, y es muy feo rechazar los regalos, no? 😉

Total, que me planté en Madrid la noche del 5 de Junio y el 6 por la mañana, tras algún que otro incidente con el transporte interurbano madrileño (sí, he dicho “interurbano”, porque el venue no era muy accesible que digamos), estaba listo para devorar lo que fuera que se cociera en expoQA, sin saber muy bien cuál era la filosofía de la expo en si misma; es decir, son unas conferencias sobre testing y demás, pero ¿dadas por quién y a qué nivel? Pues a eso iba, a capturarlo.

expoQA

A toro pasado puedo decir…

Nivelazo.

Sin ser muy consciente de ello, me iba a exponer a varias charlas profundamente motivadoras e inspiradoras de #testingheroes como Paul Gerrard, Julian Harty, Graham Thomas, Stefaan Luckermaans, John Reber, Derk-Jan de Grood, Fred Beringer et al. Cada cuál hablando un poco de “su libro”, pero a grandes rasgos, hablando todos de lo mismo: la evolución del perfil profesional del tester, el futuro del rol, la importancia de la automatización para dejar espacio a otros tipos de testing y de mayor valor, como el testing de performance, el testing en dispositivos móviles, el testing de infraestructura…

Eddy Bruin, charlando sobre testing en dispositivos móviles

De las casi 40 ponencias, keynotes y charlas realizadas en los días 6 y 7 de Junio, “mi expoQA” se consolidó en 13 sesiones sobre dos grandes temas: mobile testing (fantásticas charlas por parte de Julian Harty y Eddy Bruin – en la foto -, así como una demo de SilkMobile, herramienta para automatización funcional en móviles de Borland / Micro focus) y filosofía / metodología / background / proceso del testing en general (este tema/s principalmente tocado por los grandes popes anteriormente mencionados).

Me esforzaré por ejecutar un Top 3 de charlas a las que asistí, aunque me quedaba con 7 de las 13, creo…

  1. “The redistribution of testing” – Paul Gerrard: primera sesión, primera keynote, inicio electrizante del expoQA. Que poderío, que ideas tan claras, qué manera de salirse del dogma y ofrecer visión de futuro del tester y su profesión sin sonar fatalista ni pedante. Fantástico.
  2. “Test process improvement : answering the BIG questions” – Graham Thomas: es muy fácil señalar que algo tiene que mejorarse, así como preguntarse cómo mejorarlo, lo que es más complicado es responder a esas preguntas. Muy profesionalmente, este consultor independiente británico ofreció pistas sobre cuándo, quién, cómo… mejorar el proceso de testing. Muy interesante.
  3. Ex Aequo “Mobile testing” – Julian Harty / “Testing in a new world” – Eddy Bruin: empate en mi mente para estas dos en tercer lugar, fantásticas introducciones ambas al mundo de la movilidad y sus entresijos. Justo lo que necesitaba para perder el miedo al desconocido móvil y empezar a tener referencias básicas para empezar con buen pie en este terreno, que hace meses que llama a la puerta de Netquest. Mención especial a Julian Harty, improvisando una sesión magistral (por eso no hay link al programa) ante la ausencia del ponente oficialmente invitado a hablar de este tema. Los grandes se hacen grandes en estos momentos…

Como siempre me pasa en festivales, conferencias y demás, no asistí a las premiadas como mejores charlas de la edición (es algo innato en mi). Fueron las siguientes:

  • “Mutation: a testing technique ready for its transference to industry” – Macario Polo: escogida como la mejor ponencia por parte del comité de la expo, la técnica de la mutación se refiere a introducir errores en el código para comprobar si el testing encuentra esos errores, evaluando la confianza de las suites. Fantástica idea, que puede pegar fuerte en el futuro cercano.
  • “Exploratory Testing Myths” – Luis Fraile: elegida como mejor ponencia por parte de los asistentes, la charla de Luís trató del testing exploratorio desde el punto de vista desmitificador y práctico. Me quedo con mal sabor de boca por no haber asistido a esta, pero no se puede tener todo…

En resumen, gran experiencia, puede ser una práctica recomendable asistir a una gran conferencia sobre testing una vez al año, cargando las pilas y tomando ideas y ejemplo de lo más puntero en el sector, para luego volver a la tierra y aplicar algo de lo que se haya aprendido, ya sea en términos prácticos o filosóficos.

Nos vemos en la próxima edición (o lo intentaremos)!

¿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!