Testing your code before releasing to QA

Question

I have heard developers say that people who write code should not be the ones testing it. I am looking for peoples experience in this situation. Many times I have done my share of development, then released to the QA dept and had the code sent back to me becuase some aspect of the application was broken due to my coding, regardless of how much I had tested it prior to QA release.

Does anyone on this board have a process to follow, that enables them to throughly test their code before releasing to QA?

Answer 1

A developer should test the code to the extent of the specs that were given. What happens more often than not is that specs may be unclear or misinterpreted, and that is sorted out by someone else doing QA, which usually means the ones that gave the developer the specs verify that the implementation does what it was supposed to do, and if not that is the time when the mismatches are found and sent back for fixing.

Answer 2

A developer should ALWAYS test their code to their own satisfaction that it works as they expect it to work.

The QA team is there to test as an end user would and do/find the things that the developer just didn't think of.

Answer 3

My rule of thumb is a Unit Test for every method that returns a value. Once you're all green, it goes to QA.

Yes, QA is probably still going to find defects. Their job is to think of, and test, situations you didn't consider, after all. In general, I don't think it would be probable, and certainly not usual, to have code go straight through QA with no problems on the first iteration (excepting bug fixes and very minor changes).

Answer 4

re: "I have heard developers say that people who write code should not be the ones testing it. "

If they don't test it, how do they know if it works or not? The real answer is, "people who write code should not be the only ones testing it". It is true that as developers, we have blind spots with regard to our own code ("I know I didn't touch that code, so no need to test it...") and need help.

Ideally, there should be a unit test for every testable unit. Developers who write these units typically write the unit tests but it doesn't have to be that way. But unit testing is only part of the story. Testing professionals should be used to do integration and system level testing.

Answer 5

1) Yes, as a developer you need to write lots of unit tests. These will help you catch bugs earlier in the cycle before releasing it to your QA team.

2) Yes, as a development team, you will need to do system integration tests as well to ensure your component does not break other existing functionalities.

Answer 6

Developers normally work from the inside outwards, with a focus on the code:

• Assertions - verify data flow and structures
• Debugger - verify code flow and data
• Static analyzer - verify coding standards and find known errors
• Unit testing - verify each function
• Integration testing - verify sub-systems
• System testing - verify functionality
• Regression tests - verify defects stay fixed
• Security tests - verify system can't be penetrated easily.

Testers, on the other hand, normally work from the outside inwards, with a focus on the features:

• Acceptance tests - verify end-user requirements
• Scenario tests - verify real-world situations
• Global tests - verify feasible inputs
• Regression tests - verify defects stay fixed
• Usability tests - verify that system is easy to use
• Security tests - verify system can't be penetrated easily
• Code coverage - testing untouched code
• Compatibility - with previous releases
• Looking for quirks and rough edges.

End-users generally work from the outside fairly randomly:

• Acceptance tests - verify end-user requirements
• Scenario tests - verify real-world situations
• Usability tests - verify that system is easy to use
• Looking for quirks and rough edges.