When should development stop and QA begin?

Question

We write a complete functional specification for our development team of two. We do not have professional testers however we have drafted in the help of our available helpdesk personnel to perform 'QA testing'.

We have had problems in the past where complete chunks of functionality do not work, or the code is delivered is simply not according to the spec.

My questions are: at what stage should developers stop coding at hand over to the QA team? Is it too much to ask the developers to review their code against the spec before handing over to the QA team?

Answer 1

It shouldn't!

It is very hard to do all the work, stop, and then fix all the issues. When you go to fix an issue you find during the QA process, you may learn that it would be better to do something differently.

Instead of thinking of everything as a lock-step process, try to make it more cyclical. Code some functionality and test it. Code some more and test it (and the old things still work). This more fluid process alleviates the hard ship of trying to front load everything. You can still have the concept of a code freeze (just fix bugs) when you get close to the deadline, but the point is to test early and often.

Answer 2

Well, if entire sections of code are being handed over to QA in a non-working state, perhaps you should look into adding some sort of unit/integration testing to your process. Don't abuse your QA people by making them find out that you failed to unit or integration test your code.

Answer 3

It's a fine line, because if the code is delivered according to spec then to me that means there are not bugs (and no need for QA!). The fact that code is routinely not delivered to spec is the reason why we do QA in the first place.

But I don't actually think that's what you're talking about. What you mean is that the dev team seems a bit too lazy with their coding, and there are big obvious things that don't seem to work. Laying out before hand that unit tests need to be present for each of features A, B, and C (in the spec) and then having code and tests reviewed independently (by a team lean or manager) should help to alleviate this sort of problem.

Answer 4

I would argue that at the very least, the developers should have tested the "happy path." That if they enter expected data then it does what the spec says it should do. Developers who don't do that much should be questioned.

I am also disappointed if a developer hasn't tested the obvious edge cases: a string too long for the database, obviously invalid text, if you enter letters where a number should be, etc. If that happens often, again questions should be asked.

However, assuming it isn't specifically mentioned in the spec, if a developer limits a name to just upper- and lower-case letters, but forgets that some names have apostrophes, or allows a date of 29th Feb 2011 - that's slightly more understandable. Unless they're making the same mistake time after time.

The QA team should be picking up the extreme edge cases. I prefer QA to be monkey-testers: just entering random garbage, seeing if they can break the app that way.

In web development, QA should try different browsers and try to find plugins that might affect the code. They should switch Javascript and CSS off and see what they can get away with then. That kind of thing. If you expect the developers to do that, you're spending too much money on it.

Answer 5

If functionality is being delivered that doesn't work, then the problem is not between development and QA, but between development and the product owners.

Product owners and developers should be part of the same team, and should work together to define what needs to work to consider a feature "done", and to make sure that the code meets that need.

When code is delivered, testing should be a mere formality, because the product owners should have been working with the developers along the way to make sure that all the use cases are covered.

(If you have professional testers, they should be part of the team, and should be involved at every stage.)

Answer 6

We have a screening process for projects where we ask the developers to give a walkthrough/demo of their code before it comes into QA. We include not only the QA testers, but the business owner(s) of the code, customer service, and marketing/design. This tends to focus on the developers on at least the easy use cases, and sometimes the resulting discussion between the various teams results in changes to specs and a delay in entry into QA. When we can, we involve QA much earlier in the process, which helps get bugs fixed while the code is still warm -- but we still do the walkthrough before "official" QA starts.

I sometimes have said that code should not be submitted to QA if you'd be upset if it mistakenly went to production instead of QA. Code with major dysfunctionality does not belong in QA (except in specific circumstances)