AITS - Quality Assurance Testing

Requests for Accessibility, Automation, Functional, Performance, and Vulnerability testing.
Status
The status of the ticket. This indicates where the ticket is in its lifecycle.
New

Contact Information

Request Details

A short description to explain the nature of this request.
What type of testing is required?
What type of testing is required?
Common name for this application
Name used in the CMDB for this application, if different than the common name.
Who develops and supports this application?
Who develops and supports this application?
Is this application already in production?
Is this application already in production?
Please provide details of the testing needed including anything that is in or out of scope for this project.
Press Alt + 0 within the editor to access accessibility instructions, or press Alt + F10 to access the menu.
What devices should be used for testing?
What devices should be used for testing?
Accessibility Questions
Use cases will be needed before accessibility testing can begin. They can be attached to this request or provided separately.
Which campus or University location will be using the application?
Which campus or University location will be using the application?
Which audience(s) will be using the application?
Which audience(s) will be using the application?
How many people are going to use the application?
How many people are going to use the application?
How many people will use reports or other output (charts, graphs, etc) from the application?
How many people will use reports or other output (charts, graphs, etc) from the application?
Is this testing request in response to a complaint or a request from a campus ADA Coordinator?
Is this testing request in response to a complaint or a request from a campus ADA Coordinator?
Is there an Alternative Access Plan for this application? (If So, Please Attach It)
Is there an Alternative Access Plan for this application? (If So, Please Attach It)
If you have a current VPAT or ACR (Accessibility Conformance Report) review, please attach it below.
Automated Questions
Once your request has been assigned to a tester, a meeting will be scheduled to discuss automated testing options.
Functional Testing Note
Once your request has been assigned to a tester, an application walk through will be scheduled. If test cases or documentation is available, please attach it to this request.
Performance Questions
If test cases or documentation is available, please attach it to this request.
Performance tests can be simple or complex depending on what exactly is being tested. Please explain in detail what type of testing is needed.
If database access is needed, please provide details. For the most accurate testing results, QA should have exclusive use of the database during testing. If others are changing records during testing this could impact expected test cases.
Will each user perform the same task or different tasks? Are there users with different types of access? Please explain or attach a document explaining steps to be taken by each user.
Making a good estimate of application usage is often the most difficult part of testing. Worst case scenarios can be useful and QA can push almost any system to the breaking point – but this is not a good predictor of general performance nor does it contribute meaningfully to the expected day-to-day impact on the production environment.

The best way to determine the number of users is by looking at actual usage of the application in production or the usage of an equivalent system. If possible create estimates from these sources.
Consider if all users can use the same login ID or if each user will need a separate ID. Determine if the application will allow multiple logins or if we need an ID for each user. Attach a list of available login IDs to the request.
Test applications are rarely run on the same hardware as production. The amount of usage is usually discounted to account for this difference.
It is important to establish what level of performance is acceptable before testing begins. The Acceptance Criteria consists of a list of the maximum time that each user action should take. For Banner the acceptance criteria is set contractually at 15 seconds for login – 5 seconds for all other actions. Other applications may take longer or shorter times and different actions may have different expected times.
Vulnerability Questions
Select the data classification that best describes this application.
High Risk – Extreme risks associated with unauthorized disclosure (costs > $1 million) Ex. Health data, banking information, social security number, drivers license number, export control, data associated with legal cases, federally classified data. Example: Personal Health Information (HIPAA), Credit Card Information (PCI-DSS), Personal Data (PIPA)

Sensitive – Large risks associated with unauthorized disclosure (costs > $100,000) Example: Student records, employee personal information, NDA’s, Network diagrams

Internal – Risk that could result in reputational damage to the university, loss of competitive advantage and higher costs for university business processes. Example: Unpublished Research Data, Intellectual Property

Public – The application accesses no highly sensitive data, sensitive data, or internal data. Publicly accessible web pages

For more information about data classifications please visit: https://cybersecurity.uillinois.edu/data_classi...
Select the data classification that best describes this application.
What is the user base for this application?
What is the user base for this application?
Does this application have active content (User input including forms, data queries, updates, web posts, etc.)
Does this application have active content (User input including forms, data queries, updates, web posts, etc.)
What is the network scope for this application?
What is the network scope for this application?
File attachments associated with the ticket.
Browse...

Other Fields

Your name
Verification Code