The main work of the QA is to make sure that the product works perfectly well (or at least, with a minimum quality). QA people have to find the greatest number of problems with the product, incoherences, compatibility bugs, typos, …. and once they found them, they should make sure the bugs have dissapeared in the next release/build, and no longer appear.
Reporting a bug is fundamental to improve software. The problem is that if the people who reports the bug, only says something like:
- It does not work.
- It crashes when I click on save button
- The text does not bold
- …
As a developer these messages above say nothing to me.
From my experience as a developer, reporting a bug is VERY EASY. The bug description should answer simply, to the following questions:
- What’s the bug?
Explain what’s the problem, and remember that sometimes an image is worth a thousand words; screenshots help!
- How the bug is reproduced?
Once a problem has been detected, you should reproduce it. Once you reproduce it, you can write the steps for reproducing it. If necessary, start with “Open the application”.
The best way to explain how the bug is reproduced is by doing a list of steps clearly defined.
Remember to attach any file or data needed in order to reproduce the problem. - What’s the version affected by the bug?
Is really important to specify the program version in which the bug manifests (include the build number).
In order to reproduce the bug, it’s very important that the programmer knows exactly in which version of the program the bug is happening, because sometimes in the last build a bug may not reproduce, but this does not means that the bug has been solved.
If the program connects to a server, it’s also important to supply the version in which the server was running.
- What’s the expected behaviour? (opcional)
Sometimes is not enough to explain what the problem is. Sometimes it’s important to say what was the expected behaviour. Obviously if the application crashes while trying to do some kind of computation, the expected result would be doing that computation without the application crashing. But other times, if for example, the bug is “The color of the object is wrong” because when you click on “Change Color” with a blue color selected, and the object becomes black, then the expected result will be “The object should become blue”.
Is not always needed, of course, but sometimes it helps the person who is reading the bug description. - In which version of the OS / in which hardware occurs? (opcional)
Sometimes the software only crashes or fails under specific operating systems or specific hardware (Intel/NVIDIA card/ATI Card/…)
Often when the bug is reported and the programmer closes or returns the bug as “cannot reproduce”, it’s because the bug is missing some information, we are not recreating the circumstances that make the bug reproduce.
In web development for example, the equivalent of OS and Hardware will be Browser and OS.
To sum up, the gold rule for QAs:
“Make the developer be able to reproduce the bug in HIS computer wihout any help”
Español
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!).
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.
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”