Writing Quality Software – Quality Assurance

One must not underestimate the necessity of the QA team.
Quality Assurance (QA), the guys that test the software designed by the engineers and written by the developers. Their mission is to make sure that the software does what it needs to do, and do it well. They are also the first users of the software so they have the best review and criticism about the visual design and usability.
A developer needs to learn to listen to the QA team notes. The QA team, on the other hand, must learn how to note.
In order to really understand this, lets check things more thoroughly:
First of all, the role of the QA team versus the role of the development team in terms of software operability:
No QA team – Bad software; No development team – No software.
That said, we now need understand that the two teams must work together in order to create good software.
Alas, those two teams are meant to work as rivals, as the QA must constantly critic the products of the developers, in order to find flaws, and the developers must fix the flaws and prevent new flaws from being introduced.
This is a real fight between the two teams, and not once you hear both sides places the blame on the other doing a bad job, wasting everybody else’s time, etc. While this is not true, this is often the feeling, especially if the organization isn’t done right.
So, how can the two teams work together?
First, developers tend to fix problems presented to them when these are clear enough, and reject or ignore them when these are unclear. Also, a repeated claim, especially if not clear enough, rejects the average developer even more.
This is why a tester must learn how to file a bug report. This is the key to good tester-developer relationship.
A bug report must contain a very clear, short as possible list of steps that reproduce a bug. THE BUG MUST BE REPRODUCABLE UNDER ANY TERMS. This means that a bug that could not be reproduced, actually does not exist.
Reproducing a bug is an art by itself. Finding the minimal set of operations that yields a bug to reveal. You think you had found it? Think again. Try to do things differently, see if it still happens. Omit steps. If you can’t make an educated guess, make some uneducated guesses. After that – call a developer who might know how things work on the inside, and direct you to a more simple way to reproduce it.
Now, dear QA guys, please understand – The only people who have anything to do with your bug reports are us, the developers. Not your team leader, not your boss, not even the client. Only the developers. And it is very very frustrating for us not to understand what you have written, because, you see, we really do want to make the software we had written better. It is our reputation on the line.
Since developers are the only people who have anything to do with bug reports (the most important product of the QA team), I believe (and some would not agree, for some unclear reason) that the QA team should be placed next to the development team, under the development manager.
Yes, that’s right. There is no reason for a QA team to stand by itself, as the developers are those who need to use the QA products in order to fix their software. The managers can’t fix it. The client can’t fix it. Only the developers can fix it.
According to the size of the organization and the nature of the project, the QA-DEV relationship nature should be defined. Small company, with small development team and small QA team – consult each other a lot by speaking to each other. Don’t go and file bug reports just like that, and don’t go and write the same pieces of code after given a bad critic. Consult. For bigger companies – bug reports are the only way to go, but make sure everything is written correctly, everything can be understood by the relevant developer (or by anyone, for that matter), everything reproduces. Write the relevant version number in the bug report. Don’t attach error logs – these should be reproduced next time that bug occurs anyhow, so instead, make sure all the steps are clear, and that there are no redundant steps.
This is my two cents philosophy of quality assurance. Please try to put it to good use.