QA&TEST Blog

Los riesgos de requisitos se encuentran entre los riesgos más insidiosos que amenazan los proyectos de software. Tanto si se trata de requisitos que no se han definido correctamente, como de la falta de participación del cliente en las necesidades de desarrollo o incluso de requisitos defectuosos, se encuentran entre las principales razones por las que los proyectos fracasan. Un equipo de un proyecto puede marcar la diferencia mediante la adopción y aplicación de prácticas ágiles. Cuando se aplican correctamente,  las prácticas ágiles pueden mitigar los riesgos más comunes asociados con los requisitos en proyectos de desarrollo de software.

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

El tema de la codificación de los estándares es algo muy recurrente entre desarrolladores de software, cuyas opiniones divergentes plantean cuestiones que van desde por qué necesitamos estas restricciones a cómo podríamos trabajar sin ellas.

Los ingenieros de software siempre han luchado con los estándares, y el desarrollo de lenguajes de programación C y C++ supone que tengan que dedicar todavía más atención. Estos lenguajes, flexibles y potentes, están profundamente arraigados en entornos industriales y embebidos. En los últimos diez años, los desarrolladores han aceptado la necesidad de controlar y limitar C y C++ para fines industriales, comerciales y de seguridad.

Haz click aquí para seguir leyendo este artículo en Embedded.com

¿Has oído alguna de estas frases últimamente?
“Los testers han encontrado demasiados errores, por lo que hay que retrasar el proyecto.”
“Cualquiera puede ser tester; solo tenemos que darle los pasos a seguir”
“Nuestros casos de prueba proporcionarán cobertura completa del sistema“.
Ni una sola de estas comunes afirmaciones acerca del testing es cierta; al menos ninguna podría haber sido dicho por un tester.

Es imprescindible promover la precisión en la información acerca de las pruebas y los resultados para el trabajo de los testers y el responsable del equipo de testeo. Es fundamental acabar con los mitos y conceptos erróneos acerca del testing y lo que se puede y no se puede hacer. También debemos estar alerta y preparados para hacer frente a las posibles versiones que se puedan dar de un mismo mensaje acerca del testeo, incluso si esas versiones vienen de nosotros mismos o de nuestro equipo.

Si quieres seguir leyendo este artículo en Sticky Minds, pulsa aquí.

La virtualización es una tecnología establecida desde hace largo tiempo en el mundo de los servidores. Durante décadas se han utilizado diversas fórmulas para establecer el uso de esta plataforma, y en los últimos años, ha adquirido un creciente interés público al poder utilizarse en ordenadores personales. El hecho de que la virtualización pueda aportar un elevado nivel de aislamiento, y que se pueda adquirir con una capa básica de código, ha incrementado también el interés por la seguridad relacionada con las aplicaciones.

La posibilidad de integrar múltiples sistemas independientes en una única máquina, podría ser muy beneficiosa para muchas de las aplicaciones de seguridad crítica. Sin embargo, además del especial aislamiento que ofrece la virtualización, muchas de esas aplicaciones necesitan un nivel temporal de determinación: cada subsistema interactúa con un componente técnico, y en consecuencia, tiene que tener en consideración las propiedades de sincronización de estos componentes.

Haz click aquí para seguir leyendo este artículo en Embedded Control Europe.

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.

Uno de los desafíos de los sistemas en tiempo real, especialmente en aplicaciones que corren sobre sistemas operativos multitarea, es la resolución de defectos. Para solucionar los defectos, hay que ser consciente del flujo del programa en el momento en el que se da ese bug. Normalmente, esto se hace mediante el uso de emuladores integrados en circuito (ICE).
Sin embargo, el ICE de apoyo no siempre estará disponible y de esta forma, se perdería la dinámica del sistema y todas las interacciones que el sistema había establecido con otras redes y sistemas, se pararía de golpe, lo que provocaría que reproducir el defecto o anomalía sea muy difícil.  Aunque el ICE puede proporcionar información en tiempo real, la posibilidad de rastrear la función y dar con el defecto también está limitada, por lo que a veces será necesario poner fin a los procesos del sistema, para poder analizarlo en ese preciso momento; una característica que tampoco es normal en los sistemas de depuración habituales.

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

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.