How you go about testing your code depends on the programming philosophy you are following - Extreme Programmers will, for example, run tests on their code pretty much every working day, whereas more structured plans will plan testing time into the schedule at regular intervals.
Because PHP is an interpreted language, you can run tests on individual scripts simply by executing them - any execution errors will be reported back immediately. If you would rather not execute your scripts again and again, use the "lint" mode of the PHP CLI SAPI by typing php -l yourscript.php from the command prompt. Users on Windows will need to change directory to where they placed PHP and into the "cli" directory. Note that linting your script only returns syntax errors - execution errors, such as treating an integer variable as an array, are not reported.
You can also lint your script from within PHP by using the php_check_syntax() function, which takes a filename as its first parameter, and an optional variable passed by reference as its second parameter. If the script has no problem, true will be returned and the variable will be empty. If the script does have problems, false will be returned, and the variable will filled with the first error message that was encountered. This is a lot slower than using the CLI directly, as you have to work through each error one at a time, however it is the only option if you do not have the CLI to hand and don't want to execute the script.
As well as linting and running your scripts, you should also try going through entire scenarios as part of your tests. If you have the resources, a member of your team should spend some time creating test cases for each part of your system that involve complete, standalone transactions that can be performed such as "Adding a user", "Editing a message", etc. For each major test build that is made, a team of testers (depending on the size of your project) can simply work through the tests, checking them off as they go.