Manso advice: How to report bugs

WireframeWhen designing desktop apps, websites, and mobile applications, more than once I have tried using an application like mockingbird or Pencil Project. On one hand, mockingbird, is a web application that can be accessed from any browser and allows you to design multiple pages with different elements. On the other hand, Pencil Project, initially born as a Firefox extension, now has a multiplatform desktop application that allows you to mockup easily.

The drawback I see on these two applications is that for some reason, I always end up making simple mockups with a simple pen and paper. This way I can organize my ideas faster than using these applications. I guess the main reason for this is that I’m not a designer, so to me it is the same doing a shitty design in paper, than a shitty design with an application. Moreover, usually using a computer app for this task I end up spending more time to do the same…

Anyway, the other day I discovered, and the truth is that I was quite impressed by the UI. It is super-easy and fast to use. You just drag the mouse while clicking and voila, you have an item of the size of your selection. You click on the type of item you want and you are done with the item. Even if you want to change attributes, you just have to double click on it, and select the attributes you want to change.

Actually, it is the first time I feel that I do not waste my time doing mockups with an application of this kind. From what I’ve seen, this application is starting, and it still lacks of some functionalities and needs some polishment, but I suppose that those will be added in the future. Even I think this lack of complexity and lack of tons of box types is what makes you go faster.

I think choosing the right tool for a job is a matter of personal preferences and personal needs, but I would recommend trying and taking a look at the other apps I pointed out at the beginning of the post.

Feel free to share any other tool you find useful in the comments 😉

Trackback URL

, , ,

  1. Juanjo
    15/10/2009 at 12:04 am Permalink

    En realidad eso que comentas es QC (control de calidad, así en castellano), más que QA (‘aseguramiento de la calidad’ ?¿).

    QA es más profundo que hacer solo testing, creeme 😀

    Normalmente se usan sistemas para tickets o seguimiento de bugs que ya refuerzan lo que explicas en esta anotación, porque lamentablemente la gente que hace testing no siempre tiene los conocimientos adecuados (a veces ni conocen el producto!).

  2. Ivan
    16/10/2009 at 11:14 am Permalink

    A mi lo que más me llama la atención es eso del “resultado esperado”. Antes de empezar a trabajar con testers, no entendia la utilidad de ese “resultado esperado”. Luego lo entendí plenamente: ¡¡esperan cosas muy raras!! 🙂

    En serio, a veces desde determinados departamentos de test parece que quieren imponer como ha de ser el producto y creo que no es algo que les corresponda.

  3. Pau Sanchez
    16/10/2009 at 8:53 pm Permalink

    @Juanjo si es Control de Calidad en español, porque las siglas no son CC? Puestos a que haya una Q, prefiero hacerlo todo en inglés, estoy acostumbrado ya a QA 🙂

    @Ivan coincido en que no son ellos a los que les corresponde decidir como se debe comportar el producto (sobretodo si hay PRD de por medio), sin embargo, si se pone el comportamiento esperado, pueden pasar una de estas cosas:
    – El comentario no aporta nada
    – El comentario ayuda al desarrollador a entender el problema
    – El desarrollador estaba en un error, y lo ha implementado mal
    – El QA está en un error y no es un bug

    La ventaja que le veo a poner cual es el comportamiento esperado, es para ayudar al desarrollador a ver el problema, y sobretodo en los casos en los que o bien el desarrollador o el QA estén en un error. Si por ejemplo el QA está en un error, y resulta que el bug no es un bug, pues se acaba la historia enseguida “Not a bug, it’s a feature” 😉