What developer testing needs to be done before passing a build to the QA team?
As a developer my knowledge of best QA practises, etc., are limited to know just enough to get me by writing unit tests, etc. From a tester's point of view, what testing procedures should the developer ideally have gone through before signing off a project to the QA team to be tested? Obviously this will vary based on what development methodology is in place, so different answers based on different methodologies would be fantastic. I don't want to step on any toes but at the same time I don't want to be passing over completely untested code.
Based on my first sentence, should I just sharpen up my knowledge in this field?
What has worked well for me regarding the developer testing is the following steps.
- The developer makes their best effort at writing good code.
- The developer gets a code-peer review from another developer
- The developer runs their unit tests, and checks that they all pass.
- The developer and the tester sit down for a review:
The developer walks through with the tester to let them know what is being delivered, any related changes and any areas that aren't finished yet so that bugs aren't logged in those areas. The tester runs through the tests that they have written for the feature . This allows the developer to review the tests and ensure that they make sense. The tester takes a few minutes to execute some high level test and walk through the feature with the developer. Any obvious bugs are fixed on the spot, without logging them in the system. With the review complete, the developer checks in The tester then formally tests the feature in the next day's daily build. Whilst on paper this may seem really onerous, we found it to be really effective in flushing out and fixing a lot of obvious issues really quickly and cheaply as we haven't touched the defect tracking system yet, and that saves everyone time in the long run.