Solution to Challenge 1 - Login with Different Users

Challenge #1 is done — here's my solution to Practice Real-World Testing Scenarios for QA: Challenge #1 - Login with Different Users

I created the Abi's testing dojo, a website with some of the challenges that I had to handle localization:

A global trade web app where that I have to test to ensure it was correctly translated into Portuguese. I got an Excel with the translation in English and Portuguese.
An e-commerce site for different countries TThe DOM elements differed across countries, so instead of adding a lot of if/else or switch cases, I refactored using CSS locators in a JSON file for each country. So the test steps were the same, and with a parameter, you can test across different countries.

So the first challenge is to test login with different languages and varying levels of access; the user role determines the menu displayed.

I prefer creating API tests with Postman because it is easier and focused on APIs, but I have also worked on two projects with RestSharp. I think RestAssured for Java is a very popular option, so I included the example with RestAssured for .Net

API Testing

I tested these scenarios:

Login

Login with the admin user returns the admin menu.
Login with a normal user will return the menu for normal users.
Menu without user returns status code 401
Menu access with a user with access to a menu link returns HasAccess true
Menu access with a user without access to a menu link returns HasAccess false

Usually, the dates should be in UTC, so on login, I checked that the expiration date was within 24 hours, and I added some time as bandwidth.

Postman

I usually create a folder to test different scenarios for a feature, using this naming convention: API_Scenario_Expected_Result. Example: Login_withAdminUser_ReturnsAdminToken

I always add utility function that contains common validations across all tests. There is also a package library option

In one project, the JSON returned by the API changed significantly, but with the global function, I only needed to update the function, and the error message was different for each API.

On each API request, you can use the global functions as:

// 1. Test that the status code is 200
utils.StatusOk();

You can execute your tests on Postman with different options:

** Postman scheduled option** You can, for example, schedule daily tests and receive an email if they fail. I used this option in one project.

Export collection and environment to a Git repo with Newman.
Postman Cli with the collection and environment IDs. I used this with one project with Bamboo as CI/CD.

You can also create a CSV file so I can run the same test with different test data. For example, the login will be the same; you only need to change the default language, and each language and menu should be in a CSV file with the same name as your environment variables.

You can install the Postman Report on Azure Devops to get the results on your Azure DevOps CI/CD

Postman Newman report on Azure DevOps

.NET

For .NET, I decided to try a new testing framework TUnit

For security, you will never store passwords in code; instead, store them as secrets on your computer or in Azure Key Vault.

If you are using Azure DevOps and you have Visual Studio, you can associate your API tests with the manual Test Case

RestSharp

RestSharp is a popular package for making HTTP Requests, although it's not focused on testing like RestAssured. I've worked with RestSharp in 2 different projects.

I also created a TestBase with global functions that include the Auth Bearer token in all requests that require the user token.

I usually add each file with the API to test, for example, login + Test.cs (e.g., LoginTest.cs), which extends BasePage.

I created a wrapper to call the API. If new versions of RestSharp introduce a breaking change, you only need to update the ApiClient class.

RestAssured

RestAssured iis very popular for Java API testing and uses the Given/When/Then syntax.

 var response = Given()
            .ContentType("application/json")
            .Body(loginRequest)
        .When()
            .Post($"{AuthUrl}/api/Users/login")
        .Then()
            .StatusCode(200)
            .And().Body("$.AccessToken", Is.Not(Is.Null<object>()))
            .And().Body("$.TokenExpiration", Is.Not(Is.Null<object>()))
        .DeserializeTo<LoginResponse>();

UI Testing

For UI testing, you have different options. I've worked with

I tried some AI options that can generate code for manual tests. I added the link to the article. I tested with the first version, so I guess it now includes more options

To create tests, I usually follow the Page Object Model (POM) and components to add common functionality, for example, to grids, date pickers, and combos. With this combo, I've worked on UI migration from Telerik webforms to Component One, so I only need to change the Grid from Telerik to Component One, instead of changing some helper or more code.

I explained in a video How to design a web automation testing framework

For the different languages, I created a data folder with the text for each language.

I created a fixture to set the current language from the playwright projects.

// Each project runs the full test suite once in that language.
// The project name is matched by the locale fixture in fixtures/index.ts to load the correct data/xx-XX.json file.
// To add a new language: add a project here, add the mapping in fixtures/index.ts, and create data/xx-XX.json.
  projects: [
    { name: 'English', use: { ...devices['Desktop Chrome'] } },
    { name: 'Spanish', use: { ...devices['Desktop Chrome'] } },
    { name: 'German', use: { ...devices['Desktop Chrome'] } },
    { name: 'Japanese', use: { ...devices['Desktop Chrome'] } },
  ],

Fixture

// Fixtures are shared test dependencies that Playwright injects into every test automatically.
// Instead of repeating setup code in each test, you declare it once here and use it as a parameter.
// This file exports a custom `test` object that replaces the default one from @playwright/test.
import { test as base } from '@playwright/test';

// Maps the Playwright project name (defined in playwright.config.ts) to a BCP-47 locale code.
// The project name is used as the human-readable label in the HTML report.
const localeMap: Record<string, string> = {
    English:  'en-US',
    Spanish:  'es-MX',
    German:   'de-DE',
    Japanese: 'ja-JP',
};

type Fixtures = {
    locale: string;
};

export const test = base.extend<Fixtures>({
    locale: async ({}, use, testInfo) => {
        await use(localeMap[testInfo.project.name] ?? 'en-US');
    },
});

export { expect } from '@playwright/test';

For the website, I used Transloco which uses a similar approach to JSON.

I follow the same security best practices for using the .env file with user and password information, and I also created API helpers, for example, to read Excel, PDF, or API files.

Playwright includes a global setup where you can store the session for different users and reuse it for different tests.

async function globalSetup() {
    await fs.mkdir(authFolder, { recursive: true });

    const browser = await chromium.launch();
    const page = await browser.newPage();
    await page.goto(process.env.BASE_URL!);

    const loginApi = new LoginApi(page);

    let userLogin: Login = {
        Company: process.env.COMPANY!,
        UserName: process.env.NORMAL_USER!,
        Password: process.env.NORMAL_PASSWORD!,
        KeepSession: true,
        Code: 0,
    };
    await storeToken(page, await loginApi.login(userLogin));
    await saveAuthState(page, 'normal-user.json');

And to use, you only need to add the state

test.describe('Valid access to the page', () => {
    test.use({ storageState: '.auth/normal-user.json' });

I add tags in general by feature to execute tests by tag. You can also create tags like regression, security, smoke.

With an additional npm package, you can add a tag with the Test Case ID from Azure DevOps, and each time you execute the Azure DevOps pipeline, it will mark the test failed, passed, or skipped on Azure DevOps.

I published the results on GitHub Pages. I used this approach with one project, but they wanted to store the last week in separate folders, and on that project, I connected it to Allure Report.

You can check my solution code TestingDojo Code

Thanks for following along with my take on Challenge #1! Testing is all about continuous learning, so don't hesitate to ask questions or share your feedback below. If this helped you in any way, feel free to share it with the community.

推荐订阅源

DEV Community