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

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 2

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 3

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 4

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 5

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 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.

Answer 7

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 8

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..

Answer 9

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

Version control with continuous integration:

• 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.