Test cases for a Login Page
Overview
In this tutorial, we will learn how to write manual test cases for a login page. Login Page test cases in this tutorial are not verbose to list all the test cases. The tutorial’s main aim is to teach you how to write test cases on your own.
Login Page UI Mock-up
https://www.testingdocs.com/login-page-ui-mockup/
Actors
Bob is a web application user. Mark is a System administrator with powerful capabilities to manage the web application. Malicious Hacker is not a verified user of the system. However, the hacker is trying to get hold of other users’ login credentials.
Functional Test Cases
Understand the main functionality of the application under test. Functional Specifications, SRS documents.( Software Requirement Specification), User Stories, etc.
Test Case Name | Test Case Detailed Steps | Test Data | Expected Result | Actual Result |
Verify Login Page Load. |
Preconditions Application Server running. Web client(Browser) connected to the network. Steps
|
|
Verify that the Page loads successfully in the browser window. |
The importance of the test case is High. This test case is the Basic Verification Test. (BVT). If this test case fails the tester can log a Show stopper defect with high priority. There is no need to execute other test cases. A valid application defect is when the web application is not deployed on the App server, missing login page files in the build, etc.
However, the tester should investigate and ensure no false negatives exist. Things like poor network connectivity, Application server issues, Firewall issues, etc.
Test Case in TestLink Tool:
- Test case Status – Draft / Final, etc
- Test Case Priority -Importance of the Test Case.
- Test Case Execution Type – Manual / Automated
- Test Case Execution time – This is used for test effort estimation
Valid Login Test Case
Test Case Name | Test Case Detailed Steps | Test Data | Expected Result | Actual Result |
Verify Successful Login. |
Preconditions App Server running, App Deployed. Good Network Connection. Steps
|
username: sampleUserName
password:%Sam%123
|
Verify that the User Dashboard Page is displayed. |
This is a valid positive happy path test case. The login page should always be hosted on HTTPS protocol.
Invalid Login Test Case
Enter an invalid username and /or password. Error messages should be displayed to the user. There can be several combinations for these testcases.
Remember Me Test Case
Test Case Name | Test Case Detailed Steps | Test Data | Expected Result | Actual Result |
Verify the Remember Me Option. |
Preconditions App Server running, App Deployed. Steps
|
|
Verify that the session cookie is set and stored in the browser.
Users should be directed to the Dashboard page without entering login credentials. |
GUI Test Cases
Test Case Name | Test Case Detailed Steps | Test Data | Expected Result | Actual Result |
Verify Login Page GUI. |
Preconditions Login Page BVT Test Case Pass. Steps
|
|
Verify that the Page text labels are displayed. Verify the Look and Feel of the Page. |
Error messages
Verify Error messages for invalid login attempts.
Consistent fonts, readable text size, etc. All the text on the page should be visible to the user.
Page Responsive
Verify the Login page responsiveness on different screen sizes, small screens like mobile devices, etc.
Security Test Cases
Server Communication Encryption Test Case:
Test Case Name | Test Case Detailed Steps | Test Data | Expected Result | Actual Result |
Verify Login Page Encryption. |
Preconditions App Server running, App Deployed. Network Sniffing Turned ON. Steps
|
username: sampleUserName
password:%Sam%123 SLA (Service Level Agreement) for encryption TLS 1.1 or higher (Transport Layer Security) |
Verify that the Login page communication to the App Server is encrypted. |
Sniff the communication using Protocol Analyzer tools like ( Wireshark, etc).
Some testcases are:
HTTPS Redirection Test Case
Launch the login page URL on HTTP. It should redirect to HTTPS with a valid SSL certificate. Verify the SSL certificate in the browser.
Session Timeout
Session Timeout Testcase: There should be a login session timeout duration.
Browser Back button
What happens when we click the Browser back button after logging out of the application?
Penetration test cases
Login attempts, Rate limiting
How many unsuccessful login attempts can an actor make from the same IP address?
Verify and write test cases for common security issues like:
- SQL Injection
- XSS ( Cross-Site scripting )
- SSLScan vulnerabilities, etc.
For example, we can test that the login page is vulnerable to SQL Injection attacks.
In the National Vulnerability Database(NVD), we can find the Common Vulnerabilities and Exposures (CVE) list.
Performance Test cases
Test Case Name | Test Case Detailed Steps | Test Data | Expected Result | Actual Result |
Verify Login Page load Time. |
Preconditions App Server running, App Deployed. End User Network Connection Speed. Steps
|
username: sampleName
password:%Same%123 SLA (Service Level Agreement) for Page load time = 5 secs. TTFB < 1 sec Time To First Byte FCP < 2 secs (First Contentful Paint) |
Verify that the Page Load time is < 5 secs.
FCP < 2 secs TTFB < 1 sec |
FCP – First Contentful Paint
TTFB – Time To First Byte
Compatibility Test Cases
Assume that the web app supports Windows 10, Ubuntu Linux.
Browser: Mozilla Firefox ( latest version.), Microsoft Edge and Google Chrome browser ( latest version).
Notice how the test cases for compatible device combinations explode 2 x 3 = 6 combinations
Test Case Name | Test Case Detailed Steps | Test Data | Expected Result | Actual Result |
Verify Login Page Compatibility. |
Preconditions App Server running, App Deployed. Steps
—
Repeat the test case on all possible <OS, Browser> combinations.
|
username: sampleName
password:%Sam%123 SLA (Service Level Agreement) for browser compatibility: Mozilla Firefox(latest version), Google Chrome(latest version) OS Compatibility: Windows 10, Ubuntu 20 Linux. |
Verify that the Login Page works seamlessly on various compatible device combinations. |
User Acceptance Test Cases
Everything might be working on premises for the tester on staging or QA environments. The application would be deployed on the production environment for the end user. Many factors might vary from the QA environment and the Production environment.
UAT test cases are designed for the end user to execute on the web application in the Production environment. This can be in a controlled environment setting or uncontrolled.
Related:
ATM Test Cases:
https://www.testingdocs.com/atm-test-cases-automated-teller-machine/