Testing procedure:

• Verify that the "Wallets" section displays a list of all card accounts.
• Confirm that the list is consolidated and shows all cards owned by the user.
• Verify that I can assign a personalized name to a card.
• Check that the assigned card name is displayed correctly in the card list.
• Ensure that the status (active or blocked) of each card is accurately displayed.
• Test that status changes (e.g., blocking a card) are correctly reflected in real-time.
• Verify that the real-time balance of each card is displayed accurately.
• Confirm that balance updates in real-time, considering all transactions.
• Check that the transaction history of each card is accessible.
• Ensure that transaction details (purchases, payments, withdrawals) are correctly listed.
• Verify that transactions are categorized correctly (e.g., groceries, entertainment, bills).
• Confirm that spending summaries provide accurate insights into user's spending patterns.
• Confirm that transaction alerts can be set up for various activities.
• Trigger alerts for specific activities (e.g., large transactions) and verify that notifications are received.
• Check that I can lock and unlock cards through the app.
• Verify that the status change is immediate and accurately reflected in the card list.
• Ensure that I can customize notifications for low balance, large transactions, and bill due dates.
• Confirm that customized notifications are received when the specified conditions are met.
• Verify the overall responsiveness and performance of the "Wallets" feature, ensuring it loads quickly and functions smoothly.
• Test for security by ensuring that card data is appropriately protected, and no unauthorized access is possible.

As a customer, I want to receive proactive notifications for significant transactions, account activities, or security-related events through my preferred channels.

Acceptance Criteria:

• Notifications include relevant details like transaction amount and source.
• Notifications are sent through my preferred channels: email, SMS, or WebApp.
• Transactions notifications should be deliver immediately.
• News and special offers notifications are delivered in near real-time.

Testing procedure:

1. Verify that users can access the money transfer section from the main menu or dashboard.
2. Test the ability to select recipients (beneficiaries) from the user’s beneficiary list for money transfers.
3. Confirm that the application verifies recipient details (e.g., account number, beneficiary name) before proceeding with the transfer.
4. Test the ability to enter the transfer amount, ensuring it meets account balance and transaction limits.
5. Test various payment methods (e.g., NEFT, RTGS, IMPS) and ensure that the selected method is processed correctly.
6. Check the option to include a message or note with the money transfer (if supported).
7. Ensure that users are required to enter a valid PIN or receive and verify an OTP (One-Time Password) before completing the transfer.
8. Confirm that the transaction details are accurately recorded in the user’s transaction history.
9. Verify that the application enforces transaction limits and communicates these limits clearly to users.

Description

This test case verifies that the news page allows filtering news by tags and that clicking on a tag redirects to the news page with the appropriate tag filter

Precondition

The system is online and accessible. The news page has at least two posts with different tags

Input data

None

Test Steps

Expected Result

The news page allows filtering news by tags and clicking on a tag redirects to the news page with the appropriate tag filter

This is how the tester determines if the test case is a “pass” or “fail”

Requirements

#7

• Verify user's debts: If the user has outstanding debts, they should not be able to close the account until the debts are cleared.
• Add additional verification of the user's identity before closing the account: Implement an additional step, such as two-factor authentication or security questions, to ensure the person closing the account is the authorized user.
• Verify correct withdrawal of funds from the account: Ensure that all funds are withdrawn correctly, and there are no discrepancies in the withdrawal process.
• Verify that all automatic payments will be canceled: Confirm that all scheduled automatic payments linked to the account are successfully canceled to prevent any future transactions.
• Verify that the user was informed about all rules, limitations, and conditions associated with the procedure: Ensure that the user receives comprehensive information about the closure process, including any fees, waiting periods, or additional requirements.
• Verify unsubscribing from all notifications associated with the account: Confirm that the user is successfully unsubscribed from all notifications, including emails, SMS, or app notifications, related to the closed account.
• Verify if there are waiting periods for closing the account after submitting a request.
• Verify the system's response accuracy upon closing the account after the waiting period has elapsed (if applicable).

Security Testing

Tasks

• Verify that API is inaccessible from an unauthorized source
• Ensure only specific roles have access to specific API levels
  • Admin
    • Website health & performance data
    • Page/post visiting statistics
    • Everything below
  • Client
    • User account ID info
    • Money accounts info
    • Credit debts/loans info
    • Transaction logs
    • Services/utilities payment account info
    • Everything below
  • Bot
    • Read news posts
    • Retrieve terms of service
    • Retrieve service tariffs

Permission Management

The system allows users to have multiple roles assigned by default. However, some roles are incompatible with others (for example, no bot can have the admin permission level)

The table below describes roles and permission levels representing them (level numbers in-between are reserved for the future, just in case)

Decision table (compressed) the system should follow to prevent the assignation of incompatible roles

As a customer, I want to register a new account to access the functionality of a bank

Acceptance criteria:

• Website must validate address field
• Website must validate city
• Website must validate state
• Website must validate zip code
• Website must validate phone number
• Website must validate SSN
• Website must validate username
• Website must validate password
• After successful registration, the website has to open an account overview page
  • In case of data collision, the website must provide an error message and cancel the registration

As a customer, I want to use a chatbot to assist me in managing my account and getting information about various banking services.

Acceptance Criteria:

• Accessibility: The chatbot should be easily accessible on the bank's website, with a clear and prominent way to start a conversation.
• Greetings and Introduction: When I initiate a chat, the chatbot should provide a friendly greeting and introduce itself as the bank's virtual assistant.
• Account Information: I should be able to ask the chatbot for information about my account, including account balance, recent transactions, and statements. The chatbot should ensure the security of this information through authentication.
• Transactions: The chatbot should guide me through basic transactions, such as fund transfers, bill payments, and setting up recurring payments.
• Product and Service Information: I want the chatbot to provide information about the bank's products and services, including savings accounts, loans, credit cards, and their associated interest rates and fees.
• FAQs: The chatbot should be equipped with a database of frequently asked questions and their answers, allowing me to find quick solutions to common queries.
• Data Security and Privacy: The chatbot should assure me of the bank's commitment to data security and privacy, outlining how my personal and financial data will be protected.
• Feedback Collection: The chatbot should encourage me to provide feedback about my experience and have a mechanism for collecting and analyzing user feedback for continuous improvement.
• Multilingual Support: To cater to a diverse customer base, the chatbot should be capable of understanding and responding in multiple languages.
• Responsiveness: The chatbot should work seamlessly on both desktop and mobile devices, ensuring a consistent and user-friendly experience across platforms.
• Support and Assistance: If the chatbot is unable to address my request or if I need more personalized assistance, it should be able to seamlessly connect me with a human customer support agent or provide contact information for further assistance.

As a customer, I want to login to my account to access my funds and operations with them

Acceptance criteria:

• Customer has to be already registered in the system
• Website must validate login
• Website must validate password
• Website must hide password in the input field
• Website must open account overview after successful login
  • In case of invalid data website must show an error message and return to the login page

Environment

Client info

• Operating System: doesn't matter
• Browser: doesn't matter

Product Version: 0.1.0

Reproduction

Preconditions
You're unauthorized on the website

Steps to Reproduce

1. Open the website in incognito mode
2. Click on the ParaBANK logo

Postconditions
None

Behavior

✔️ Expected

The website requests authorization

❌ Actual

You gain access to the admin page being unauthorized

Requirements

User Story: #11
Test Case: #42

Decision Table Template

Here's a template of a decision table to copy/paste and fill

| Causes         | R1  | R2  | R3   | R4  |
| ------------- |:----:|:----:|:----:|:----:|
| ...                  | y     | y    | n     | n    |
| ...                  | y     | n    | y     | n    |
| **Effects**    |        |       |        |       |
| ...                  |        |       |        |       |
| Notices        | N1  | N2 |        |       |

> [!important]
>
> Explanation of notices
>
> - N1: ...
> - N2: ...

And here's what it looks like

As a customer, I want to be able to pay for my phone number bills through the bank's website:

Acceptance criteria:

• There should be a clearly labeled section or option within the website's interface for paying phone bills. It should be allowed in navigation or in "money transfer" panel;
• The system should support payments for a variety of local phone number providers or carriers commonly used within the country of residence;
• The most constantly used phone numbers should save in fast pick up panel;
• The user should have the option to choose from multiple payment methods (e.g., bank transfer, credit card, debit card) to pay the bill;
• After the payment is processed, the user should receive an on-screen confirmation of the successful transaction.
• If there are any errors during the payment process (e.g., incorrect phone number, insufficient funds), the system should display clear error messages guiding the user on how to proceed and offer call to emergency support.
• The system should maintain a record of the payment transaction in the user's account history section, accessible for future reference.

• Verify the presence of login and password validation on both the client and server sides.
• Verify the absence of the possibility to use special characters or SQL injections to bypass security systems.
• Verify the ability to use two-factor authentication to provide an additional layer of security.
• Verify the configuration of limitations on the number of incorrect login attempts.
• Verify the accuracy of account lockout messages after reaching the maximum number of incorrect login attempts.
• Verify the implementation of measures to protect against brute-force attacks, including limiting the password input speed and locking the account after a series of failed attempts.
• Verify the correctness of security certificate configurations and TLS protocols.
• Verify restricted access to administrative functions only for authorized personnel with appropriate privileges.
• Verify compliance with password requirements regarding length, complexity, and periodic password changes.

As an admin, I want to have a toolkit to manage the website and respond to potential issues

Acceptance criteria:

• Admin should be able to change basic website Appearance settings (change website title, update theme, update menu layout, add new posts to the news section, update page content)
• Admin page should have a separate User Accounts section (with the possibility to update the contact info and account details a user enters during registration)
• Website must provide a possibility to change website database endpoint, update database connection details, reconfigure database access driver easily, and update basic API connection details in the Connection section
• Admin should have access to the website health data, server performance info, API status, and page/post visiting stats in the Dashboard section

Description

This test ensures the validity and security of the backend checks for user input-related API requests to prevent wrong, inadequate, or malicious data from reaching the DB

Precondition

For making requests with forms in the web app

1. Frontend checks are disabled for testing
2. Any page with an input field for entering some data is opened
3. Input field is active

Input data

1. Whitespace characters and tabs except for the default space character
2. Whitespace at the beginning
3. Whitespace at the end
4. Multiple whitespace characters in the middle
5. Non-alphabet non-numeric characters, like ~!@#$%^&*()_+, 👍, or 💯
6. More than maximum amount of characters
7. SQL injections, for example: '; drop table users
8. HTML tags
9. Cross-site scripting vulnerabilities, or <script> tags

Test Steps

Expected Result

The form must not be submitted in any case

Requirements

#12

As a frontend developer, I want to create new features by using RESTful and SOAP API:

Acceptance criteria:

• Web application should send a GET request to the server to fetch transaction data for a specific user. This criteria includes the next functions: get an account of the specific user, get an ID of the user after successful authentification, get information of a user, transaction ID, date, amount, description, and so on.

• Web application should allow the user to manipulate his data and make POST requests to the server and get the correct response from one. The response from the server should be in XML format;

• Web Application should give the user functionality to modify user data locally in the frontend application. Upon making changes, I can send a POST request to the server to update the user's information.

• The POST and PATCH requests should include the modified data in XML format.

• After the server processes the request, I expect to receive a confirmation XML response indicating the success of the operation.

• If there are errors in the request (such as invalid data or missing parameters), the server should respond with an appropriate XML error message indicating the issue. The error message should provide clear information about the error, helping me understand what went wrong.

• The API endpoints should be secured, requiring proper authentication or authorization to access and modify user data. Any sensitive data sent via XML in the request should be encrypted to ensure security during transmission.

• The API should be well-documented, providing clear guidelines on the XML structure for requests and responses.

• Examples of valid XML requests and expected XML responses for different API endpoints should be provided in the documentation.

• The documentation should also include information on authentication methods and error handling procedures specific to XML requests and responses.

• Verify that the user can correctly choose the account type.
• Verify the user's ability to add funds to the account.
• Verify the user's ability to make transactions from the account.
• Verify the correct display of transaction history and the status of financial transactions.
• Verify the possibility of subscribing the user to notifications for the created account.
• Verify the possibility of restoring the account password.
• Verify the user's ability to close the account.
• Verify the user's ability to edit the ceiling of daily expenses.

Description

The registration form mandates accurate input in various fields: first name, last name, address, city, state, zip code, phone number, SSN, username, password, and confirmation. Pre-testing, the user must ensure an unregistered phone number, a unique email, stable internet, a compatible device, and awareness of the registration process. Inputs must adhere to specific length, character, and validation rules. After filling out the form, clicking submit should trigger server messages: success for accurate data and error for issues. Successful registration grants access to the user's bank page.

Precondition

1. The tester does not have their phone number registered in the bank's database.
2. The tester has a valid and unique email address that is not already associated with an existing account in the bank's system.
3. The tester has a stable internet connection to access the registration form.
4. The tester is using a compatible device and browser specified for the registration process.
5. The tester's device meets the minimum system requirements specified by the bank for accessing their online services.
6. The tester has the necessary information, such as personal details and identification documents, to complete the registration form accurately.
7. The tester is familiar with the registration process and understands the required fields and steps to create an account.
8. The tester has cleared their browser cache and cookies to avoid any interference from previous attempts.

Input data

Requirements for input data

Test Steps

Expected Result

If registration is successful, the tester will be authenticated and able to access their personal bank page; otherwise, he/she/they will receive a registration error.

Requirements

#5

As a customer, I would like to see all the news of the bank:

• News articles should be clearly separated into individual pages.
• Each page should be dedicated to a specific topic or category of news.
• Links to the news articles should be featured on the main news page, where they will be placed within frames. These frames should include a brief description of the news article and a headline that includes the publication date.
• In the main news frame, the newest articles should be highlighted, and they should represent various news categories.

Testing procedute:

• Verify that all mandatory fields are marked as such and cannot be left blank.
• Validate that the registration form accepts valid and unique email addresses.
• Validate that First Name, Last Name fields don't contain numbers.
• Validate that Zip Code consists of digits.
• Test if the registration page has proper validation for phone number formats.
• Validate that SSN consists of digits.
• Validate that username is unique.
• Test if the password field contains minimum amount of input sings.
• Check that the “Confirm Password” field matches the password entered.
• Test if the registration form displays the right error messages for invalid or wrong inputs.
• Verify that the registration form clears all fields after a successful registration.
• Test if the registration process allows users to enter special characters in fields where applicable.
• Validate that the form prevents registration with an already registered email address.
• Verify that a user receives a confirmation email upon the completion of a successful registration session.
• Test if the registration form supports different input formats, such as uppercase, lowercase, and mixed case.
• Validate if the registration form handles leading and trailing spaces appropriately.
• Test if the registration page has a “Terms and Conditions” checkbox that is marked as a mandatory field.
• Validate that the registration process has appropriate CAPTCHA to prevent spam registrations.
• Test if the registration form has a “Reset” or “Clear” button that clears all entered data.
• Test if the registration process includes encryption of sensitive user information.

As a customer, I want to have the ability to manipulate my card accounts

Acceptance criteria:

• I want to view all my cards in one consolidated list for easy access and management.
• Each card should have the option for naming, allowing me to assign a personalized name to easily identify the card's purpose or issuer.
• I should be able to see the current status of each card (e.g., active, blocked) to stay updated on its usability.
• The app should display the real-time balance of each card, ensuring I can monitor my funds accurately.
• Access to the transaction history of each card, enabling me to review past purchases, payments, and withdrawals.
• Provide insights into my spending patterns, categorizing transactions and displaying summaries to help me manage my finances better.
• Implement security features such as transaction alerts, allowing me to receive notifications for any card activity to prevent unauthorized usage.
• Include the ability to temporarily lock or unlock a card through the app, enhancing security and control over my accounts.
• Allow customization of notifications for low balance, large transactions, or bill due dates to keep me informed about my account status.

Application for testing: ParaBANK

Zoom meeting link

Navigation

Repository

• Issues
• New Issue

Project

Testing procedure:

• Accessibility: Test if the chatbot is easily accessible on the bank's website. Ensure that the chat icon or button is visible and clickable.
• Greetings and Introduction: Start a conversation with the chatbot to verify that it provides a friendly greeting and introduces itself as the bank's virtual assistant.
• Account Information: Test the chatbot's ability to provide account information. Authenticate with the chatbot and request details like account balance, recent transactions, and statements.
• Transactions: Verify that the chatbot can guide you through transactions, such as fund transfers, bill payments, and setting up recurring payments. Check for proper transaction confirmation and security measures.
• Product and Service Information: Ask the chatbot for information about various banking products and services. Ensure it provides details on savings accounts, loans, credit cards, and associated interest rates and fees.
• FAQs: Ask common banking-related questions to test if the chatbot can provide accurate and relevant answers from its database of frequently asked questions.
• Data Security and Privacy: Inquire about data security and privacy to ensure the chatbot can articulate the bank's commitment to safeguarding personal and financial data.
• Feedback Collection: Check if the chatbot encourages you to provide feedback about your experience and whether it has a mechanism for collecting and analyzing user feedback.
• Multilingual Support: Test the chatbot's ability to understand and respond in different languages. Verify that it can switch between languages upon request.
• Responsiveness: Use both desktop and mobile devices to interact with the chatbot. Ensure a consistent and user-friendly experience across platforms.
• Support and Assistance: Test scenarios where the chatbot is unable to address your request or when you need human assistance. Verify that the chatbot can seamlessly connect you with a human customer support agent or provide contact information for further assistance.

Verify if a user will be able to login with a valid username and valid password. - Positive
Verify if a user cannot login with a valid username and an invalid password. - Negative
Verify the login page for both, when the field is blank and "Log in" button is clicked. | Negative
Verify the ‘Forgot Password’ functionality. | Positive
Verify the messages for invalid login. | Positive
Verify the ‘Remember Me’ functionality. | Positive
Verify if the data in password field is either visible as asterisk or bullet signs. | Positive
Verify if a user is able to login with a new password only after he/she has changed the password. | Positive
Verify if the login page allows to log in simultaneously with different credentials in a different browser. | Positive
Verify if the ‘Enter’ key of the keyboard is working correctly on the login page. | Positive
Other Test Cases
Verify the time taken to log in with a valid username and password. | Performance & Positive Testing
Verify if the font, text color, and color coding of the Login page is as per the standard. | UI Testing & Positive Testing
Verify if there is a ‘Cancel’ button available to erase the entered text. | Usability Testing
Verify the login page and all its controls in different browsers

Functional Testing

Precondition: registered user with the Admin role

Tasks

• Verify access to the admin page
• Verify switching between Appearance, User Accounts, Connection, and Dashboard sections is working
• Verify states and content of all the fields, inputs, and checkboxes in every section correspond to their values in config files and DB (ensure reading settings and applying of those to control fields on the admin page is working)
• Verify updating website settings
  • Appearance section
    • Change website title
    • Update theme
    • Update menu layout
    • Add new posts to the news section
    • Update page content
  • User Accounts section
    • Add new account
    • Update existing account details
    • Remove account
    • Ban user by IP/MAC-address
  • Connection section
    • Change website database endpoint
    • Update database connection details
    • Reconfigure database access driver
    • Update basic API connection details
  • Dashboard section
    • Check website health data for displaying server performance data in real-time
    • Check website visiting stats are collected by visiting the website from multiple devices

Date and Time

October 24, 2023, 14:18

Severity

Minor

Priority

Medium

Environment:

OS: Microsoft Windows 10, 64-bit
Browser: Google Chrome (Version 118.0.5993.89)
Reproducible: Always
Build Found: Production

Preconditions

Steps to Reproduce

Actual Result

Get message about succeful operation

Expected Result

These actions should trigger an error

Screenshots

Tasks

• Verify post abstracts are displayed chronologically (newest first) on the news page
• Verify Read more links are working properly
• Verify navigation between posts (previous/next post buttons)
• Verify filtering news by tags
  • Click on a tag on the news page applies filters so only posts with this tag are displayed
  • Click on a tag redirects to the news page with the appropriate tag filter

User-Stories-ATM.pdf

As a customer, I want to have access to information about bank
Acceptance criteria:

• Page should contain accurate and up-to-date information about the bank, including details about its history, missions, vision

• The page should match the overall appearance of the bank’s website

• Page should display any pictures/videos in good quality and suitable format.

• Page should be accessible for every customer (authorized and unauthorized)

Functional Testing

Tasks

• Verify user notification settings are applied after updating
  • Update notification channels by enabling/disabling some of them
    • SMS
    • Email
    • Web app
  • Trigger the system to send a notification (perform a money transfer, for example)
  • Verify the system is following updated user notification settings
• Verify logging of notifications to the notification center
• Verify all the important events in your account are followed by triggering sending a notification

Load Testing

Tasks

• Create a test script performing 1000 general requests per minute
• Ensure the HTTP balancer is doing its job and the system is operating normally
• Check event logs for any buffer overflow or request timeout errors
• Ensure database log triggers don't slow down the system

Stress Testing

Tasks

• Modify the load testing procedure the following way
  • Alter load testing script to perform 10K complex and time-consuming requests per minute
  • Run the script in multiple threads
  • Run the script on different computers both in the local network and from the Internet
• Ensure the database and whole system integrity

Testing procedure:

• Create the rule from Successful Transaction: Test the tool to confirm that after a successful transaction, it displays a button to create a rule based on that transaction.
• Recurrence Options: Verify that users can choose recurrence options for the rule. Test different recurrence intervals such as daily, weekly, monthly, and yearly.
• Rule Description Input: Ensure the tool provides an input field for users to describe the rule. Test that the description input is functional and allows users to enter meaningful information.
• View and Manage Rules: Test the dedicated page for viewing and managing all created rules. Ensure users can access this page and that it displays a list of rules along with their details.
• Enable/Disable/Rename/Delete Rules: Check if users can perform essential management actions, including enabling, disabling, renaming, and deleting rules. Verify that these actions update the rules effectively.
• Reminder for Rule Execution: Test the system's ability to send reminders to users one day before a rule is set to be executed. Verify that these reminders are sent as expected and include relevant details about the upcoming transaction.
• Notifications for Successful and Unsuccessful Transactions: Verify that the system notifies users about the status of executed transactions. Test that users receive notifications for both successful and unsuccessful transactions, with clear information about the outcome.

Description

The tester will conduct a series of tests on the Admin Page of the system. The test environment includes an authenticated session with admin rights, ensuring the tester has appropriate access privileges to evaluate the admin functionalities

Precondition

1. The tester is authenticated
2. The account has the Admin role

Input data

None

Test Steps

Expected Result

The tester should experience the following outcomes:

1. Successfully log into the Admin Page with appropriate credentials.
2. User management operations (addition, editing, deletion) should function correctly without errors.
3. Access to system settings, logs, and reports should be smooth and error-free.
4. User roles and permissions are correctly implemented, ensuring proper access levels.
5. The system should handle errors gracefully, displaying appropriate error messages.
6. Successful logout from the Admin Page, returning the user to the Login page.

Requirements

#11

Draft of user stories, feel free to edit/add your own ideas)

Google Document

User stories for ATM example

PDF Document

Date and Time

October 24, 2023, 14:18

Severity

Major

Priority

High

Environment:

OS: Microsoft Windows 10, 64-bit
Browser: Google Chrome (Version 118.0.5993.89)
Reproducible: Always
Build Found: Production

Preconditions

Steps to Reproduce

1. Navigate to the "To Account" selection item.
2. User should choose one of their accounts from the list. The selection is restricted to the user's own accounts.

Actual Result

Users can choose from selection item "To account" only theirs accounts.

Expected Result

Users should be able to input or select accounts belonging to other users.

Screenshots

Description

This test verifies a user can turn any successful payment into a rule

Precondition

A logged-in user

Input data

Requirements for input data to be trespassed

Example input data to be entered into the rulemaking dialog to test user input adequacy

Test Steps

Expected Result

In case no error is expected, the dialog gets dismissed and the rule is created successfully. Otherwise, the dialog stays and the user is notified about an issue through a pop-up

Requirements

#19

As a customer, I want to have some type of tool to automate payments for utility services, subscriptions, and other types of transactions with fixed amounts of funds

Acceptance criteria:

• For every successful transaction, the website should show a button to create a rule out of this transaction
• User should be allowed to choose recurrence options for the rule
• The website should show an input field to describe the rule
• User should be able to view and manage all the created rules on a dedicated page
• User should be allowed to enable/disable/rename/delete these rules
• The system should remind the user that the rule is going to be executed in 1 day
• The system should notify the user about successful and unsuccessful transactions

Робим все в останній момент

Test Case Structure

As a customer, I want to be able to pay for my service subscriptions from the bank app

Acceptance criteria:

• Website has to list available services/utilities (Internet, Electricity, Entertainment services, etc.)
• Website has to provide information about the next planned payment (if possible)
• Website has to provide the ability to search and pay for services by IBAN (International Bank Account Number) or EDRPOU (Unified State Register of Enterprises and Organizations of Ukraine)

Description

This test case verifies that the news page allows filtering news by tags and that clicking on a tag redirects to the news page with the appropriate tag filter.

Precondition

The system is online and accessible. The news page has at least two posts with different tags.

Priority

Medium

Input data

None

Test Steps

Expected Result

The news page allows filtering news by tags and clicking on a tag redirects to the news page with the appropriate tag filter.

Requirement

As a customer, I would like to see all the news of the bank

Test Case Structure

▪ Test Case ID
– Identification of the test case
– It should be unique across Test Case Specification
– Can consist of numbers or/and letters
– Examples: 1, 2, 3 etc; UR.001, UR.002, etc

▪ Test Case Name/Summary
– Short name of test case which briefly indicates what will be verified

▪ Description / Objective
– Describes the functionality/actions that test case validates/does
– It should be detailed enough to understand purpose of test case

▪ Priority
– Reflects the relative importance of the test case taking into consideration different aspects
– Can be presented by words or numbers
– Examples:
High, Medium, Low, etc;
Major, Minor, Trivial, etc;
1, 2, 3, 4 (where 1-the most important, and 4-the least important), etc.

▪ Test Case Type
– Reflects the type of test case depending on what kind of testing is covered by particular test case
– Examples: GUI, Functional, System, Performance, etc.

▪ Pre-condition
– Defines conditions that should be met before test case can be executed
– Usually precondition field lists data/actions which should exist/be done in system and links to appropriate test cases/test functions which can setup required pre-conditions
– Preconditions specified in Description are used for all Test Case.
– In case, if preconditions should contain the different data and be repeated iteratively it could be added to the first step.

▪ Test Steps
– Step by step instructions on how to carry out the test case
– There should not be missed or redundant steps!

▪ Expected Result
– Shows how the system must react based on the test steps
– Expected results should be mentioned only for test case objective!
– “Verify”, “Correctly”, “Successfully” words are forbidden for expected results! Exact behavior of the system, which is going to be verified, should be mentioned
– Example:
Incorrect: User “TestUser” is created -> It is not understandable how to verify it
Correct: User “TestUser” appears in the list of users

▪ Test Inputs / Test Data
– Lists data which is used while test case execution
– Can be presented in this field directly, in parameter or in the attached files
– Data should be accurate!

▪ Attachment
– May contain files which can be used while test case execution

▪ Execution Result / Status
– Shows the result of test case execution to indicate whether behavior of the system meets expected results of test case or not
– Examples of Test Case Status:
Passed – expected results of test case and behavior of the system match
Failed – expected results of test case and behavior of the system do not match
Blocked – test case was unable to be executed due to some reasons (e.g. blocker issue, etc.)
Not Applicable – test case was untested since it wasn’t planned to be executed this time etc.

▪ Actual Result
– Shows the actual output of the system. This field is used when actual behavior of the system doesn’t meet expected results of test case

As a customer, I would like to have the option to recover my password using my phone number or SSN.
Acceptance criteria:

• New password page should have two fields:

  1. New Password
  2. Re-enter New Password

• New password should have parameters: at least 7 characters, 1 number, 1 uppercase letter, 1 lowercase letter, one special character.

• New password cannot be same as previously used password

• New password should be saved by clicking “Reset password” button.

• A message for restoring should be sent to my phone number.

• On the next page I should enter the recovery code.

• After successful validation of all entered password fields and on clicking Submit, show message indicating successful password reset and route user to Login screen

  • If new password does not meet criteria, then red cross mark next to 'New Password' data field should be displayed that indicates this error to the user
  • If entries in 'New Password' field and 'Re-enter Password' do not match and user hits Submit, show error alert 'Password entries do not match'

UI Testing

Verify different aspects of the UI to correspond with the requirements specification

Layout

Tasks

• Verify layout of every page is rendered according to mockups
• Verify scrolling is working properly, vertical scrollbars are displayed
• Ensure CSS loading has the highest priority

Compatibility

Tasks

• Ensure the website looks the same in different supported browsers on all the supported platforms
• Ensure the website adapts to supported screen dimensions

Theming

Tasks

• Verify the website responds to the client's browser theme changes
• Ensure the website explicitly declares light/dark theme support

Accessibility

Tasks

• Ensure the website responds to the browser's zoom level (should be synced with the OS's zoom level)
• Ensure the paragraph font size is always 16pt+
• Ensure all the interactive elements are large enough for convenient usage
• Ensure TAB navigation is supported
• Ensure screenreaders extract the content from the website properly

Testing procedure:

• Verify that users can initiate a payment transaction.
• Confirm that the user can specify the recipient's details, payment amount, and payment purpose.
• Ensure that the payment system validates the recipient's details, including account number, IBAN, or EDRPOU, depending on the payment method.
• Verify that the system checks for any errors or invalid entries before processing the payment.
• Confirm that the user receives a payment confirmation before the transaction is processed.
• Verify that the confirmation includes details such as payment amount, recipient, and a transaction reference number.
• Verify that users can check the status of their payment transactions (e.g., pending, completed, failed).
• Confirm that users receive real-time updates on the payment status.
• Ensure that a history of payment transactions is available for users to review.
• Verify that payment history includes details such as date, recipient, amount, and status.
• Test scenarios where payments may fail (e.g., insufficient funds, incorrect recipient details) and confirm that users are provided with informative error messages.
• Confirm that the payment system uses secure and encrypted connections for all transactions.
• Verify that sensitive payment information (e.g., credit card details) is stored securely, following industry standards.
• If applicable for international payments, ensure that the payment system correctly handles currency conversions and displays accurate exchange rates.
• Confirm that users receive digital receipts or confirmation emails after making a payment.
• Verify that receipts include all transaction details and a unique reference number.

As a customer, I want to be able to easily transfer my funds

Acceptance criteria:

• Authenticated user should be allowed to transfer money

  • To some account by the card number
  • To some account by the phone number (if supported by the receiver’s bank and enabled for that specific account)
    • In case the receiver’s bank doesn’t support phone numbers as account numbers, an error message should pop up
    • In case there’s no account bound to the specified phone number, an error message should pop up
  • To some account within the EU by the account’s IBAN number
  • Internationally through international payment systems supported by the bank
  • Between their own accounts without manually entering account requisites

• The website must provide an input field to specify the amount of money to be transferred

• User should be able to optionally describe the purpose of the transfer in a specific input field

• After continuing with the entered details and before confirming the money transfer itself, the website should display all the info possible about the receiver’s account (full name/organization name, card number/IBAN/EDRPOU (to recheck)) and show the amount to be credited and transfer fees (commissions for both payer and receiver)

• If available for a specific account at a supported range of banks (including within the bank), the user should have an option whether to pay the transfer fee themselves or to leave the fee for the receiver to pay

• The website should ask a user to confirm payment twice to make them recheck payment details and prevent accidental money transfers

• The website should ask a user once more with a more secure way implemented by the bank (sender’s card PIN, SMS/email code, call confirmation, etc.) to confirm transfers of large amounts of funds

Date and Time

October 19, 2023, 15:01

Severity

Critical

Priority

High

Environment:

OS: Microsoft Windows 10, 64-bit
Browser: Google Chrome (Version 118.0.5993.89)
Reproducible: Always
Build Found: Production

Preconditions

Steps to Reproduce

Actual Result

User is successfully logged in.

Expected Result

Trigger an error.

Screenshots

Date Time
DD-MM-YYYY HH:MM

Severity
Blocker/Critical/Major/Minor/Trivial

Priority
High / Medium / Low

Environment:
OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Reproducible: always, rarely, sometimes etc.
Build found: (e.g. tag)

Pre-conditions
A clear and concise description of actions to be done before the start of the bug reproducing (to make bug reproducing possible). E.g.: "Create an item in the database using SQL query: INSERT INTO table1 (column1, column2) VALUES (value1, value2);"

Steps to Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Actual result
A clear and concise description of what do happen.

Expected result
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Postconditions
A clear and concise description of actions to be done after bug reproducing. E.g.: "Delete created item from database using SQL query: DELETE FROM table1 WHERE id=<item1_id>;"

User story and test case links E.g.: "User story #100 Test case"

Labels to be added "Bug", Priority ("pri: "), Severity ("severity:"), Type ("UI, "Functional"), "API" (for back-end bugs).