Testing Techniques

Testing is a cornerstone activity of a product development process. Testing is one of the activities used to verify that a design generates the correct outputs for a defined set of inputs and to validate a design as meeting its requirements and providing adequate fitness for use. Testing is important in all product and system development, but in software development, lack of a strong development process and/or design methodology can promote testing to the principal activity for finding and removing design and implementational defects (other activities that remove defects include good design methodologies, design reviews, and code inspections). What constitutes a good test plan, and when should I do this planning? How do I ensure that I'm doing adequate testing without going overboard? In software testing, what is the difference between "statement coverage" and "logic coverage"? How can automation help me in achieving good test coverage? Is there any value in early testing, or should I wait until the design is mature? What is the difference between black box and white box testing, and how do I apply them? What is glass box testing? Can developers really do complete testing of their own code? Every time I run tests on my emerging design, the results generate lots of bugs and issues -- how do I know if my design is converging on its requirements? How can I measure the overall effectiveness of my testing in order to justify what I spend on it to my management? How can I use these measures to improve my testing process? Are there any tools that can help me do this? What is the best way to keep track of bugs and issues that my testing is uncovering? Testing web site software seems to have special challenges, to say the least -- where can I go for help in this area?

• PAPER: This overview of Software Unit Testing -- contributed by Rodney Parkin, Technical Director of IV&V Australia Pty Ltd -- defines the practice, as well as issues to consider when building unit testing into your overall plan.
  
  
• TEMPLATE: Reduce overall development time and costs by finding and fixing errors before they get lost in the end-to-end tests. Our Software Unit Test Plan and Report Guidelines include an overview of unit testing, step-by-step process guidelines, and sample documents for creating your own formal testing procedures, which can then be used for reliability testing by third parties as well as in-house resources.
  
  
• TEMPLATE: Our Software Test Transfer template includes practical forms to accompany a software build when Development sends it Testing, to serve as a record of what is being transferred, testing instructions, and ultimately a record of what was tested and the results.
  
  
• TEMPLATE: Our Customer Acceptance Checklist and Signoff template provides a checklist format for customer to use while walking through a review and test of a pre-release system, for example before going through with a purchase. Allows customer to record issues, indicate which must be resolved before acceptance, and ultimately sign off on accepting the new system.
  
  
• TEMPLATE: The User Acceptance Test Plan provides an annotated outline for testing to be executed by users of a system or application prior to the production-level build and deployment. User Acceptance Testing (UAT) is the formal means for ensuring that a new system or application actually meets the essential user requirements. The plan includes sections such as scope of testing, test team, training needed, and a testing timeline to ensure that this critical activity is planned for and executed thoroughly.
  
  
• ARTICLES: The Software Testing & Quality Engineering journal is a source of articles and product information on software testing.
  
  
• BOOKS: We've collected some helpful references on testing in our book collection.
  
  
• CHECKLIST: The Software Integration Checklist gives the project manager or software integration team leader a way to analyze, plan, communicate and execute the Integration Phase of a large or complex software project, or a project combining hardware and software. This checklist highlights considerations that the project manager or integration team leader can use to minimize risks and delays inherent to the Integration Phase.
  
  
• TEMPLATE: Software Release Life Cycle Phase 6: Integration covers documents and activities needed to get all the parts, projects, sub-projects, modules, libraries, packages, etc. that are part of the release working together for the first time as a cohesive system. The focus is on the testing interfaces between the various software entities.
  
  
• TEMPLATE: Software Release Life Cycle Phase 7: System Test covers documents, reports and activities needed while executing a series of tests with the primary purpose of fully exercising the software release being created.
  
  
• TEMPLATE: Software Release Life Cycle Phase 8: Internal Testing defines testing and review activities to run a software release through its final paces internally before being exposed to an external customer.
  
  
• TEMPLATE: Software Release Life Cycle Phase 9: External Testing defines testing and review activities to exercise a software release in a "real world" environment at one or more customers.
  
  
• TEMPLATE: Our Beta Test Plan provides an annotated outline for a full beta test plan document, testing that is often critical for exercising the product, service, or system in a way that cannot be duplicated in a controlled environment; and getting customer and end user reaction to the functions and features.
  
  
• TEMPLATE: The Master Test List template provides a tabular format for listing the tests to be run during a testing cycle (such as Beta, System test etc.), with a place to categorize and describe each test, provide pass-fail criteria, indicate the planned run day or week; and log pass-fail test results.