views:

165

answers:

3

At work, we have a pre-QA step where we (the developers) would test each other's work (broken up to individual bugs or enhancements). While this is useful to have (good to have a sort of 'double check' to make sure failures from QA are kept to a minimum; also useful to look at the stuff that other people have been doing); it has always bugged me that I'm essentially replicating the work that a QA tester would do after me (except that the tester is probably more thorough).

Note that I'm not talking about a code review, essentially we run through the changes from a functionality point of view.

Am I currently doing it right (i.e. doing a quick QA test)? Does anyone have any suggestions as to how this could be done more effectively?

+2  A: 

lookup Test Driven Development (TDD), that should send you in the right direction

KevinDTimm
+3  A: 

Looks like unit testing and code reviewing through unit testing. I think the developer should do that, for me the QA job is more for validation than verification.

They should take care of more high level tests, IMO.

Augusto Radtke
+1  A: 

Does QA have access to the code? If not then you are looking for the edge cases they may not see or bet able to recreate. What are the limits of their tools?

  • Can you find any race conditions.
  • What happens when that Long value overflows.

When I was in QA I wrote up a bug that required playing through a game to a particular tournament, took about 16 hours by hand...problem was we where getting builds faster than that :) and who has 16 hours to find/regression test one bug?

Paxic