Eres de los que le gusta probar todas las versiones de Firefox?

Alguna vez has pensado en hacerte betatester de Mozilla?

Te gusta buscar fallos de seguridad en nuevas versiones de software?

Si alguna de las respuestas es SI, Mozilla te puede pagar por ello.

Para ello Mozilla ha creado el “bug-bounty”, us sistema a traves del cual una persona que encuentre un fallo de seguridad crítico en el sistema podrá llevarse una cantidad de 3000 $ y lo más importante, una camisa de Mozilla.

Logicamente para que puedas recibir esa cantidad, el bug ha de ser considerado como critico y que afecta a la seguridad de sus productos y aparte seguir una serie de condiciones:

  • El bug encontrado debe ser original y no encontrado anteriormente
  • Debe ser un “remote exploit”
  • Debe estar presente en la mayoria de las versiones recientes (betas o releases candidate) de Firefox, Firefox mobile, Thunderbird o otros productos de Mozilla Corporation.
  • No pueden ser causados por software 3rd-party
  • No pueden ser ninguna de las personas que han desarrollado esa parte del código o los empleados de Mozilla.
  • Si el bug es reportado por varias personas simultaneamente se repartiran los 3000 $.

Si queréis más información podéis leer las clausulas y el resto de detalles aquí.

Tagged with:  

Un nuevo planeta ha llegado: The Testing Planet

On 27 julio, 2010, in Revistas, by twiindan

The Software Testing Club han publicado el segundo número de su revista.

En esta ocasión han realizado un profundo lavado de cara en muchos aspectos ya que se ha cambiado totalmente el formato (ahora se parece más a un periódico que a una revista) y también le han cambiado el nombre a “The Testing Planet”.

La versión en PDF es gratuita y se puede descargar desde este enlace.

Si queréis tener la versión impresa, tiene un coste de 6 libras (unos 8 euros aproximadamente) y podéis realizar la compra desde aquí.

Espero que disfrutéis de una buena lectura.

Tagged with:  

La Real Federación Española de fútbol ha publicado en su página web oficial el calendario oficial para la temporada 2010/2011 un día antes que se realizará el sorteo oficial (se realizará mañana).

Según la federación no se había percatado del error y comentan que el sorteo se celebrará de forma oficial durante el día de mañana por lo que los datos publicados no tienen niguna validez.

Parece ser que el problema ha venido causado por un error informático ya que se estaba gestionando la presentación del nuevo calendario de la Liga 2010/2011 con un nuevo programa de gestión de contenidos.

Este es un ejemplo de una mala gestión de los entornos de prueba en una aplicación web, o seguramente de un mal uso de la nueva herramienta de gestión de contenidos por parte de los desarrolladores web. Siempre que debamos realizar una serie de pruebas antes de lanzar una aplicación o en este caso una página web se han de realizar en un entorno de pruebas y nunca en un entorno de producción para que no se produzcan errores como el ocurrido.

Por si alguien tiene curiosidad, según el calendario el Barcelona-Real Madrid se jugaría el 7 de Noviembre y la vuelta el 30 de Marzo.

Tagged with:  

ISTQB Foundation Certified!

On 16 julio, 2010, in Certificación, by twiindan

Ayer día 15 de Julio, me presente al examen de ISTQB Foundation Level con un resultado de aprobado!

El examen constaba de 40 preguntas multirespuesta con una sola opción válida y sin restar los fallos. para aprovar el examén hay que acertar un mínimo del 65 % de las preguntas (26 de 40).

Para preparar el examen aconsejo utilizar el syllabus oficial del ISTQB y el libro “Foundations of Software Testing: ISTQB Certification” Dorothy Graham y Erik van Veenendaal. Podéis comprarlo en Amazon aquí.

A parte podéis utilizar también los examenes de muestra que os comente hace unos días en el siguiente post.

Mucha suerte para los futuros testers!

Tagged with:  

Tienes algo que decir?

On 13 julio, 2010, in Conferencias, by twiindan

Tienes algo que decir? Este es el lema de la nueva campaña de EUROSTAR    2010.

EUROSTAR intenta crear una gran comunidad de testers y por eso lanzan un reto a todos los que nos gusta escribir en nuestro blog cosas sobre testing. Para ello ha creado un divertido reto para ver quien es el blogger más popular en la comunidad de EUROSTAR.

Para ello has de registrarte enviando el nombre y una pequeña biografia a Siobhan@eurostarconferences.com antes del 25 de Agosto.

La lista con todos los bloggers se publicara el día 30 de Agosto, y tendrán hasta el 15 de Octubre para realizar una pequeña batalla entre ellos mediante creatividad y contenidos.

Del 15 al 22 de Octubre los lectores de BlogStar deberán votar cual ha sido para ellos el mejor Blog de todos.

Lo mejor de todo, el premio:

Un viaje con todos los gastos pagados a EUROSTAR 2010, incluyendo el vuelo, transporte desde el aeropuerto, alojamiento para 4 noches, un ticket para la cena de gala y 500 € para las comidas y el champagne.

La verdad que es una muy buena suculenta oferta, así que ya sabes, si te has quedado con ganas de ir a EUROSTAR 2010 en Cophenague está es una ocasión única para conseguir unas entradas y todos los gastos pagados!

Más Información en la comunidad de Eurostar.

Tagged with:  

Principios Generales de Testing

On 6 julio, 2010, in Consejos, Definiciones, by twiindan

Actualmente estoy estudiando para realizar la certificación del ISTQB Foundation y en el primer tema existe un apartado donde se indican muy bien los principales principios del testing.

  1. Testing shows presence of defects: El testing puede mostrar que existen defectos, pero no puede provar que no los haya si no que unicamente reduce la probabilidad de que queden defectos sin descubrir.
  2. Exhaustive testing is impossible: Testear todas las combinaciones y posibilidades es imposible, por ello se debe priorizar y realizar análisis de riesgos para enfocar los esfuerzos del equipo de test.
  3. Early testing: Las actividades de test deben lo antes posible en el ciclo de vida de desarrollo de software, enfocandolo en objetivos definidos.
  4. Defect clustering: Un pequeño número de módulos son los que contienen la mayor parte de los defectos descubiertos antes de realizar una release.
  5. Pesticide Paradox: Por mucho que se repitan los mismos tests, no se van a encontrar más errores. Por ese motivo los test cases necesitan ser regularmente revisados y se deben ir añadiendo nuevos para probar las diferentes partes del software.
  6. Testing is context dependent: Los procesos y las metodologías de test aplicadas deben ser diferentes según el contexto.
  7. Absence  of errors fallacy: Encontrar y arreglar defectos no ayuda si el sistema no es usable o no concuerda con las necesidades y expectativas del testing.

Estáis de acuerdo con todos los principios? La verdad que es un buen resumen de las características principales del testing, unos principios que todos deberíamos aplicar siempre que podamos.

Tagged with:  

Testing Jokes

On 1 julio, 2010, in Jokes, by twiindan

El poder reirse de nuestro trabajo es esencial en algunos casos para no acabar subiendote por las paredes, por eso os dejo una serie de diferencias entre los puntos de vista de un desarrollador y de un tester.

Optimistic Developer: The glass is half full
Pessimistic Tester: The glass is twice as big as required

Optimistic Developer: This code hasn’t yet been tested. It’s not known if it has any bugs.
Pessimistic Tester: This code hasn’t yet been tested. It’s not known if it works.

Optimistic Developer: We are 90% done.
Pessimistic Tester: We don’t know when we’ll be done, if ever

Optimistic Developer: We will refactor the code to make it better
Pessimistic Tester: They are throwing out the working code and replacing it with an unknown quantity

Optimistic Developer: I only changed one line of code
Pessimistic Tester: The entire system must be retested

Optimistic Developer: The code is the design
Pessimistic Tester: There is no design

Optimistic Developer: We’ll fix those bugs later, when we have time
Pessimistic Tester: We never have enough time to fix the bugs

Optimistic Developer: This build is feature complete
Pessimistic Tester: The features exist; some are completely broken

Optimistic Developer: Anything is possible, given enough time
Pessimistic Tester: Everything has flaws, and given enough time I can prove it

Optimistic Developer: Of course it will work
Pessimistic Tester: It might work, but probably won’t

Optimistic Developer: One last bug fix, and we can ship tomorrow
Pessimistic Tester: Fixing this one bug will likely lead to two more

Optimistic Developer: Stop finding bugs, or we’ll never be done
Pessimistic Tester: Stop creating bugs, so I can find them all

Optimistic Developer: There’s no need for more tests
Pessimistic Tester: Let’s just run a few more tests to be sure

Optimistic Developer: There is no I in TEAM
Pessimistic Tester: We can’t spell BUGS without U

Optimistic Developer: That’s an “undocumented feature”
Pessimistic Tester: That’s a bug

Optimistic Developer: I like to build things
Pessimistic Tester: I like to break things

Optimistic Developer: Sure, we can use the Beta version of this component in Production
Pessimistic Tester: We should wait until version 2.1

Sabéis de alguno más?

Fuente original by Joe Strazzere.

Tagged with: