Typically, the web application pen test effort is directed toward the identification of common vulnerabilities in the application. These vulnerabilities when found through a pen test mostly consists in security issues such as configuration management, session management, input and output validation, data protection and encryption, error handling, authorization and authentication, auditing and logging. The scope (i.e. target) for the "external" penetration tests (also called ethical hacks or web application vulnerability assessments) typically do not include the security assessments of the infrastructure (e.g. servers, proxies, firewalls etc) that are not externally accessible by the tester. As part of the pen tests, testers might look at web server vulnerabilities that can be found externally such as non-safe web server configuration (e.g. default admin files not disabled, HTTP methods such as TRACE not disabled, admin ports open, non required services, weak SSL, expired certs etc etc). Besides common web application vulnerabilities, testers might also try to test the application for specific threats previously identified with a threat analysis during the development of the application such as threat modeling. For new applications, pen tests can be integrated during the Software Development LifeCycle as part of the security tests performed in the application testing environment (e.g. User Acceptance Tests or Integrated System Tests) during the verification phase of the SDLC. Such security tests (e.g. black box tests) integrate ethical hacking test cases (e.g. for malicious inputs) with functional test cases (e.g. testing expected functionality of security controls). This is for the general cases, for the specific that relates to each application and/or organization, my suggestion is to discuss the testing objectives and requirements with the project stakeholders. Security testing requirements should be captured in a security testing plan. If your organization does not have a test plan for security you can start by identifying the security requirements by looking to the company security policy and the information security standards. The testing methodology should capture how to test for these security requirements besides the common vulnerabilities and specific threat scenarios. This should be part of the security testing guideline. A good one when you start from zero is the OWASP testing guide http://www.owasp.org/index.php/Penetration_Testing.