El próximo 7 de Octubre la red temática RePRIS celebrará el III Taller sobre Pruebas de Software en Gijón. Algunas fechas a tener en cuenta:
Fecha límite para la recepción de contribuciones:14 de Julio de 2008
Comunicación de resultados de revisión: 19 de Septiembre de 2008
Versión definitiva de los trabajos: 3 de Octubre de 2008
Celebración del taller: 7 de Octubre de 2008
El taller se celebrará en el Palacio de Congresos y Exposiciones de Gijón (Asturias) a lo largo del día completo, coincidiendo con la celebración de las XIII Jornadas de Ingeniería del Software y Bases de Datos (JISBD 2008).
Video resumen de las Jornadas de Testing de Software 2008 emitido por la UPV(Universidad Politécnica de Valencia). Podéis leer el resumen de las jornadas en el blog de SQUAC:
Cualquiera que haya sido programador probablemente ha recibido defectos mal reportados. Defectos que no dicen nada ( “No funciona!”); que no tiene sentido; que no dan suficiente información; que dan información errónea. Defectos que resultan ser error del usuario, problemas que son culpa de otro componente del programa; o que resultan ser un problema de red.
Tenemos que distinguir claramente hechos reales de especulaciones. Debemos dejar a un lado las especulaciones, frases como: “Yo creo que el problema podría ser…”, y ceñirnos a los hechos, a lo que ha ocurrido.
No es muy aconsejable contratar un equipo de testing que tenga los mismos perfiles. Crea un equipo con diferentes puntos fuertes, distintos unos de otros. Analiza apropiadamente los tipos de actividades de pruebas que vas a realizar, y en función de ello comienza a pensar en el tipo de gente que mejor se pueden adaptar a esas necesidades. Por ejemplo, es obvio que si queremos realizar pruebas de rendimiento necesitaremos incorporar en nuestro equipo a una persona con experiencia en la utilización de herramientas de rendimiento y análisis de resultados. Si queremos automatizar, necesitaremos un experto en herramientas de automatización…
Esta claro que no es necesario que todos lo miembros del equipo tengan diez años de experiencia en testing o en alguna herramienta en concreto, pero si es importante que tengan algunos conocimientos mínimos sobre testing e informática. Un error común en este aspecto es dedicar desarrolladores a la realización de pruebas…siempre intenta contratar personas cuya carrera profesional se haya enfocado a las pruebas de software. Si necesitas realizar pruebas a bajo nivel, busca una persona con perfil de testing y buenos conocimientos en programación. Read more
Lo que en principio puede parecer una afirmación bastante lógica no siempre es así. En muchas ocasiones son los propios desarrolladores o jefes de proyectos los que, “alegremente”, cierran defectos que no han sido verificados por testing. Un defecto marcado como “Arreglado” (Fixed-Ready to test), debe de ser siempre verificado por el equipo de testing. Si el defecto es “rechazado” por no ser considerado un defecto, el tester deberá de pedir más información sobre el defecto para así realmente verificar que no se trata de un defecto y estar de acuerdo con la decisión. Si el defecto es rechazado por ser considerado “duplicado”, el tester deberá verificar que efectivamente el defecto existe y que efectivamente está duplicado. En muchos proyectos los desarrolladores tienden a esconder los defectos refugiándose en que el defecto está duplicado. Read more
Sólo hay que hacer una busqueda en google para encontrar cientos de artículos sobre “Test-Driven Development“. Si nunca has oido hablar de este concepto, el TDD (Test-Driven Development) se define a la técnica por la cual las pruebas se han de escribir siempre antes de que se escriba una sola línea de código.
No debemos olvidar por tanto que este tipo de pruebas son llevadas a cabo por el equipo de desarrollo y no por el equipo de testing. Esta técnica no sustiturá las pruebas funcionales, de rendimiento, o de automatización…sino que complementará a las pruebas realizadas por el departamento de testing. El objetivo principal es obtener código limpio que funcione. Read more
Estoy trabajando en una empresa con productos (soluciones informáticas para la gestión de empresas) líderes en el mercado.
Desde mi puesto de trabajo (Responsable de QA -ingresé a la empresa hace 6 meses-) he podido vivir de cerca las múltiples incidencias y la creciente reincidencia en errores en el ciclo de vida del producto.
Como equipo de QA, solemos exigir un mínimo de respeto a los protocolos y procesos aplicables al desarrollo y entrega de la versión, pero siempre hay un “coste de oportunidad” (salida al mercado y adelantamiento a competidores), así como también, la variabilidad de lo definido como “estratégico” a nivel corporativo. Entre otros temas propios de la cultura e historia de esta empresa.
Interesante curso sobre Pruebas de Software, ideal para gente que quiere introducirse en el mundo de las pruebas de software. Es un curso bastante completo que trata, en otros, los siguientes temas:
Estrategias y métodos de diseño de pruebas: White-box versus black-box testing.
Introducción de las revisiones períodicas en la estrategia de pruebas.
Generación de planes de pruebas específicos para las fases del desarrollo e implementación.
Características de las pruebas de sistema OO.
Características de las pruebas para aplicaciones Cliente/Servidor y Web.
Desarrollo del testing comercial off-the shelf (COTS).
Herramientas de soporte a las pruebas del software.
Fechas:
Barcelona: 17 y 18 de Junio del 2008
Madrid: 15 y 17 de Noviembre del 2008
La duración será de dos días, con un precio de unos 1700€ + IVA.
El próximo 7 de Octubre la red temática RePRIS celebrará el III Taller sobre Pruebas de Software en Gijón. Algunas fechas a tener en cuenta:
Cualquiera que haya sido programador probablemente ha recibido defectos mal reportados. Defectos que no dicen nada ( “No funciona!”); que no tiene sentido; que no dan suficiente información; que dan información errónea. Defectos que resultan ser error del usuario, problemas que son culpa de otro componente del programa; o que resultan ser un problema de red.
No es muy aconsejable contratar un equipo de testing que tenga los mismos perfiles. Crea un equipo con diferentes puntos fuertes, distintos unos de otros. Analiza apropiadamente los tipos de actividades de pruebas que vas a realizar, y en función de ello comienza a pensar en el tipo de gente que mejor se pueden adaptar a esas necesidades. Por ejemplo, es obvio que si queremos realizar pruebas de rendimiento necesitaremos incorporar en nuestro equipo a una persona con experiencia en la utilización de herramientas de rendimiento y análisis de resultados. Si queremos automatizar, necesitaremos un experto en herramientas de automatización…
Lo que en principio puede parecer una afirmación bastante lógica no siempre es así. En muchas ocasiones son los propios desarrolladores o jefes de proyectos los que, “alegremente”, cierran defectos que no han sido verificados por testing. Un defecto marcado como “Arreglado” (Fixed-Ready to test), debe de ser siempre verificado por el equipo de testing. Si el defecto es “rechazado” por no ser considerado un defecto, el tester deberá de pedir más información sobre el defecto para así realmente verificar que no se trata de un defecto y estar de acuerdo con la decisión. Si el defecto es rechazado por ser considerado “duplicado”, el tester deberá verificar que efectivamente el defecto existe y que efectivamente está duplicado. En muchos proyectos los desarrolladores tienden a esconder los defectos refugiándose en que el defecto está duplicado.
Estoy trabajando en una empresa con productos (soluciones informáticas para la gestión de empresas) líderes en el mercado.
