Site icon TestingDocs.com

Test cases for a Login Page

admin

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:

  1. Test case Status  – Draft / Final, etc
  2. Test Case Priority -Importance of the Test Case.
  3. Test Case Execution Type – Manual / Automated
  4. 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

  • Launch the Browser.
  • Navigate to the login page URL.
  • Enter a valid Username.
  • Enter a valid Password.
  • Click on the ‘Sign In’ button.
 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

  • Launch the Browser.
  • Navigate to the login URL.
  • Enter VALID user credentials.
  • Toggle the Remember Me option button.
  • Hit the Sign in button.
  • Close the browser tab.
  • Open a new browser tab and Re-launch the Login page.
  

 

 

 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

  • Launch the Browser.
  • Navigate to the login page URL.
  • Examine the Login page text, buttons, toggle switch, and password link.
  

 

 

 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

  • Launch the Browser.
  • Navigate to the HTTPS login page URL.
  • Sniff the network traffic.
 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:

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

  • Launch the Browser.
  • Navigate to the login page URL.
  • Measure Page load Time.
 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

  • Launch the Mozilla Firefox Browser on Windows 10.
  • Navigate to the login page URL.
  • Verify the Page.

—

  • Launch the Google Chrome Browser on Ubuntu 20 Linux.
  • Navigate to the login page URL.
  • Verify the Page.

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/

Exit mobile version