The Frontend Audit Guide for SQA: 22 Tests in Plain English

A step-by-step field guide for catching performance, interactivity, data-integrity, accessibility, and code-quality bugs — written in plain English, with validation checklists and copy-ready bug-report templates you can paste straight into your tracker.

Part 1 — Making It Feel Fast

Performance tests: images, loading, and code delivery (Tests 1–6).

1 · Image Jumping (Cumulative Layout Shift)

Have you ever tried to click a button, but right before you click it an image finishes loading and pushes the button down, making you click the wrong thing? That's what this is.

How to test:

1. Open Chrome DevTools (right-click → Inspect) → Network tab → change 'No throttling' to Slow 3G.
2. Refresh the page and hover your mouse over a button that sits directly below an image.
3. Watch what happens as the image finishes loading.

2 · Lazy Loading

If a page has 50 pictures, the browser shouldn't download the ones at the very bottom until the user actually scrolls down to look at them.

How to test:

1. Open the Network tab.
2. Load a long article with lots of images. Do NOT scroll down.
3. Watch how many image files download immediately.

3 · Background Image Processing (Async Decoding)

When a massive 4K picture loads, it takes a lot of CPU brainpower to process it, which can freeze the user's screen for a split second.

How to test:

1. Scroll very fast down a page until a huge banner image comes into view.
2. Watch closely for any stutter or freeze the moment the image appears.

4 · Link Hover Pre-loading (Prefetching)

When a user hovers their mouse over a link, the website should secretly download the next page in the background before they even click, making navigation feel instant.

How to test:

1. Open the Network tab.
2. Hover your mouse over the 'Settings' button for 1 second — do not click it.
3. Check if anything new appears in the Network tab during hover.

5 · The Ugly Font Flash (Preconnect)

Sometimes a website loads with a boring system font like Times New Roman, then half a second later 'snaps' into the custom font. This looks very unprofessional.

How to test:

1. Check 'Disable Cache' in the Network tab.
2. Hard refresh the page (Cmd+Shift+R or Ctrl+Shift+R).
3. Watch the text closely as the page loads.

6 · Sending Too Much Code (Code Splitting)

A regular user shouldn't have to download the code that runs the Admin Dashboard, because they aren't an admin. The code should be split into separate chunks.

How to test:

1. Log in as a normal (non-admin) user.
2. Open the Network tab and click on the largest JavaScript file downloaded.
3. Press Ctrl+F and search for words like 'AdminDashboard'.

Part 2 — Making It Feel Smooth

Interactivity tests: input handling and UI responsiveness (Tests 7–12).

7 · Search Lag (Debouncing)

If you type 'apple' into a search bar, the website shouldn't search for 'a', then 'ap', then 'app'. It should wait until you finish typing to do the search.

How to test:

1. Open the Network tab.
2. Type quickly into the search bar — e.g. 'macbook pro' — without pausing.
3. Count how many API requests appear in the Network tab.

8 · Scroll Lag (Throttling)

If a scroll tracker runs 1,000 times per second (e.g. to change a header's colour), your computer will lag. It should be capped to run far less frequently.

How to test:

1. Scroll up and down the page furiously using your mouse wheel or trackpad.
2. Pay close attention to whether the scrolling feels choppy or smooth throughout.

9 · Losing Your Place (Scroll Restoration)

If you scroll down 50 items, click an item, then click the Back button, you shouldn't be dumped back at the very top of the list.

How to test:

1. Scroll deep down into a long list.
2. Click on any item in the list.
3. Click the browser's Back arrow and observe where the scroll position lands.

10 · Faking Instant Clicks (Optimistic UI)

When you click 'Like' on Instagram, the heart turns red instantly; it doesn't wait for the server. If the internet fails 3 seconds later, it quietly reverts.

How to test:

1. Throttle the network to Slow 3G in the Network tab.
2. Click a 'Like' or 'Bookmark' button.
3. Time how long before the button visually changes state.

11 · Hiding Loading Spinners (Stale-While-Revalidate)

If you visit a dashboard, leave, and come back 5 minutes later, it shouldn't show a blank loading screen again. It should instantly show old data while fetching updates in the background.

How to test:

1. Visit a data-heavy page and let it fully load.
2. Click away to another page.
3. Navigate back to the first page and observe what appears first.

12 · Too Many Items (Virtualization)

Rendering a table with 10,000 rows will crash the browser. Only the ~20 rows visible on your screen should be drawn at any time; the rest are swapped in as you scroll.

How to test:

1. Open a list or table with thousands of items.
2. Open DevTools → Elements tab.
3. Count how many <tr> or list-item tags exist in the HTML panel simultaneously.

Part 3 — Data Bugs & Weird Glitches

Data integrity: duplicates and rendering conflicts (Tests 13–15).

13 · Double-Click Protection (Idempotency)

An impatient user mashing the 'Submit Payment' button 5 times shouldn't be charged 5 times. The system must handle repeated submissions safely.

How to test:

1. Fill out a 'Create Item' or similar form.
2. Rapidly double-click or mash the Submit button multiple times.
3. Check the resulting list or database for duplicate entries.

14 · Server/Browser Disagreement (Hydration Mismatch)

Sometimes the server thinks it's 12:00 PM, but the user's browser thinks it's 8:00 AM. When the page loads, they 'fight', causing the clock to visually glitch on screen.

How to test:

1. Hard refresh the page (Cmd+Shift+R).
2. Stare closely at things like timestamps, dates, or randomly generated numbers.
3. Watch if any text visually jumps or flashes right after the page finishes loading.

15 · Wasting Math (Memoization)

Typing one letter into a search box shouldn't force the browser to re-calculate and re-draw the entire navbar and footer; only the search-related components should update.

How to test:

1. Install the React Developer Tools browser extension.
2. Open DevTools → Profiler tab → click Record.
3. Type one letter into a search box, then click Stop.
4. Look at the flame chart for unexpected yellow/green component re-renders.

Part 4 — Accessibility & Keyboard

Keyboard navigation and focus management (Tests 16–17).

16 · Trapping the Keyboard (Focus Trapping)

If a popup is open, a keyboard user shouldn't be able to press Tab and accidentally interact with buttons hidden behind the popup.

How to test:

1. Open a 'Confirm Deletion' or any modal popup. Put your mouse away.
2. Press Tab 10 times and watch the blue focus-highlight box.
3. See if focus stays inside the popup or escapes to background elements.

17 · The Never-Ending Dropdown (Roving Tabindex)

A keyboard user shouldn't have to press Tab 50 times to get past a long dropdown menu. The whole list should be one Tab stop, with arrow keys navigating inside.

How to test:

1. Press Tab to move focus into a large custom dropdown list.
2. Try to Tab past it to reach the next form element below.
3. Count how many Tab presses are needed to escape the dropdown completely.

Part 5 — Code Audits

Behind-the-scenes checks, usually via code review or tooling (Tests 18–22).

18 · Shaking the Tree (Tree Shaking)

If a developer imports a massive 500-page library just to use one sentence from it, the bundler should delete the other 499 pages before shipping it to users.

How to test:

1. Run Webpack Bundle Analyzer (or equivalent) on the production build.
2. Look for large blocks of library code flagged as unused.
3. Compare bundle size with and without the library to assess impact.

19 · Erasing Test Code (Dead Code Elimination)

Developers write console.log('This is broken!') while testing. This debug code should be automatically removed when the app is shipped to real users.

How to test:

1. Open the live production website.
2. Open DevTools → Console tab.
3. Browse around various pages and look for any developer debug messages printing.

20 · Fake Buttons (Polymorphic Components)

Sometimes a developer designs a pretty blue 'Button', but uses it as a link to another website. It must look like a button but use the correct <a> HTML tag so search engines can read it.

How to test:

1. Find a styled button that links to an external URL.
2. Right-click it and choose 'Inspect'.
3. Check which HTML tag is actually used in the markup.

21 · Reusable Building Blocks (Inversion of Control)

Instead of building 4 different Button components just because they have different icons, you build 1 Button and let the caller pass in whatever icon they need.

How to test:

1. Browse the component folder in the codebase.
2. Search for near-duplicate names like ButtonWithLeftArrow, ButtonWithRightArrow, ButtonWithSpinner.
3. Compare their code for meaningful differences vs. minor copy-paste variations.

22 · Designing for the Worst (Graceful Degradation)

The website should still show something useful even if the user is on an ancient phone or if JavaScript breaks completely; never a blank white screen.

How to test:

1. Open Chrome DevTools → Settings (gear icon) → Preferences.
2. Check 'Disable JavaScript'.
3. Reload the page and observe what is displayed.