How do you scope, organize, and execute a test project?

[U]A. INPUTS TO START TESTING[/U]
Documents Needed:
[LIST][*]Test Plan[*]SRS / SDS[*]Test Cases[/LIST]

[U]B. Initially assure that the application was successfully passed out through the basic functional testing and working properly in various platforms and browsers.[/U]
Some basic guidelines to do so are -
[LIST][*]Identify most frequently used functionality to test and check it with valid data[*]Identify most critical functionality to test and check it with valid data[*]Identify the functionality that may cause probable system crash and check it with valid data[*]Check for errors in calculation or display of incorrect data in reports [*]While inserting the data into database, check for the proper insertion of data in relevant columns.[*]On form load, check whether all the fields of updating forms are initially displaying respective values or not [*]Check the content of critical pages match what is supposed to be there [*]Check whether all dynamically generated content like customized links are working properly or not[/LIST]

[U]C.If the application failed as per the guidelines listed in ‘B’, handover it to product development for renovation.[/U]

[U]D.If the application passed the basic functional testing, try to uncover the errors as many as possible by using under mentioned General guidelines.[/U]

General Guidelines

[LIST][*]Check for spelling mistakes and proper alignments of form fields.[*]Check for any inconsistency in usage of words or names for form fields in various interfaces (includes label captions, Titles, error messages, help and other screens) For example: the word Business can be mentioned as trade or commerce in various forms [*]Check the Tab order of the form fields [*] [INDENT]Check that focus is set to an object, which makes sense according to the function of the window/dialog box.[*] Check that tabs are placed horizontally across the top[/INDENT][*]Check for consistency in usage of fonts, colors, alignments in various forms. [*]Check for consistency in size, position & caption of the buttons on the pages. [*]Check for relevant label captions for the corresponding form field values. [*]Check for proper titles for windows or forms[*]Check for global acceptance of date / Time field validations. [*]Check the usage & appropriate display of standard error messages in the application[*]Check whether the formats for fields such as currency, date etc are followed properly or not.[*]Check whether the currency fields are right aligned or not[*]While testing the report pages, check whether correct data is displayed in relevant columns or not.[*]By clicking on each link, reassure the proper working of all links. Also check for the simplicity in navigational structure, so that user can understand properly[*]Check for the provision of certain values in applications such as default values given in the form fields, default selection of frequently used values in combo boxes or checked in check boxes / option buttons etc, which makes the applications easy to use[*]Check whether the application interface in all / selected screen resolutions is displayed properly or not[*]Write suggestions for ease of use in user point of view[*]Check the usage of company Standard validation.js file for form field validations.[*]Guidelines for regression testing in addition to the above [*] [INDENT]Check the affect of change on other parts of the application [*] Check the data presented to the user is accurate enough[/INDENT][/LIST][LIST=1][/LIST]

[U]E.Criteria to Pass / Suspend / Resume Testing.[/U]

[U]Pass Criteria[/U]
[LIST=1][*]The actual output from an action should be identical to the expected output specified by a test case.[*]All processes should execute with no unexpected errors.[*]All processes should finish update/execution in an acceptable amount of time based on benchmarks provided by the business analysts and documented by the development team.[/LIST]
Note:
[LIST=1][*]If a test case fails, it should not be assumed that the code is defective. A failure can only be interpreted as a difference between expected results, which is derived from project documentation, and actual results. Always there is a possibility of incorrect expected results, due to misinterpretation and incomplete/inaccurate project documentation.[*]After conducting a post test review meeting, actual bugs should be identified and categorized.[/LIST]

[U]Suspension Criteria[/U]

If any of the following occurs on a given build, the system test team may suspend testing activities fully or partially:
[LIST][*]Files are missing from the new build.[*]The development team cannot install the new build or a component.[*]The development team cannot configure the build or a component.[*]There is a fault with a feature that prevents its testing.[*]Item does not contain the specified change(s).[*]A severe problem has occurred that does not allow testing to continue.[*]Development has not corrected the problem(s) that previously suspended testing.[*]A new version of the software is available to test[/LIST].

[U]Resumption Requirements[/U]
[LIST][*]Clean the previous code from machines and Re-install the item.[*]Correct the problem encountered to avoid suspension [*]Get a new build from development team via Visual Source Safe, with a list of all bugs fixed and changes made in the new version.[/LIST]

[U]F.Severity and Priority Classification[/U]

[U]Severity [/U]
Low - Minor flaw not affecting operation or understanding of feature

Medium - is usable, but some functionality is lost or user may misinterpret and use improperly

High - Important functionality is lost or feature is not usable, but there is a work-around or feature is not critical to the operations

Critical - Important feature is not useable. Emergency fix is authorized

[U]Priority [/U]
[U]Low[/U] Correct in next scheduled enhancement release or update documentation and do not fix

[U]Medium[/U] Fix after high priority defects and enhancements. Document work-around or affect on users

[U]High [/U] Fix within 72 working hours, stop work on enhancements, if necessary

[U]Emergency[/U] Fix ASAP, within 12 hours; overtime authorized; skip full acceptance testing, if necessary. Don’t go home until fixed.