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

Availability & Reliability Testing


Availability & Reliability Testing

Reliability Testing is to test how your system stand with the usual scenario run over the period of time say 10 days. This scenarios are basically are day in a life situations. How your system will be utilize in a day with number of users in the system all the time.

Availability can be defined in terms of High Availability and Enhanced Availability. In these testing we introduce the failure and see how the system copes with those failures and in how much time system will be back live. The important thing is about the data loss prevention can be ruled out using these scenarios.

The iPhone SDK package has some kinds of such of these testing tools

Test Strategy & Test Plan

 Index

·         Test Plan

·         Test Strategy

·         Testing Environment

o  IT Environment

o  Equipment Environment

o  Data Analysis

o  Backup Database

o  Restore Database

·         Procedures

o  Problem Identification

o   Defect Rectification

o  Re-testing

o  Sign-off testing activities

·         Sign-off Testing

Test Strategy

Project Name

Overview

Testing stage Instructions:

Identify the type of testing to be undertaken.

Example:

User Acceptance Testing

Boundary value analysis of a button


Occasionally it may be difficult to even identify looping structures, especially when designing tests from only a black box test design approach. For example, in Window Xp a known defect appeared to allow a device name (LPT1, CON, etc.) as the base file name if the extension was appended to the base filename component in the Filename edit control (I'll talk more about this defect  later.) A Windows Xp patch attempted to correct this defect; however classic boundary analysis testing easily revealed the defect was only partially fixed as illustrated in the steps below.

1. Launch Notepad
2. Select the File -> Save menu item.
3. In the Filename edit control on the Save dialog enter "LPT1.txt" (without the quotes).
4. Press the Save button
5. Press the Yes button on the error dialog that states the file already exists and asks "Do you want to replace it?' As illustrated below,

What is Bugzilla?

Bugzilla is a bug tracking system developed at mozilla.org.

How do enter a bug in Bugzilla?

To enter a bug, through "Enter a new bug" link from the main Bugzilla page. This will take you to a product selection screen.

What happens once enter a bug?

After you enter a bug, mail is sent both to you and the QA department. A member of the QA department will verify that they can reproduce your bug.

How do search a bug?

To search a bug, through "Query" link from the main Bugzilla page.

How do submit a patch?