DEV Community

Cover image for Practice Real-World Testing Scenarios for QA: Challenge 2 - Data Grid Validation and CRUD Operations
abigail armijo
abigail armijo

Posted on

Practice Real-World Testing Scenarios for QA: Challenge 2 - Data Grid Validation and CRUD Operations

#api #devchallenge #testing #tutorial

Hi! The second challenge is ready — if you missed it, start with Challenge 1: Login with Different Users to get familiar with the site and set up your environment.

Challenge 2: Create test scenarios from User story.

This time you will create the testing scenarios following the structure of a user story.

You can find some tricky gaps on the user story and I will give the gaps when I publish my solution.

I only created one small Figma design but usually are more complete with the desktop and mobile version. You can check this Practical Design Example.

Create the manual test, API Tests and E2E tests.

Title: [UI - API] Register Servers

Description:
The admin user needs to register the different servers used to connect to the ERP to see some reports from the Firebird database.

Server Fields
Id - Server ID (numeric auto-increment)
Key – Server key (unique identifier)
Name – Server name
URL – URL to connect to the ERP API
Active – Whether the server is enabled

Scope: view the registered servers, search by name or key, add, edit, delete, and mark a server active/inactive.

Design
https://www.figma.com/proto/rY4DuulnpEMQ9vGwzkbVK9/Practical-UI-design-system?node-id=9221-1831&p=f&t=sRD8XZAWmyZJB4nW-1&scaling=min-zoom&content-scaling=fixed&page-id=9220%3A79786

In the attached file, you can find translations for English, Japanese, Spanish, and German.

Acceptance Criteria

Servers grid

  • Admin can see a list of registered servers showing Key, Name, URL, and Active status.
  • Admin can search the list; results filter as text is typed. The list supports pagination with page sizes of 10, 20, 50, and 100 rows.
  • The list can be exported to Excel and PDF.
  • When there are no servers, the list shows a message that explains that there is no data registered.

Add / Edit

  • An admin can add a new server, edit an existing one, or delete it.
  • Key, Name, and URL are all required; Save is disabled while the form is invalid. Key: number between 1 and 999999. Name: text, maximum 150 characters. URL: must start with http:// or https://, maximum 200 characters. -Key must be unique; uniqueness is validated server-side. Saving a duplicate Key returns a server error message, and the record is not saved. -A new server defaults to Active.

Delete / Active state

  • You can delete a server only if no company is assigned to it.
  • An admin can mark a server as active or inactive; inactive servers remain visible in the list with Active = No.

Navigation

  • Clicking a server name opens that server's companies (that will be in user story #451)

Permissions

  • Only authenticated admin users can access the servers screen and its actions.
  • I attached a CSV file with the translations to the different languages.

CSV file

Key,English,Spanish,German,Japanese
title,Servers,Servidores,Server,サーバー
newServer,New Server,Nuevo Servidor,Neuer Server,新しいサーバー
key,Key,Clave,Serverschlüssel,サーバーキー
keyHint,Key (1 to 999,999),Clave (1 a 999,999),Schlüssel (1 bis 999.999),キー（1〜999,999）
name,Name,Nombre,Servername,サーバー名
nameHint,Descriptive name for the server,Nombre descriptivo para el servidor,Beschreibender Name für den Server,サーバーの記述的な名前
url,URL,URL,Server-URL,サーバーURL
urlHint,Full URL including protocol (e.g., https://server.example.com),URL completa incluyendo protocolo (ej. https://servidor.ejemplo.com),Vollständige URL einschließlich Protokoll (z.B. https://server.beispiel.com),プロトコルを含む完全なURL（例：https://server.example.com）
active,Active,Activo,Aktiv Status,アクティブステータス
activeHint,Enable this server to allow access to database,Habilitar este servidor para permitir acceso a base de datos,Diesen Server aktivieren, um Datenbankzugriff zu ermöglichen,このサーバーを有効にしてデータベースアクセスを許可する
Enter fullscreen mode Exit fullscreen mode

Tips

  • The grid is your source of truth for viewing, sorting, filtering, and handling empty states — and every value it shows should match what the API actually returns and/or the description of the user story.
  • Creating and editing records, on the other hand, happens on a separate form page, backed by the Data API, so you'll get to practice writing pre-conditions and post-conditions around real API calls, and generating random test data with Faker instead of hardcoding it.
  • As always, every challenge in this series also covers testing across different languages — the site supports multiple locales by default, so keep that in mind as you validate your scenarios.

Website: https://abi-testing-dojo-demo.azurewebsites.net/
Security API (Scalar): https://abi-testing-dojo-auth-demo.azurewebsites.net
Data API (Swagger): https://abi-testing-dojo-ar-demo.azurewebsites.net

If you complete this challenge, share your repository and feel free to ask any doubt about this challenge.

Top comments (0)