Las métricas son estándares para medir que se han estado usando en la industria del softwate, y en otros muchos sectores, para indicar la efectividad y la eficacia de una actividad en particular dentro de un proyecto. En este caso en particular estaré hablando de métricas en entornos de pruebas.
Las métricas existen en una gran variedad de formas. La pregunta no es si debemos utilizarlas, sino, cuales debemos utilizar. Lo más simple casi siempre es lo mejor.
Read more
¿Te gustaría construir, testear y “deployar” tu software de forma estable y fiable? Tal vez la integración continua te pueda ayudar. La Integración continua (continuous integration en inglés) es un proceso automático que permite comprobar continuamente que todos los cambios realizados por cada uno de los desarrolladores, no producen problemas de integración con el código del resto del equipo. Se pierde mucho tiempo integrando todo nuestro código, y sobre todo, pasar del entorno de desarrollo al de producción. Esto nos permite construir nuestro código desde las fuentes, simular nuestro entorno de producción y realizar algunas pruebas que garanticen su estabilidad.
Las pruebas estáticas ó Static Testing se realizan con el propósito de validar que las especificaciones del diseño se implementan adecuadamente tal y como se especifica en los requerimientos del producto y validar la calidad del diseño. Static testing es considerado como una de las técnicas más efectivas de encontrar defectos en fases tempranas de desarrollo, ahorrando mucho tiempo y dinero. Por supuesto no sólo implica diseño, sino también inspecciones de requisitos, software walkthrough (proceso de examinar algoritmos y código de fuente)…estás técnicas se pueden englobar dentro de técnicas de White Box Testing.
Read more
¿Es bueno tu proceso de testing? Esta es una pregunta muy fácil de hacer y muy dificil de contestar. Las pruebas de software amenudo consumen mucho tiempo y dinero. Muchas organizaciones se han dado cuenta que mejorando sus procesos de pruebas pueden solucionar estos problemas. Sin embargo, en la practica resulta mucho más dificil saber que medidas tomar para mejorar y controlar el proceso.
El modelo TPI está basado en las mejores prácticas de la industria relativas a la mejora del proceso de pruebas. El modelo incluye guías prácticas para evaluar el nivel de madurez de prueba de una organización así como los pasos para mejorar el proceso.
Read more
Tal y como se esperaba, VMware ha lanzado hace ya algunos meses una versión Beta gratuita de su VMWare Server, sucesor de su anterior producto VMWare GSX. VMWare Server soporta la virtualización de los sistemas operativos Linux, NetWare, Solaris x86 y Windows, en sus versiones 32 y 64 bits (!). Además, también soporta la reciente Virtualization Technology de Intel.
VMWare Server puede soportar de 2 hasta 4 máquinas virtuales simultáneamente por núcleo en el host, mientras que VMWare ESX Server soporta de 4 a 8.
Esta herramienta es ideal para optimizar el desarrollo y las pruebas de software al permitir crear múltiples entornos con diferentes sistemas operativos en el mismo servidor.
En YouTube he encontrado esta ponencia titulada “Testing Distributed Systems with AJAX, XML”, dentro de las jornadas de Google Developer Day. Martin Omander y Jason Huggings explican como “Google Checkout” utiliza Selenium para automatizar sus pruebas funcionales. En el video hay algunas demos de como usan selenium en Google. Esta ponencia no tiene desperdicio…
[youtube gFlaZ2UjAEw]
Afirmar que hay software 100% libre de fallos es totalmente falso. Es perfectamente normal que los desarrolladores cometan errores y que una aplicación no funcione a la primera. Bueno, esta afirmación es perfectamente discutible y me he encontrado con gente en foros que sostiene que es capaz de desarrollar software completamente Bug Free.
En fin, Javier Lopez Arana me envia este artículo donde cita algunas de las razones de porque el software no está libre de defectos.
Falta de comunicación entre los equipos de desarrollo y calidad – Como consecuencia, algunas veces no están claros los requerimientos que tiene que tener la aplicación software a diseñar, es decir lo que la aplicación debería y no debería hacer
Complejidad del software – La complejidad de las actuales aplicaciones software, aplicaciones que usan configuraciones multi capa, arquitecturas cliente – servidor, bases de datos relacionales, complejas comunicaciones de datos, bases de datos relacionales así como el uso de tecnologías orientadas a objetos puede ser difícil de entender para personas sin experiencia en el desarrollo de software actual.
Errores en la programación – Los programadores, como todo el mundo, pueden cometer errores. Es importante que le equipo de QA testee profundamente todos los requerimientos de la aplicación y tener un sistema de seguimiento de defectos que permita a los programadores solucionar los defectos que han sido encontrados por el equipo de QA
Presiones de tiempo – Ya sabemos que los schedules de los proyectos software son bastante ajustados y que cuando se acercan los deadlines es más fácil que se cometan errores por motivos de presiones de entregas
La implantación de nuevas funcionalidades en fases avanzadas del ciclo de vida del producto puede generar nuevos errores en funcionalidades que anteriormente funcionaban correctamente – de ahí la importancia de los test de regresión
Las tools de desarrollo de software, pueden introducir sus propios issues dando origen a issues que no son consecuencia de problemas en el código de la aplicación a diseñar sino que derivan de problemas en el código asociado a las tools de desarrollo de software
Cambios en los requerimientos – Se trata de un problema bastante común en aquellas organizaciones donde existen expectativas relativas a que los requerimientos se pueden predeterminar y pueden permanecer bastante estables. El usuario final puede no entender los efectos de los cambios. Como consecuencia de estos cambios se tienen que realizar rediseños, cambios en los schedule que pueden afectar a otros proyectos. Dependiendo del número de cambios y de su importancia aumentara la complejidad de la coordinación de los equipos de trabajo lo que puede originar errores. Todo esto tiene que ser tenido en cuenta por el equipo de QA para realizar y planificar un testing extensivo y exhaustivo
Código pobremente documentado – Es complicado mantener o modificar el código que se ha escrito sin documentar. La complejidad aumenta si la persona que tiene que mantener o modificarlo no es la misma persona que lo ha escrito.
