En estos momentos soy preparando la certificación de ISTQB. En mi búsqueda de información por internet he encontrado los libros para la preparación de dos de los exámenes. Por un lado el de “Foundations” y por otro el “Advance”.

Yo los he comprado directamente en Amazon.co.uk, pero también lo podéis comprar directamente a la editorial que se llama rockynook.

Si estás pensado hacer algunos de los cursos que hay disponibles sobre el ISTQB, estos libros te pueden ser de mucha ayuda como información complementaria:

Software Testing Foundations

Una vez hecho el primer examen se puede acceder al avanzado. En “Amazon” podéis comprar los dos libros, este es el otro:

Software Test Engineer’s Handbook (Advance)

Ya está disponible el segundo número de la revista “te” (testing experience). Para los que aún no conoce esta revista debéis saber que es gratuita y te puedes subscribir y bajarte la revista en la web de testing experience.

En esta segunda entrega podréis encontrar artículos sobre “Requirements-Based Testing”, “Usabilidad”, “The value of testing to business” o “Rules-Based Design Reviews”. Revista totalmente recomendable, no dudeis en subscribiros!!!!!!!!!!!!!

He leído muchos artículos y foros que discuten sobre si un Software Quality Engineer (SQE) tiene que sabe programar o no. La respuesta podría ser “depende”, pero mi respuesta a esta respuesta es ¿porque no?. En la universidad aprendí varios lenguajes de programación, y actualmente tengo mucho interés en PHP y Python…pero, ¿esto significa que soy un experto? Por supuesto que no, pero al menos un SQE tiene que tener unas mínimas nociones y conocimientos de programación.

Realmente, de una forma u otra seguramente tendrás que enfrentarte a algún proyecto en el que los conocimientos de programación sean requeridos. Por ejemplo, si paticipas en un proyecto de automatización deberás saber programar….o un proyecto de pruebas de rendimiento (será necesario que utilices alguna de las herramientas que están en el mercado).

Tal vez no haya mucho debate y todos estemos de acuerdo que es necesario que un SQE tenga conocimientos de programación, pero espero vuestras opiniones!!!!!!

Saludos

Debido a que durante el desarrollo de cualquier producto software se identifican un gran número de defectos, en muchos casos de alta prioridad o prioridad crítica, un equipo para la revisión de defectos (Defects Review Team) es esencial en cualquier equipo de testing.

Un DRT (Defects Review Team) proporciona una rápida y eficiente respuesta a un defecto en cualquiera de nuestros entornos y garantiza una oportuna solución. El equipo estará integrado por los siguientes miembros:

• Responsable del equipo de desarrollo (Development team leader).
• Jefe de proyecto (Project manager).
• Responsable del equipo de pruebas (QA team lead).
• Cliente (Opcional). Es importante que el cliente forme parte de este equipo, aunque no siempre es posible su participación.

Read more

El Plan de pruebas describe la estrategia, recursos y planificación de nuestras pruebas. Esta estrategia incluye la definición del tipo de pruebas a realizar para cada iteración, la cobertura y objetivos…en definitiva, el test plan representa el proceso de pruebas. Es importante detallar lo que está dentro del “scope” de las pruebas y lo que no se testeará.

La función principal del Test Plan es ayudarnos en la realización de las pruebas…por ello debe al menos incluir:

• Definir objetivos de las pruebas.
• Definir de los elementos que se van a probar.
• Enfoque o estrategia que se usará.
• Recursos y planificación necesarios.

Adjunto una plantilla que he obtenido de la “IEEE” que os puede servir como ejemplo. A partir de ella podreís crear vuestra propia plantilla que se adapte a las necesidades de vuestra empresa.

Test Plan Template

He querido recopilar algunos libros muy interesantes sobre software Testing que no deben faltar en vuestra biblioteca:

• Software Testing Techniques, 2nd Ed. Boris Beizer.
• The Art of Software Testing Glenford J. Myers, 1979
• The Complete Guide to Software Testing Bill Hetzel, 1988
• How to Break Software: A Practical Guide to Testing James A. Whittaker, 2003
• Black-Box Testing: Techniques for Functional Testing of Software and Systems Boris Beizer, 1995
• Software Testing: A Craftsman’s Approach, 2nd Ed. Paul Jorgensen, 2002
• How to Break Software Security James A. Whittaker, 2002
• Effective Software Testing: 50 Specific Ways to Improve Your Testing Elfriede Dustin, 2002
• The Craft of Software Testing: Subsystem testing Including Object based and Object oriented testing Brian Marick, 1995 Read more

Como norma general, cualquier aplicación debe probarse a fondo. Lamentablemente, en la práctica, las prueba son insuficientes y a menudo pasadas por alto.

Las pruebas de regresión intentan verificar que los cambios realizados no han introducidos nuevos defectos y que el resto de la aplicación sigue funcionando correctamente.

¿Como podemos realizar correctamente nuestra pruebas de regresión? Podemos comenzar analizando nuestras necesidades y definiendo una estrategia. Es importante que nuestra estrategia defina los pasos que debemos seguir a la hora de seleccionar los test que vamos a ejecutar. Podríamos pensar que debemos ejecutar todos, pero en muchas ocasiones esto no es posible por lo ajustado de las planificaciones. Es por ello que debemos hacer una selección, una batería de pruebas. ¿Que debemos considerar para hacer una buena selección?

Read more

Siempre he escribo sobre las diferentes conferencias sobre calidad de software que hay en nuestro país. La verdad es que creo que hay grandes conferencias a las que asisten importantes personalidades del sector a nivel mundial, como Scott Barber (USA), Michael Bolton (USA), Lee Copelan (USA), John A. Fodeh (DEN)…

Si no recuerdo mal la última conferencia que se hizo en Barcelona fue en Junio del 2003, en aquella época las jornadas eran organizadas por al ati (asociación de técnicos informático) y un grupo de empresas locales. Creo recordar que eran las VIII jornadas de innovación y calidad de software. Otras ciudades como Madrid, Bilbao, Valencia…celebran anualmente sus jornadas sobre calidad de software. Expoqa celebra este año su 5ª edición, Valencia también ha organizado cinco, Bilbao siete años…

Creo que una ciudad como Barcelona merece tener su propia conferencia internacional, la cual agrupe a los mejores especialistas del sector…¿para cuando habrá una conferencia?

Nota: hubo un “Taller sobre Pruebas en Ingeniería del Software” en Sitges en el 2006, organizado por PRIS, pero cada año se organiza en una ciudad diferente (este año se celebra en Gijón)…

Nos encontramos con una aplicación donde las pruebas son una cadena consecutiva de pasos. como toda cadena, todo eslabón debe estar intacto, de lo contrario se pierde la naturaleza como tal de la cadena.

Probar cada paso representa una carga de trabajo considerable en horas/hombre. Entonces, surge la idea de distribuir el trabajo entre varios de los testers. Pero el problema no se resuelve, ya que “apriori” el tester B debe esperar (o duplicar trabajo) a que el tester A termine sus pruebas (entiéndase que A probará el eslabón de la cadena inmediatamente anterior al eslabón que B probará). Sólo un dato más: Hay que hacer un montaje (creación de datos de pruebas en las BBDD) previo al inicio de las pruebas.

Read more

Curso sobre “Rapid Software Testing” impartido por Michael Bolton del 16 al 18 de Junio del 2008 en Barcelona. Un año más Expoqa y Sogeti traen a uno de los mayores expertos mundiales en Exploratory Testing a Barcelona. Si queréis más información sobre el contenido de curso podéis acceder directamente a Expoqa.com…allí también podréis apuntaros al curso.

Michael Bolton es uno de los gurus en el mundo del testing con más de 15 años de experiencia en el sector. Es, junto con James Bach, el autor de “Rapid Software Testing”. Este curso es totalmente recomendable, no dudes en asistir si tenéis la oportunidad.

Michael Bolton és el co-autor (junto con James Bach autor principal) del curso sobre Rapid Software Testing, un curso que presenta una metodología y una disposición para el testing de software en situaciones con planificaciones ajustadas e incertidumbre.