El mundo de la usabilidad está últimamente muy en boga. Para mi es muy interesante e importante y parece que al fin se le reconoce el valor que aporta.
Por supuesto, los que trabajan en usabilidad, no son los que miran que ‘los colores’ sean los más bonitos.
Tras asistir a algunos cursos, leer algunos libros (como “Usabilidad. Diseño de sitios Web” de Jakob Nielsen y “Don’t make me think” de Steve Krug), leer bastante documentación varia disponible en Internet y trabajar sobre el tema en algunos proyectos internos y otros externos (servicios prestados a otras empresas clientes), creo que me atrevo a resumir diferentes métodos aplicables relacionados con la usabilidad. Read more
Podemos implantar un sistema de la calidad, partiendo de documentos de requerimientos y/o de casos de uso, podemos escribir los planes de pruebas, hacer el diseño y escribir al detalle todos los casos de prueba, podemos ejecutarlos en paralelo al desarrollo e ir manteniéndolos con los cambios.
Con todo eso puede valer para tener un producto de calidad, pero ¿qué pasa si añadimos un ingrediente más a la receta: el análisis y gestión de riesgos?
La actividad de la gestión de riesgos no es un trámite o formalismo a cumplimentar para superar una certificación: es algo útil. La gestión de riesgos cierra el círculo, vinculando requerimientos, riesgos y casos de prueba que controlan la mitigación de estos riesgos.
¿Qué aporta este ingrediente?
Read more
El objetivo del control de configuración (también llamado gestión de la configuración) es mantener la integridad de las versiones que obtenemos a lo largo del desarrollo de un producto, garantizando que no se realizan cambios incontrolados. Así, en nuestra herramienta de configuración no solo se encontrarán los ejecutables y código fuente, sino también los modelos de datos, modelos de procesos, especificaciones de requisitos, pruebas, etc.
La estrategia de gestión de configuración debe de ser conocida y aplicada por todos los integrantes del proyecto, por tanto, esta estrategia no aplica solo y exclusivamente a código o documentos técnicos. Los equipos de pruebas deberán utilizar este tipo de herramientas como repositorio de toda la documentación. Si no tenemos una herramienta de gestión de pruebas (ex. El test link, el Mercury Quality Center…) deberíamos de usar la herramienta de gestión de la configuración para almacenar test cases, scripts de rendimiento, scripts de automatización o cualquier otro tipo de documento que puede ser de ayuda al equipo de calidad. Aún así, no es mala idea tener las dos herramientas. Read more
Los defectos más graves de cualquier software suelen ocurrir en la fase de análisis de requisitos y en muchos casos son defectos que no son detectados hasta fases finales del proyecto. Es por eso que debemos considerar Quality Assurance teams como una parte importante del equipo que debe de integrarse con el ciclo de desarrollo desde etapas tempranas, y no sólo en la fase final de pruebas.
¿Porque es tan importante? Muy sencillo, cuanto más tardemos en identificar estos defectos, más costoso será arreglarlo. Pero no sólo será costoso a nivel técnico, sino también económicamente ya que añadirá un coste extra al proyecto. Read more
La mayoría de los cursos que se había recomendado en Softqa eran todos en Barcelona, pero bueno, en Madrid también hay centros donde se imparten cursos muy muy interesantes, como este de CMMI. Algunas personas me habían preguntado si conocía algún sitio donde imparten este tipo de cursos.
Se realizarán tres cursos en tres fechas diferentes comprendidas entre Marzo y Junio del 2008. Es un curso oficial y tiene un coste de 1.500 € + Iva. Este tipo de cursos son esenciales si queremos enfocar nuestra carrera profesional en el mundo del CMMI (cada vez más requerido por grande empresas del sector IT).
Apuntaros las fechas en vuestras agendas. Podeis encontrar más información en ESI consulting.
El hecho de testear una aplicación conlleva reunir cada vez más y más información. Esto a su vez provoca que cada vez encontremos defectos nuevos en áreas o que antes no prestábamos importancia, eternizando el proceso de testing y provocando una sensación (a mi juicio, verdadera) de que “el test nunca termina”. En vez de eso, deberíamos dar por terminado el proceso de test cuando creamos que hay una baja probabilidad de encontrar un defecto de alta severidad.
Read more
En toda aplicación multilenguaje se debería dedicar parte del esfuerzo del testing a los tests de localización. En estos tests se verifican varios componentes, esto hace que la localización se suela dividir en dos partes: la internacionalización (i18n) y la localización (l10n).
La internacionalización hace referencia a los aspectos de lenguaje e interfaz de usuario de nuestra aplicación. Se ha de verificar que no haya componentes hard-coded, o elementos específicos de una región. Normalmente revisaremos todo lo referente a componentes de lenguaje como la gramática, alfabetos o uso de mayúsculas, así como lo referente la user interface, como los mensajes, menús, iconos, imágenes, shortcuts y controles.
Read more
Se trata de un conjunto de herramientas de desarrollo que permiten a un programador crear aplicaciones para un sistema bastante concreto. Se puede ver como una interfaz de programación de aplicaciones o API creada para permitir el uso de cierto lenguaje de programación, o puede, también, incluir hardware sofisticado para comunicarse con un determinado sistema embebido. Los SDKs frecuentemente incluyen, también, códigos de ejemplo y notas técnicas de soporte u otra documentación de soporte para ayudar a clarificar ciertos puntos del material de referencia primario.
Read more
