Screen Validation Checklist  - Alpha Field Checks

• Use blank and non-blank data
• Include lowest and highest values
• Include invalid characters & symbols
• Include valid characters
• Include data items with first position blank
• Include data items with last position blank

Screen Validation Checklist  - Numeric Fields

• Assure that lowest and highest values are handled correctly
• Assure that invalid values are logged and reported
• Assure that valid values are handles by the correct procedure
• Assure that numeric fields with a blank in position 1 are processed or reported as an error
• Assure that fields with a blank in the last position are processed or reported as an error an error

Screen Validation Checklist  - Date Field Checks

• Assure that leap years are validated correctly & do not cause errors/miscalculations
• Assure that month code 00 and 13 are validated correctly & do not cause errors/miscalculations
• Assure that 00 and 13 are reported as errors
• Assure that day values 00 and 32 are validated correctly & do not cause errors/miscalculations
• Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations
• Assure that Feb. 30 is reported as an error
• Assure that century change is validated correctly & does not cause errors/ miscalculations
• Assure that out of cycle dates are validated correctly & do not cause errors/miscalculations

Screen Validation Checklist  - General Conditions

1. Assure the existence of the "Help" menu.
2. Assure that the proper commands and options are in each menu.
3. Assure that all buttons on all tool bars have a corresponding key commands.
4. Assure that each menu command has an alternative(hot-key) key sequence which will invoke it where appropriate.
5. In drop down list boxes, ensure that the names are not abbreviations / cut short
6. In drop down list boxes, assure that the list and each entry in the list can be accessed via appropriate key / hot key combinations.
7. Ensure that duplicate hot keys do not exist on each screen

Screen Validation Checklist  - Modes (Editable Read-only) Conditions

1. Are the screen and field colours adjusted correctly for read-only mode?
2. Should a read-only mode be provided for this screen?
3. Are all fields and controls disabled in read-only mode?
4. Can the screen be accessed from the previous screen/menu/toolbar in read-only mode?
5. Can all screens available from this screen be accessed in read-only mode?
6. Check that no validation is performed in read-only mode.

Screen Validation Checklist  - Data Integrity Conditions

1. Is the data saved when the window is closed by double clicking on the close box?
2. Check the maximum field lengths to ensure that there are no truncated characters?
3. Where the database requires a value (other than null) then this should be defaulted into fields. The user must either enter an alternative valid value or leave the default value intact.
4. Check maximum and minimum field values for numeric fields?
5. If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?

Screen Validation Checklist  - Usability Conditions

1. Are all the dropdowns on this screen sorted correctly? Alphabetic sorting is the default unless otherwise specified.
2. Is all date entry required in the correct format?
3. Have all pushbuttons on the screen been given appropriate Shortcut keys?
4. Do the Shortcut keys work correctly?
5. Have the menu options which apply to your screen got fast keys associated and should they have?
6. Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.

Screen Validation Checklist  - Navigation Conditions

1. Can the screen be accessed correctly from the menu?
2. Can the screen be accessed correctly from the toolbar?
3. Can the screen be accessed correctly by double clicking on a list control on the previous screen?
4. Can all screens accessible via buttons on this screen be accessed correctly?
5. Can all screens accessible by double clicking on a list control be accessed correctly?
6. Is the screen modal. i.e. Is the user prevented from accessing other functions when this screen is active and is this correct?
7. Can a number of instances of this screen be opened at the same time and is this correct? 

Screen Validation Checklist  - Validation Conditions

1. Does a failure of validation on every field cause a sensible user error message?
2. Is the user required to fix entries which have failed validation tests?
3. Have any fields got multiple validation rules and if so are all rules being applied?
4. If the user enters an invalid value and clicks on the OK button (i.e. does not TAB off the field) is the invalid entry identified and highlighted correctly with an error message.?
5. Is validation consistently applied at screen level unless specifically required at field level?

Screen Validation Checklist - Aesthetic Conditions

1. Is the general screen background the correct colour?
2. Are the field prompts the correct colour?
3. Are the field backgrounds the correct colour?
4. In read-only mode, are the field prompts the correct colour?
5. In read-only mode, are the field backgrounds the correct colour?
6. Are all the screen prompts specified in the correct screen font?
7. Is the text in all fields specified in the correct screen font?

Release Management

Release Management considerations

Instructions:

One of the major risks in testing is not having a proper Release Management Procedure. The same program is modified by two people at the same time, and only one modification gets into production. It is important to put in place a proper release management process.

Example:

“Prior to any testing being undertaken, a complete and documented Release Management facility must be in place.

Test Management Software

Instructions:

Identify any software that will be used to manage the testing. This includes the organization of the activities to be tested, and the management of defects. Date ranges between 1990 and 2010 can be used.

Example:

We will use "Test Manager" to manage the testing. Both the test team and applications development will have access and be able to update the status of defects.

SQL Injection Attacks – How to Test Web Applications

Security testing of web applications against SQL Injection, explained with simple examples - By Inder P Singh.

Many applications use some type of a database. An application under test might have a user interface that accepts user input that is used to perform the following tasks:
1.    Show the relevant stored data to the user e.g. the application checks the credentials of the user using the log in information entered by the user and exposes only the relevant functionality and data to the user

Change Driven Risk Management

What is CDRM?

Change Driven Risk Management (CDRM) is a technical framework to assess and manage risk over the project lifecycle.  Utilising a spreadsheet-based tool, CDRM informs the relationship between change and risk mitigation methods as a customised Checklist.
It is part of the bank's testing compliance process and must be completed by the Project Management and Test Management communities within Technology Services during project Commence.

Operational Acceptance Testing (OAT)

The purpose of OAT is to prove the aspects of the system that do not affect the functionality but can still have a profound effect on how it is managed and supported.
OAT concentrates on areas such as resiliency, recoverability, integrity, manageability and supportability, with the specific exclusions of Performance, Security and Disaster Recovery, which are areas of speciality in their own right.

The required level of OAT is determined by using CDRM (Change Driven Risk Management) and the output from this will recommend the risk mitigation strategy for all phases of the project. This will enable the OAT phase to focus on mitigating the operational risks.

The following mitigation methods form the OAT phase:

• Backup & Recovery
• Change Implementation

HP - QTP