QA&TEST Blog

Si tenemos en cuenta la cantidad de información disponible en los archivos de registro, cualquiera pensaría que las empresas debería dedicarles más atención. Los equipos, servidores, firewalls, dispositivos de red y otros dispositivos generan archivos de registro cada día, pero a menudo las empresas los ignoran.
Aunque sea un fallo grave de seguridad, es comprensible. En primer lugar, los registros pueden contener infinidad de eventos irrelevantes, de hecho, la mayoría no son más que ruido. Excepto raras excepciones, la mayoría de los registros son inútiles. En un cliente medio, con 1000 ordenadores con un firewall, se generan 25GB de archivos de registro diariamente, de los cuales, en una semana típica, ni un solo caso es un problema de seguridad que requiera una respuesta inmediata. Sí, a veces hay algunos problemas graves de seguridad, pero normalmente pasan desapercibidos entre un mar de ruido sin importancia.

Pulsa aquí para seguir leyendo este artículo en Infoworld

Aunque la implementación de un nuevo sistema suele ir acompañada de una formación rigurosa y una minuciosa documentación, suele quedarse obsoleta en cuando se lanza la siguiente versión. La mayoría del software de negocio (como oposición a las herramientas de escritorio, como procesadores de texto u hojas de cálculo), está en un estado constante de cambio, igual que el mundo de los negocios se adapta a las nuevas tecnologías para ser más competitivo y satisfacer las demandas de los clientes.

Lamentablemente, la formación del personal de la empresa no puede justificarse sólo porque haya dos nuevas funciones en un sistema, y los plazos de entrega no siempre permiten actualizar la documentación y materiales formativos. Se opta por el boca a boca para aprender a utilizar las nuevas funcionalidades del sistema, y el resultado final es la distorsión del proceso: es el juego del teléfono escacharrado.
Pero, ¿y si en lugar de documentar los procesos y formar a los usuarios, automatizamos los procesos que deben seguir los usuarios? En otras palabras, ¿y si formamos al software y no a la persona?

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

Muchas empresas gestionan sus casos de prueba de regresión manualmente; entonces, ¿cuándo es necesario comenzar la automatización de los casos de prueba de regresión? La automatización tendrá sentido cuando ya no se pueda ejecutar la prueba de regresión en cada caso particular. Por ejemplo, si llega un momento que en su empresa no es posible llevar a cabo pruebas de regresión a medida que se desarrolla el código, quizás sea el momento de sopesar la posibilidad de automatizarlas.
Para automatizar casos de prueba, debe adquirir una herramienta de pruebas automatizada y, a partir de ahí, puede utilizar la herramienta para crear sus casos de prueba en pruebas de regresión.

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

Los sistemas diseñados en código abierto presentan grandes ventajas. La más destacable es que las organizaciones dedicadas al desarrollo pueden diseñar sistemas más rápido, y de forma más flexible y económica.
En el panorama económico actual, es difícil concebir un escenario donde cualquiera pueda empezar un proyecto de desarrollo con la idea de escribirlo entero desde cero. Numerosos ejemplos de componentes de código abierto, como bases de datos, kernels, generadores de informes, herramientas, utilidades o plataformas están disponibles de forma gratuita y fácilmente combinables con otro código, para desarrollar sistemas de forma más rápida y económica. Hoy en día, los desarrolladores pueden encontrar código abierto con una simple búsqueda a través de Internet, en motores de búsqueda especializados en código abierto.

Si quieres seguir leyendo este artículo en Embedded.com, pulsa aquí.

El 11 de diciembre de 2008, el Consorcio de la World Wide Web (W3C) publicó la segunda versión los Estándares de Accesibilidad en Contenido Web (WCAG; Web Content Accessibility Guidelines). Este nuevo estándar ayudará a los diseñadores y desarrolladores a crear sitios web que tengan en cuenta las necesidades de usuarios con minusvalías y de edad avanzada.
Basado en la experiencia de los autores y las recomendaciones de la comunidad de usuarios, WCAG 2.0 actualiza las ya de por sí excelentes recomendaciones del W3C para incluir nuevas tecnologías y tests más exhaustivos.
El nuevo Estándar de Accesibilidad en Contenido Web cubre una amplia gama de recomendaciones para facilitar la navegación por internet a personas con discapacidad visual o auditiva, problemas de aprendizaje, limitaciones cognitivas o motrices y otros, además de hacer la web más fácil de usar a todos los usuarios, en general.
Haz click aquí para ver las recomendaciones.

Actualmente, el mundo se apoya en una serie de sistemas informáticos que, si por un momento fallasen, podrían causar un desastre financiero, un caos organizativo o, en el peor de los casos, la muerte. El software desempeña un papel fundamental en estos sistemas, y no deja de ser preocupante que con el uso de sistemas embebidos, no se refuerce el control de los dispositivos.
Organizaciones como “Which?” en el Reino Unido se dedican a examinar los electrodomésticos y dispositivos. Aunque por norma general estos aparatos se examinan a fondo, consideran que también es importante desmontar los dispositivos para detectar defectos de fabricación, como por ejemplo, el cableado inseguro. Pero en cuanto los sistemas embebidos entran en escena, ya no tenemos esa transparencia. Los automóviles, por ejemplo, dependen en gran parte de un ordenador, y no tenemos acceso al software, así que no hay forma de saber si esos coches son “inseguros a cualquier velocidad”.

Pulsa aquí si quieres leer el artículo completo de Robert Dewar en ESE Magazine.

A pesar del atractivo de las técnicas virtuales para los desarrolladores de software embebido y para los fabricantes de equipos, el uso de las nuevas tecnologías se puede estancar debido a las inherentes limitaciones de las plataformas de virtualización. Echemos un vistazo a las limitaciones y a cómo pueden superarse mediante un enfoque diferente a la hora de desarrollar software embebido mediante técnicas virtuales.
Durante los últimos cinco años, la virtualización ha pasado de ser una tecnología casi desconocida para convertirse en un concepto clave en los servidores de empresa y en las aplicaciones de escritorio. Actualmente, las técnicas virtuales han comenzado a desempeñar un papel fundamental en el desarrollo de software embebido.

Si quieres leer el artículo completo de Gernot Heiser en Embedded.com, pulsa aquí.

Una empresa danesa dedicada al testing de software destaca por tener un 75% de autistas en su plantilla. Su fundador, Thorkil Sonne, empezó a interesarte por la integración de los autistas en el mundo laboral cuando en 2004 se le diagnosticó el Síndrome de Asperger (un tipo de autismo que afecta seriamente a la forma de relacionarse de quien lo posee) a su tercer hijo. Sonne descubrió que sólo un 6% de la población autista está integrada en el mercado laboral, y enseguida se dio cuenta de que las características del perfecto tester de software coincidían con las habilidades que mostraba su hijo: tener buena memoria, seguir instrucciones cuidadosamente, ser persistente, notar cualquier desviación de los resultados esperados… Estas son, precisamente, las características del autismo.
Actualmente, en esta compañía trabajan 50 personas, y siguen fieles a su filosofía: facilitar posibilidades de futuro mediante la integración.

Como test manager, ¿cuenta con una serie de herramientas esenciales que le acompañan a sus nuevos proyectos? Cada vez que me uno a un proyecto, siempre me llevo la colección de herramientas low-tech que he diseñado para que me acompañen en el proceso de testing. Es tremendamente útil tener a mano las plantillas, hojas de cálculo y ejemplos que he utilizado en el pasado, para recordarme qué es lo importante y por dónde empezar. Incluso una vez que el cliente ha comprobado los resultados finales, yo cuento con herramientas propias, como las checklist, que me aportan una información que yo considero esencial.

A esta colección de herramientas la llamo mi vademécum, cuyo significado en latín es “ir conmigo”.
Si quiere leer el artículo completo de Fiona Charles en Stickyminds.com, pulse aquí.

Hemos de reconocer que las listas de comprobación de código son bastante molestas; a menudo, ridículas en cuanto a longitud y contenido, y en absoluto divertidas. Este tipo de listas pueden ser útiles para encontrar defectos en la fase temprana del proceso de desarrollo de software, pero la mayor parte del tiempo son más un obstáculo que una ayuda.

Normalmente, los programadores usan las listas como una guía general, sin detallar cada uno de los archivos. Entonces surge una duda: ¿estarán recogidos en la lista los puntos más importantes?

Si quieres leer el artículo completo de Jason Cohen en Embedded.com, pulsa aquí.