QA&TEST Blog » Testing

Testers: poneos en la piel del usuario final

admin — Wed, 08 Feb 2012 17:30:17 +0000

Una de las mayores críticas acerca de testers y organizaciones vinculadas a la calidad de software es que no entienden el negocio del usuario final. Si crees que eso es cierto, explica por qué no se tiene en gran estima al equipo de testing. Cuanto más sepas acerca del consumidor final, más efectivo serás como tester.
Cuando lideraba equipos de testing, hice del “conocer a tu consumidor” un punto prioritario para el personal. Para ello, organicé excursiones de desarrollo de negocios a las localizaciones de lo clientes, para que los testers observaran cómo y por qué utilizan el sistema o aplicacione. Una vez que volvíamos de estos viajes, el equipo empezaba a modificar la forma de enfoque del proceso de testing.

Sigue leyendo el artículo completo en Sticky Minds.

Los siete pecados capitales en SW Testing

admin — Fri, 03 Feb 2012 17:17:02 +0000

Testers con Síndrome de Asperger

admin — Mon, 30 Jan 2012 10:23:10 +0000

Últimamente proliferan en Europa las empresas de testing que contratan a testers con Síndrome de Asperger o con autismo. Esta práctica tiene ventajas e inconvenientes, y la mejor forma de descubrirlos es hablando con una persona afectada por este síndrome. Tirsh Khoo, tester en Sidney para una conocida plataforma de gestión de campañas de email, ha concertado una entrevista con Michael Drejer, que tiene síndrome de Asperger y trabaja como tester en una empresa de Dinamarca.

Pulsa aquí para ver la entrevista completa.

Smart grid: qué es, qué se necesita y qué debes saber

admin — Mon, 27 Sep 2010 09:25:59 +0000

Vamos a definir smart grid como la infraestructura y tecnologías que permiten la integración de los consumidores y los recursos distribuidos (generación, las energías renovables, el almacenamiento, la respuesta de la demanda, control de carga) con el funcionamiento de toda la red de suministro y mercados de la electricidad, además de mejorar la fiabilidad y seguridad del servicio eléctrico en general. La mayor diferencia es la falta de comunicaciones de bajo coste, el estandarizado, y las comunicaciones ubicuas que proporcionan ancho de banda, fiabilidad extrema, y seguridad, tanto para aplicaciones de control y gestión, así como la gestión de la información básica y las aplicaciones de uso compartido. Esta infraestructura de comunicaciones de banda ancha no tiene por qué ser una tecnología, pero es necesario ampliarla de los sistemas de control central a los dispositivos de usuario final.

Pulsa aquí para leer el artículo completo en Embedded Computing Desing.

El impacto de la automatización en el desarrollo

admin — Thu, 02 Sep 2010 11:47:26 +0000

Parece obvio que la automatización afectará a la organización de las pruebas. Menos obvio –aunque no menos real- es que también afectará al desarrollo de la empresa. De hecho, cuando eliges automatizar el testing para una aplicación, tu relación con el departamento de desarrollo cambia completamente.

Piensa en ello. Los testers manuales solo tienen que ser capaces de interactuar con la aplicación utilizando la pantalla, el ratón, el teclado u otro dispositivo. Las herramientas de pruebas automatizadas, por otro lado, tienen que interactuar con el software en un nivel más profundo, por lo tanto, exponiendo el nivel más interno de funcionamiento del código y tal vez, descubriendo problemas que impiden o complican la automatización. Si no se tiene cuidado, los desarrolladores podrían pensar que de golpe te has transformado en un entrometido que solo quiere meter la nariz en sus asuntos.

Pulsa aquí para leer el artículo completo en Sticky Minds.

Los 8 mandamientos de las pruebas unitarias

admin — Thu, 26 Aug 2010 11:20:18 +0000

Los equipos que realizan pruebas unitarias en una base regular se perciben como más confiables, profesionales y avanzados. Pero, qué es lo que necesitas considerar antes de elegir una solución basada en pruebas unitarias?

A continuación encontrarás los “ocho mandamientos” que te guiarán a la hora de seleccionar las pruebas unitarias más adecuadas a tu desarrollo.

1. No debes perder el tiempo en la curva de aprendizaje
Al elegir una solución basada en pruebas unitarias, querrás una que requiera el tiempo mínimo de ejecución. Puede valer la pena cronometrar a un nuevo desarrollador dentro de tu equipo para hacerte una idea aproximada de cuánto tiempo es necesario para empezar. Por ejemplo, cuánto tiempo llevará preparar las tres primeras pruebas del sistema? Es clara y sencilla la API? Hay una guía clara de qué hacer en cada punto del proceso? Con qué frecuencia es necesario comprobar la documentación? Cómo de fácil es buscar el siguiente paso cuando no se está seguro de por dónde seguir? Algunas herramientas ofrecen orientación, mientras que otras que otras ofrecen ayuda más extensa. Otras no ayudan en absoluto.

Pulsa aquí para seguir leyendo los “8 mandamientos” de las pruebas unitarias en EE Times Embedded.

Escucha a tus clientes

admin — Fri, 16 Jul 2010 15:16:27 +0000

El cliente se equivoca a menudo. La habitual costumbre de solicitar feedback a los clientes e incorporara esos comentarios en los productos es una forma brillante de producir prototipos. Los prototipos son, por supuesto, esqueletos mal implementados en ese espejo un producto real. Su función es minimizar de forma rápida el riesgo que surge de vagas obligaciones, cuestiones que la ciencia desconoce o de otras inceridumbres. Los prototipos son inestimables cuando son necesarios, pero no son necesarios para cada producto. Al menos, no la mayoría.

Por ello, los equipos de ingenieros necesitan protección ante los clientes a la hora de desarrollar el producto real.
Pulsa aquí para leer el artículo completo en EE Times.

Software embebido orientado a la verificación de hardware

admin — Thu, 01 Jul 2010 10:54:39 +0000

En las mejores estimaciones, el esfuerzo de desarrollo de software detrás del diseño de chips de 90 nm, ya ha superado el esfuerzo de desarrollo de hardware. El pronóstico para 2011 es que menos del 40 por ciento del costo global de desarrollo de chips se gastará en el hardware. Ahora mismo, el software ahora domina los ciclos del proyecto y establece cuándo un chip puede entrar en producción. Como resultado, se ha incrementado la importancia de la verificación de software, y a su vez, el software ha asumido un papel fundamental en el proceso de verificación de hardware.

Pulsa aquí para leer el artículo completo en Embedded Computing Design.

Testea tus diseños basados en MEMS para detectar fallos de hardware

admin — Thu, 10 Jun 2010 09:19:41 +0000

La inspección interna no destructiva de sistemas microelectromécanicos (MEMS) a través de grupos de micro imágenes acústicas es muy útil en la búsqueda, caracterización y eliminación de anomalías y defectos.
Durante el desarrollo de un producto, la inspección acústica es de gran ayuda a la hora de modificar procesos para evitar posibles defectos. Durante la producción, la inspección acústica permite localizar los puntos de rechazo y detectar la deriva del proceso.

El transductor ultrasónico que escanea los circuitos envía ultrasonidos UHF a la superficie y registra los ecos que devuelve. Cada pulso de un eco ocurre miles de veces por segundo a medida que el transductor se mueve por la superficie. Cada escaneo de coordenadas x-y produce un pixel en la imagen acústica, que en la resolución utilizada para circuitos MEMS, supone millones de píxeles.

Pulsa aquí para leer el artículo completo en Embedded.com

La transición al testing ágil

admin — Mon, 07 Jun 2010 08:57:25 +0000

A algunos equipos de testing les puede confundir cómo hacer la transición a ágil. Si formas parte de un equipo, probablemente tengáis pruebas manuales para la regresión, bien porque nunca habéis tenido tiempo para automatizarlas o bien porque habéis estado testeando desde la interfaz gráfica y no tiene sentido automatizarlas. En tu equipo habrá estupendos testers que puedan encontrar problemas en aplicaciones complejas pero que, sin embargo, no tienden a automatizar sus pruebas y necesitan un producto final antes de empezar a testearlo. Entonces, ¿cómo se puede equiparar el ritmo de trabajo de los testers al de los desarrolladores?

Este es un problema bastante común. En muchas empresas y organizaciones, los desarrolladores creen que han evolucionado a ágil mientras que los testers siguen atascados en pruebas manuales y no pueden mantener el ritmo. El problema no es que los testers sean demasiado lentos, sino que el equipo debe trabajar de forma paralela y, hasta que no lo consiga, los testers parecerán demasiado lentos.

Pulsa aquí para leer el artículo completo en Sticky Minds.