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

Here are some ideas for making sure your code works from the point of view of completing a task. I wouldn't recommend doing each of these rigorously for every tiny task, but rather use the following as a checklist to give you ideas. Different tasks call for different amounts of checking.

Before starting actual programming:

• Create initial test cases
• Estimate what might break

While coding:

• Autocomplete symbol names
• Highlight symbol names to check they are the same
• Type calmly to avoid typos
• Code small amounts at a time
• Ask your peers
• Engage in pair programming
• Note down more test cases
• Estimate further what might break
• Use good OOD and clean code
• Understand the code
• Leave the code be for some time (days) and come back to review it
• Run diffs for persistant data to make sure it changes appropriately
• Syntax checker to check errors
• Syntax checker to avoid malpractices and enforce coding standard
• Unit tests
• Automatic functional tests
• Manual functional tests
• Output validation

Before committing:

• Update working copy and run all tests and validations
• Debugger run
• Spell checking
• Diff comparison what has changed
• Peer review
• Estimate what might break

Integration server

• Syntax checkers
• Automatic tests and validations
• Smoke test
• Peer review notification

Release to QA:

• Run tests in the staging area
• Validate output
• Notify QA of completion of the task and send the estimates of the breakage

Some of these can be automated to be done on every save on the file being edited. Usually I map at least an error checking syntax linter to run when saving the file.

Answer 2

The developer tests her code to make sure that the code performs the way the developer thinks it should perform.

The QA team tests the code to make sure that the code performs the way the QA team thinks they read in the documentation.

The QA team doesn't just test the code. The QA team tests the effectiveness of the communication between the interested parties (clients, developers, QA, management, etc.).

Answer 3

As a developer you can test your code upto some extent like :

• Unit Testing once the modules are bulit completely
• Integration Testing after the integration of two or more modules is done.

System Testing can also be done upto some extent. The main work QA does is that he finds out the user requirements and can check the system accordingly. Also the QA used to check the code practically due to which more and more bugs can be found out.

Also User Acceptance Testing can be done by QA in more systematic way as they are having some idea of what user actually wants. It is said that "Third person can find out more mistakes from your code than you". Hence QA is must even if developers test their code thoroughly.

Answer 4

Interesting question. I'll try to give you a good overview from a testers point of view.

If I get a build I'd be expecting the code to be tested at a unit test level to check some of the basics. This means that when I enter some basic boundary value checks it doesn't fall over. For example: If a field accepts 0-100 then it should gracefully handle 101 and -1.

That's a simple example. I think when people say you shouln't test your own code they are refering to the traditional testing phase normally done by trained testers. That doesn't mean it shouldn't be tested at a unit level though. I also advocate testing it manually also, even just to check that it performs the basics.

When I code I write unit tests, integration tests (if possible) and definately manually test it for basics. The problem though is that testing code I've written is never as effective as someone else testing it. I have assumptions and ideas about the code that might mean I skip or ignore bits. I may assume too much. Take too much for granted. Think I know what the code does. A pro tester will avoid these assumptions and hence often find defects you may not find.

A good tester will also check edge cases, usability and whole host of interesting areas.

There was one comment left here that the specs might be vague and hence tricky to write tests from. But as a tester I would also suggest that doesn't that make coding it tricky too?

In my experience it is well worth pairing a dev and tester together to write unit tests. It's an amazing sight and the breadth of coverage is often excellent.

Cheers Rob..