Guidelines on Testing

Different types of testing :

Black box testing - not based on any knowledge of internal design or code. Tests are based on requirements and functionality.
White box testing - based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions.

Unit testing: the most 'micro' scale of testing; to test particular functions or code modules.
Integration testing - Testing of combined parts of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server
Functional testing - Black-box type testing geared to functional requirements of an application; This type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.)

Regression testing - re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing. Load Testing
Acceptance testing - final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.

Load testing - testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.
Recovery testing - testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
Security testing - testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques

Alpha testing - testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.

Beta testing - testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.
What's a 'test plan”?

A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The following are some of the items that might be included in a test plan, depending on the particular project:
• Title
• Objective of testing effort
• Software product overview
• Relevant related document list, other test plans, etc.
• Relevant standards or legal requirements
• Overall software project organization and personnel/contact-info/responsibilties
• Testing priorities and focus
• Scope and limitations of testing
• Test outline - a test approach by test type, feature, functionality, module, etc. as applicable
• Test environment validity analysis - differences between the test and production systems and their impact on test validity.
• Test tools to be used, including versions, patches, etc.
• Test script/test code maintenance processes and version control
• Problem tracking and resolution - tools and processes
• Reporting requirements and testing deliverables
• Software entrance and exit criteria
• Test site/location

What's a 'test case'?
• A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.


What should be done after a bug is found?
The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems

What steps are needed to develop and run software tests?
• Obtain requirements, functional design, and internal design specifications and other necessary documents.
• Determine project-related personnel and their responsibilities, reporting requirements, required standards and processes
• Identify application's higher-risk aspects, set priorities, and determine scope and limitations of tests
• Determine test approaches and methods - unit, integration, functional, system, load, usability tests, etc.
• Determine testware requirements(bug tracking, etc.)
• Determine test input data requirements
• Identify tasks, those responsible for tasks, and labor requirements
• Set schedule estimates, timelines, milestones
• Prepare test plan document and have needed reviews/approvals
• Write test cases
• Have needed reviews/inspections/approvals of test cases
• obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, Obtain and install software releases
• Perform tests
• Evaluate and report results
• Track problems/bugs and fixes
• Retest as needed
• Maintain and update test plans, test cases, test environment, and testware through life cycle

How to Enter Bug – Registry
• Complete information such that developers can understand the bug, get an idea of it’s severity, and reproduce it if necessary.
• Current bug status
• The application name
• The function, module, feature, object, screen, etc. where the bug occurred
• Full bug description
• Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy access to the test case
• File or the data that would be helpful in finding the cause of the problem
• Tester name
• Test date
• Bug reporting date
• Name of developer/group/organization the problem is assigned to
• Description of problem cause
• Description of fix
• Date of fix
• Retest date
• Retest results
• Regression testing results

A reporting or tracking process should enable notification of appropriate personnel at various stages. For instance, testers need to know when retesting is needed, developers need to know when bugs are found and how to get the needed information, and reporting/summary capabilities are needed for managers.

Note: Tester has to check-in the Bug Registry at the end of the day and must see to that all the bugs recorded in the registry is debugged