Entradas

QA en modo ITV

Imagen
Aún a día de hoy en muchas empresas el grupo o departamento de QA, en caso de existir, sigue siendo un componente externo a los proyectos. Personas a las que llegado el momento de la fase de pruebas se les pasa un entregable para que lo testeen y validen. En casos así, se suele considerar habitual que el departamento de QA juegue un papel de “certificador de calidad” o “gatekeeper”. El resultado de la fase de pruebas debe ser un KO u OK para producción o posteriores fases del proyecto. El equivalente a un sello otorgado por una entidad externa certificando que se es APTO Desde mi punto de vista, aunque este enfoque pueda ser necesario en ciertos tipos de proyectos donde el grado de exigencia de calidad sea muy alto ya sea por criticidad del sistema en sí o por cumplimiento de leyes, no representa los proyectos que desarrollan en el día a día la inmensa mayoría de empresas. En general, el papel del equipo de QA de ser meramente auditor únicamente involucrado en la fase final

Distancia entre testing y equipo de desarrollo

Ya sea el proyectos ágiles o no, a día de hoy en las empresas existen varias opciones sobre dónde ubicar a los tester o QAs en relación al equipo de desarrollo. Estas son las opciones con las que me he ido encontrando y los pros y contras de cada una de ellas desde mi punto de vista. Externalizado a otra empresa Pros Ideal para beta testing o testing exploratorio : Las pruebas por personas que no conozcan el producto y que no hayan participado en su definición hacen sea mucho más parecidas al uso que harían los usuarios finales Mobile testing: Permite aumentar el número de dispositivos y combinación de configuraciones con terminales reales Soluciones tecnológicas complejas : Una empresa externa puede estar especializada en arquitecturas de testing complejas, disponer de la infraestructura necesaria para realizar pruebas de carga intensivas o en otros aspectos avanzados relacionados con el testing Optimización de recursos internos: Puede ayudar a optimizar los re

Exploratory Testing Chrome Extension

Imagen
Objetivo de un Tester A pesar de la percepción que muchas personas suelen tener, sobre todo desarrolladores, la labor principal de un tester no es la de romper cosas o la de lanzarse desesperadamente a la caza del bug. Muy al contrario, la misión del buen tester es la de centrarse en la mejora constante del producto. Para ello resulta vital empatizar y situarse en la piel del usuario final y tratar de interactuar con el sistema tal y como éste lo haría. Es durante este proceso cuando un tester detecta cosas que se rompen, inconsistencias, mejoras de interfaz, etc. que posteriormente reporta a los desarrolladores. Como dice James Bach: “Un tester no rompe el software, si no que rompe la ilusión de que el software funciona” - James Bach - ( “We don’t break the software. We break illusions about the software.” ) Vamos que más bien un tester rompe la “ esperanza ” de que las cosas funcionan como se esperaba Testing vs Checking Existen básicamente dos maneras de afronta

Lorem Ipsum

El otro día, en el trabajo, me tocaba continuar con el desarrollo de una página web en ASP.NET que había empezado mi compañero. Me llamó la atención que en un lugar de la página donde tenía que aparecer texto estaba esta frase: “Lorem ipsum dolor sit amet, consectetuer adipiscing elit” Al ver esta frase en “ latín” , pensé que se trataba de una frikada más de mi colega y no le di importancia. Al día siguiente,  cuando me disponía a finalizar el trabajo pendiente, volví a ver la frase de marras y la curiosidad me pudo: ¿Por qué habrá puesto esto?, ¿Cuál será el significado?. Después de un copiar y pegar en google, tuve la respuesta: Se trata del asdf del siglo XVI, es decir, texto sin significado que usaban en las imprentas en el año 1500 para ver el resultado de la maquetación de una página. Con el paso del tiempo, “ Lorem Ipsum” se han mantenido como las dos primeras palabras de un texto de relleno generado sobre la combinación de más de 200 palabras latinas. Construir un con