10 Rules of Software Testing

REMEMBER SOFTWARE TESTING 10 RULES:

1. Test early and test often.
2. Integrate the application development and testing life cycles. You’ll get better results and you won’t have to mediate between two armed camps in your IT shop.
3. Formalize a testing methodology; you’ll test everything the same way and you’ll get uniform results.
4. Develop a comprehensive test plan; it forms the basis for the testing methodology.
5. Use both static and dynamic testing.
6. Define your expected results.
7. Understand the business reason behind the application. You’ll write a better application and better testing scripts.
8. Use multiple levels and types of testing (regression, systems, integration, stress and load).
9. Review and inspect the work, it will lower costs.
10. Don’t let your programmers check their own work; they’ll miss their own errors.

Software Testing @ glance

Steps to perform software testing: 

• Understand requirements and business logic
• Determine required standards and processes
• Set priorities, and determine scope and limitations of tests
• Determine test approaches and methods
• Determine test environment, test ware, test input data requirements
• Set milestones and prepare test plan document
• Write test cases
• Have needed reviews/inspections/approvals of test cases
• Set up test environment
• Execute test cases
• Evaluate and report results
• Bug Tracking and fixing
• Retesting or regression testing if needed
• Update test plans, test cases, test results, tractability matrix etc.

 

Components of a Bug Report: 

• Application name
• The function, module, name
• Bug ID
• Bug reporting date
• Status
• Test case ID
• Bug description
• Steps needed to reproduce the bug
• Names and/or descriptions of file/data/messages/etc. used in test
• Snapshot that would be helpful in finding the cause of the problem
• Severity estimate
• Was the bug reproducible?
• Name of tester
• Description of problem cause (filled by developers)
• Description of fix (filled by developers)
• Code section/file/module/class/method that was fixed (filled by developers)
• Date of fix (filled by developers)
• Date of retest or regression testing
• Any remarks or comments

Web based applications testing guidelines:

Apart from functionality consider the following:

• What are the expected loads on the server and what kind of performance is expected on the client side?
• Who is the target audience?
• Will down time for server and content maintenance / upgrades be allowed?
• What kinds of security will be required and what is it expected to do?
• How reliable are the site's Internet / intranet connections required to be?
• How do the internet / intranet affect backup system or redundant connection requirements and testing?
• What variations will be allowed for targeted browsers?
• Will there be any standards or requirements for page appearance and / or graphics throughout a site or parts of a site?
• How will internal and external links be validated and updated?
• How are browser caching and variations in browser option settings?
• How are flash, applets, java scripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?

From the usability point of view consider the following:

• Pages should be 3-5 screens longer.
• The page layouts and design elements should be consistent throughout the application / web site.
• Pages should be as browser-independent or generate based on the browser-type.
• There should be no dead-end pages. A link to a contact person or organization should be included on each page.