Login Is Slow but Still Works

The Situation

The login functionality works correctly, but it takes too long to complete.

This is a performance defect, not a functional defect.

Step-by-Step Approach

Check Performance Requirements

This is the most important step.

Verify the expected SLA or benchmark.

Example:

  • Login should complete within 2–3 seconds.

Without a benchmark, "slow" becomes subjective.

Measure the Actual Response Time

Measure the time from:

  • Clicking the Login button
  • Until the dashboard loads completely

Compare With the Benchmark

Compare the measured response time with the expected SLA.

Collect Evidence

Capture:

  • Response timings
  • Screenshots
  • Performance measurements

Report the Issue

Raise it as a Performance Defect with the measured timing evidence.

Measuring It Properly

Separate the server's time from the browser's. For the login API, curl shows where the time goes — we ran this against a test login endpoint three times:

curl -s -o /dev/null -X POST -H "Content-Type: application/json" \
     -d '{"username":"qa","password":"***"}' \
     -w "connect=%{time_connect}s  first_byte=%{time_starttransfer}s  total=%{time_total}s  status=%{http_code}\n" \
     https://qa.example.com/api/login

connect=0.0005s  first_byte=2.351s  total=2.351s  status=200
connect=0.0004s  first_byte=2.352s  total=2.352s  status=200
connect=0.0003s  first_byte=2.351s  total=2.351s  status=200

Connecting took under a millisecond, but the first byte of the response arrived after 2.35 seconds, consistently. That points to server-side processing (a slow query, an external call), not the network or the browser. If the API is fast but the page is slow, the problem is in the front end — use the browser's DevTools Network and Performance tabs, and save a HAR file as evidence. Measuring several times, at different times of day and with a realistic user (one with lots of data), makes the report hard to dismiss.

Advertisement

API Returns Partial Data & the UI Is Stuck

The Situation

The API returns a successful response, but the response contains incomplete or partial data, causing the UI to become stuck.

Step-by-Step Approach

Reproduce the Issue

Verify that the UI hangs only when the API returns partial data.

Capture the API Request and Response

This is the most important step.

Capture:

  • Request parameters
  • API Response

using tools such as Postman.

Identify the Root Cause

Determine whether the issue belongs to:

  • API
  • UI

If the API returns incomplete data, it is primarily an API issue.

If the UI cannot handle partial responses properly, it is a UI issue.

Report With Evidence

Attach:

  • API Request
  • API Response
  • Screenshots
  • Logs

Assign the defect to the appropriate owner.

The Situation

Three bugs appear to be related.

The question is whether they should be reported individually or combined.

Decision Criteria

Combine Into One Defect

Create a single defect only when:

  • All issues originate from the same root cause.

One logic defect should result in one well-documented bug report.

Report Separately

Create separate defects when:

  • Each issue has a different root cause.

Even if the symptoms appear related, different root causes require separate tracking.

Key Principle

Always base the reporting decision on the root cause, not simply on how similar the defects appear.

System Is Slow With No Exact Repro Steps

The Situation

Users report that the application is slow, but the issue cannot be reproduced consistently.

Step-by-Step Approach

Gather Maximum Information

Collect:

  • Logs
  • Monitoring information
  • Environment details
  • Time of occurrence

Determine whether the issue occurs in:

  • Production
  • UAT

Look for Patterns

Identify common factors such as:

  • Time of day
  • Load levels
  • Specific modules
  • User activities

Use Monitoring Data

Analyze available monitoring information to convert the vague complaint into a reproducible performance issue.

Two Dependent Modules, One Not Ready

The Situation

Two modules depend on each other, but one module is still under development.

Step-by-Step Approach

Identify the Dependency

Understand exactly how the two modules interact.

Test Independent Functionality

Continue testing:

  • UI validations
  • Field validations
  • Independent business logic

Use Mock Data or Stubs

Use:

  • Mock Services
  • Stubs
  • Dummy Responses
  • API Mocking with Postman

This allows integration testing to continue until the dependent module is completed.

A Bug You Can't Reproduce Consistently

The Situation

A genuine defect appears only intermittently.

Step-by-Step Approach

Never Ignore the Issue

Do not dismiss intermittent bugs simply because they are difficult to reproduce.

Reproduce Under Different Conditions

Test using different:

  • Browsers
  • Devices
  • Networks

Capture Evidence

This is the most important step.

Collect:

  • Browser Console Logs
  • Network Logs
  • Application Logs
  • Environment Details
  • Build Information

Look for Patterns

Identify whether the issue is triggered by:

  • Timing
  • Test Data
  • User Actions
  • Environment

"It Works on My Machine"

The Situation

The same application behaves differently across different systems.

This is often caused by environment or configuration differences.

Step-by-Step Approach

Verify Environment Details

This is the most important step.

Compare:

  • Environment
  • Build Number
  • Version

The same code can behave differently in different environments.

Compare Configurations

Review:

  • Configuration files
  • Environment settings

Validate Test Data

Ensure both users are testing with identical data.

Compare Client Environments

Verify:

  • Browser
  • Browser Version
  • Operating System
  • Device

Also clear:

  • Cache
  • Cookies

if necessary.

Ensuring Negative-Scenario Coverage

The Situation

You need to ensure all negative scenarios for a form are adequately tested.

Step-by-Step Approach

Understand the Requirements

This is the most important step.

Review:

  • Validation rules
  • Mandatory fields
  • Business requirements

Apply Standard Test Design Techniques

Use:

  • Boundary Value Analysis (BVA)
  • Equivalence Partitioning

Also validate:

  • Invalid inputs
  • Missing mandatory fields
  • Incorrect formats
  • Special characters
  • Security-related inputs (such as SQL Injection), where applicable

Verify Every Validation Rule

Ensure each validation rule has corresponding negative test cases.

Do not test only the happy path.

The API Returns 200 but the Data Is Wrong

A related trap: the status code is 200, so a status-only test passes — but a required field is missing or empty, and the UI breaks further down. Assert on the body and the contract, not just the status:

// Postman (Post-response script)
const body = pm.response.json();
pm.test('200 OK', () => pm.response.to.have.status(200));
pm.test('required fields present and not empty', () => {
  pm.expect(body).to.include.all.keys('id', 'items', 'total');
  pm.expect(body.items).to.be.an('array').that.is.not.empty;
});

More: Postman Assertions and JSON Schema Validation. Practice these scenarios as interview questions, with follow-ups, in the API Testing Interview Simulator.

From Real Projects

Before any automation, my work on each project started with the requirement: understanding the business flow, identifying scenarios, writing test cases and getting them reviewed. On Canolog, where sales, inventory, finance, service and parts all connect, that analysis is what found the gaps between modules. Execution was tracked in TestRail and defects in Jira. On Apkope, prospect and customer data arrives from email, phone, social media and chatbots, so test scenarios had to cover every channel that feeds the same records. Gather evidence first; it turns a debate into a decision.

📖 Related tutorials

📚 Official documentation: MDN: HTTP · ISTQB Glossary of testing terms

FAQs

How Do You Test a Login That Is Slow but Still Works?

Treat it as a performance issue.

Verify the expected SLA, measure the actual login response time, compare the results, and report the issue with timing evidence.

What Do You Do When an API Returns Partial Data and the UI Hangs?

Reproduce the issue, capture the API request and response using Postman, determine whether the root cause belongs to the API or UI, and report it with supporting evidence.

Only when all three issues share the same root cause.

Otherwise, report each issue separately.

How Do You Test When a Dependent Module Is Not Ready?

Test the independent functionality first and use stubs, mocks, dummy responses, or API mocking to simulate the unavailable module.

How Do You Handle a Bug That Cannot Be Reproduced Consistently?

Do not ignore it.

Test under different browsers, devices, and network conditions, capture detailed logs and environment information, and identify patterns.

How Do You Ensure Negative-Scenario Coverage?

Understand the validation rules first, then apply Boundary Value Analysis, Equivalence Partitioning, invalid inputs, missing mandatory fields, special characters, and security-related negative scenarios.