# Chrome for software QA testers on Mac: DevTools, throttling and HAR steps for 2026

> Chrome for software QA testers on Mac: DevTools shortcuts, network throttling, Device Mode and HAR export steps, and how Lazur helps while you test.

URL: https://www.lazur.app/for/software-qa-testers/chrome
Updated: 2026-11-09

Chrome for software QA testers on Mac runs on DevTools. Open it with ⌘⌥I, then use the Network, Console and Elements panels to reproduce, prove and report a bug. This guide covers the shortcuts, throttling, Device Mode and HAR steps you will use most. It also shows where Lazur fits while you stay in Chrome.

## Quick answer

- Open DevTools with ⌘⌥I. Use ⌘⌥J for the Console and ⌘⇧P for the Command Menu.
- Throttle the network from the Network panel to test slow connections before you file a bug.
- HAR exports leave out Cookie, Set-Cookie and Authorization by default. Turn on the sensitive option only when you need it.
- Read your Chrome build from chrome://version before you write a report, because the build changes what you see.

![A QA tester on a Mac laptop checks a web page for bugs in Chrome at a desk](https://images.lazur.app/content-images/role-app/software-qa-testers-chrome/chrome-for-software-qa-testers-on-mac-1-302bb2.jpg)

## What QA testers actually do in Chrome on Mac

Most software QA testers on a Mac use Chrome for three jobs. They reproduce a bug. They prove what the browser sent and what came back. Then they describe the problem so a developer can fix it. Chrome's built-in DevTools covers all three. You do not need a second app to start.

DevTools opens beside the page or below it. Chrome calls that spot the docking position. Press ⌘⇧D to switch back to the last docking position when the panel lands somewhere awkward. Small fixes like this keep the window out of your way.

## Open DevTools on Mac with the right shortcut

Learn four shortcuts first. ⌘⌥I opens DevTools on the panel you used last. ⌘⌥J goes straight to the Console. ⌘⌥C opens Elements. ⌘⇧P opens the Command Menu, where you can search for any DevTools action by name.

- ⌘⌥I: open DevTools on the last panel you used
- ⌘⌥J: open DevTools on the Console
- ⌘⌥C: open the Elements panel
- ⌘⇧C: toggle inspect element mode, which Chrome's shortcut page also lists for Elements
- ⌘⇧P: open the Command Menu and search by action name
- ⌘⇧M: toggle Device Mode, a shortcut the Device Mode article does not mention
- ⌘⇧D: switch the DevTools window back to the last docking position

The ⌘⇧C line is the one that confuses people. Chrome's shortcut page lists it twice for Mac. Test it on your own build before you rely on it. If it does not do what you expect, search the Command Menu with ⌘⇧P for the action name instead.

The same problem shows up with ⌘⇧M. The shortcuts page calls it Toggle Device Mode. The Device Mode article describes a toolbar button and no dedicated shortcut. Try the shortcut first. If it fails, use the toolbar button.

## Reproduce a bug with the Network panel and ⌘F

Open the Network panel before you reproduce the bug. Trigger the failure once. Then click the request that looks wrong. The Headers, Payload and Response views show what the browser sent and what the server returned. That split helps you tell a page problem from a server problem.

Press ⌘F while the Network panel is active to search headers, payloads and responses. Search for an error message, a field name or a test order ID. The search reaches inside response bodies, so you can find a value without scrolling a long request list.

Here is a simple case. A checkout button seems to do nothing. You open the Network panel, press the button, and find a request to the order endpoint. You search the response for the order ID and find an error message the page never showed. Now the bug report has evidence, not a guess.

## Throttle the network to test slow connections

Throttling slows the connection Chrome uses for the page. Use it to see what a slow user sees. Open the Network panel, then open the Network throttling drop-down. Pick Fast 4G, Slow 4G or 3G. Pick Offline to cut the connection completely.

The drop-down sits next to Disable cache. Choose Custom > Add when no preset matches the speed in a bug report. When throttling is on, the Network panel shows a warning icon. Look for that icon before you blame the app for slow loading.

| Option | Where to find it | What to check |
| --- | --- | --- |
| Fast 4G | Network throttling drop-down | Loading on a quick mobile connection |
| Slow 4G | Network throttling drop-down | Loading states on a weaker signal |
| 3G | Network throttling drop-down | Timeouts and spinners that never stop |
| Offline | Network throttling drop-down, next to Disable cache | What the page shows with no connection |
| Custom | Custom > Add | A speed that matches the bug report exactly |

_Throttling options in the Chrome DevTools Network panel_

Turn throttling off when the test ends. The warning icon tells you it is still on. A common mistake is to run the next test on a slow profile and file a bug that was never there.

## Test layouts with Device Mode at real widths

Device Mode resizes the page to a device width. Chrome's own guide calls it a first-order approximation of how your page looks and feels on a mobile device. It does not run the code on a phone. Use it as a first pass, then check a real device when you are not sure.

| Preset | Width |
| --- | --- |
| Mobile S | 320px |
| Mobile M | 375px |
| Mobile L | 425px |
| Tablet | 768px |
| Laptop | 1024px |
| Laptop L | 1440px |
| 4K | 2560px |

_Device Mode width presets in Chrome DevTools_

Custom devices take a name, a width and a height. Use a custom device for a screen size your team supports that Chrome does not list. Write the width in every bug report, so a developer can reproduce it at the same size.

Avoid one common mistake. Do not report a Device Mode layout bug as if a real iPhone showed it. Say in the report that you used Device Mode, and name the preset or width. That one line prevents a round of back and forth.

## Check layout bugs in the Elements panel

Open the Elements panel with ⌘⌥C when the bug looks visual. Elements shows the HTML of the page. Pick a part of the page and you see the markup behind it. That helps you tell a missing element from one that is hidden.

Use ⌘⇧C when you want to point at the page instead of hunting through markup. Confirm what that shortcut does on your build first, because Chrome lists it twice on Mac.

Pair Elements with Device Mode. Set the width to Tablet at 768px, then inspect the element that breaks. Write the width and the element name in your report, so the developer can find the same part of the page.

## Export a HAR file without leaking secrets

A HAR file records the network traffic for a page. Developers ask for one because it shows the exact requests and responses. Chrome sanitizes the export by default. Cookie, Set-Cookie and Authorization are left out of the file.

Sensitive exports need an extra step. Open Settings > Preferences > Network. Turn on Allow to generate HAR with sensitive data. Then choose Export HAR (with sensitive data). Third-party guides use other menu labels, so check the labels in your build.

Importing works the other way. Drag a HAR file into the Requests table, or use the Import HAR button in the action bar. Imported requests keep their initiators, so you can trace where each one started.

Read the file before you share it. The default removes three headers. It does not promise that nothing sensitive is left in the body. Send the sanitized file in public tickets, and send the sensitive one only to people who need it.

![A Mac laptop on a desk, ready for Chrome browser testing by a software QA tester](https://images.lazur.app/content-images/role-app/software-qa-testers-chrome/chrome-for-software-qa-testers-on-mac-2-805163.jpg)

## Use the Console and Recorder to repeat a flow

Open the Console with ⌘⌥J, then reload the page. Read the first error in red, then the lines after it. The first error often explains the rest. Copy the exact message into the report, not your paraphrase.

The Recorder panel saves a series of steps as a replayable recording. On Mac, ⌘E starts or stops recording. ⌘Enter replays it. ⌘B toggles the code view. ⌘C copies the whole recording or the step you have selected.

Record a flow once, then replay it after each fix. Copy the code into the ticket, so the developer runs the same steps you ran. Replaying a recording removes one source of human error from the retest.

## Keep Chrome and macOS in step with your test Macs

Build version changes what DevTools shows, so write it down. Open chrome://version in the address bar and copy the build number into the report. Google's Chrome Releases blog posted a stable desktop update dated November 3, 2026. That post did not list a build number, so read yours from chrome://version.

macOS sets a floor. Chrome 150 is the last release to support macOS 12. Chrome 151 removes macOS 12 support, and new installs require macOS 13 or later. On macOS 12, Chrome keeps running but stops updating.

Watch for stale release notes. The Chrome Enterprise release notes list Chrome 152 as the latest entry, dated September 1, 2026. That page is older than the November update, so do not use it to pick a build for your lab.

A test Mac on macOS 12 will fall behind. Check every Mac in the lab before you assign Chrome 151 work to it. A Mac that cannot update may give you reports from a build that does not match what your users run.

## What AI can and cannot do for QA work right now

- **Up to 82%** of testers still use manual testing in their day-to-day work, per Katalon's survey of 1,400 QA professionals ([source](https://katalon.com/resources-center/blog/test-automation-statistics-for-2025))
- **45%** of those manual testers automate regression testing, per the same Katalon article ([source](https://katalon.com/resources-center/blog/test-automation-statistics-for-2025))
- **15%** of organizations have scaled Gen AI in quality engineering enterprise-wide, per the World Quality Report 2025-26 ([source](https://www.capgemini.com/insights/research-library/world-quality-report-2025-26/))
- **macOS 13** minimum for new installs of Chrome 151, which drops support for macOS 12 ([source](https://support.google.com/chrome/a/answer/10314655?hl=en))

Katalon's State of Quality Report 2025 interviewed 1,400 QA professionals, according to its article. The article says up to 82% of testers still use manual testing in their day-to-day work. About 45% of those manual testers automate regression testing. This is a vendor survey, not an independent study, so read it that way.

Capgemini's World Quality Report 2025-26 says only 15% of organizations have scaled Gen AI in quality engineering enterprise-wide. Gen AI was also the top-ranked skill for quality engineers, at 63%. Other secondary coverage gives different adoption figures, so quote only the 15% number.

No survey I could find measured how much time testers lose to DevTools friction. Treat any speed claim about a tool with care, including the ones on this page. Time the workflow on your own pages and decide from that.

## What to say to Lazur while you test in Chrome

Lazur is a voice assistant for the Mac. It lives in the notch. Hold ⌥⌘ to ask about anything on screen, and Lazur answers out loud. It sees your screen only while you hold the shortcut.

Ask where something is, and Lazur draws a circle and a label around it. Ask how to do something, and Lazur guides you one click at a time, waiting for each click. Lazur does not click for you. It does not operate other apps, so the clicking stays with you.

Hold fn to dictate clean, formatted text at the cursor in any app. Use it for repro steps and report text. Snippets, a personal dictionary and clipboard slots help with the phrases you repeat every day.

Research is the background option. Ask Lazur to research a question, and it runs in Lazur's own Chrome tabs through the Lazur for Chrome extension. It comes back with a summary and a report. Check the sources in that report before you rely on them.

Privacy matters on a test page. Lazur listens and looks only while you hold the shortcut. Audio and the screenshot go to AI providers to answer, and they are not stored. Content is never used to train AI models. If the page holds customer data, check your company rules first.

## A worked example: from checkout error to bug report

Here is one pattern you can reuse. A customer says a promo code works on a phone but fails on a laptop. Work through it in this order.

1. Open the page under test. Press ⌘⌥I and pick the Network tab.
2. Turn on Device Mode with ⌘⇧M, or use the toolbar button. Choose Mobile M at 375px and apply the promo code.
3. Turn Device Mode off. Test again at Laptop L, which is 1440px wide.
4. Press ⌘F in the Network panel and search for the promo code. Compare the request and response from each run.
5. Open the Console with ⌘⌥J. Note any error that appears at the moment of failure.
6. Export a HAR without sensitive data. Send the sensitive version only if the developer asks for it.
7. Write the report. Include the build from chrome://version, the macOS version, the width and the HAR file name.

The report now holds facts a developer can act on. It also says what you did not test, such as a real phone. Ask Lazur to draft the report from your notes. Then check every line before you file it.

![A developer reviews browser console errors on a laptop screen during QA testing](https://images.lazur.app/content-images/role-app/software-qa-testers-chrome/chrome-for-software-qa-testers-on-mac-3-f9be12.jpg)

## Common mistakes QA testers make in Chrome on Mac

- Reproducing a bug before opening DevTools, so the request never shows in the Network panel.
- Reporting a Device Mode layout as a phone bug without saying so.
- Sharing a sensitive HAR file in a public ticket.
- Leaving throttling on after the test, then blaming the app for slow loads.
- Skipping the Chrome build number, so the developer cannot match your results.
- Trusting the ⌘⇧C label in one list and ignoring the second entry.

## What to do next

Pick one open bug from your queue and run it through the steps above. Write the Chrome build and the macOS version in the report. If you need a clean start between runs, clear your browsing data first, using the [steps for Chrome on macOS](https://www.lazur.app/how-to/clear-browsing-data-in-chrome).

When you want Lazur on your Mac, the [download page](https://www.lazur.app/download) has the install. You can compare plans on the [pricing page](https://www.lazur.app/pricing) before you decide.

## With Lazur

Lazur is a voice assistant for the Mac that lives in the notch. Hold ⌥ ⌘ and ask; it sees your screen, answers out loud, points at buttons and walks you through apps. Hold fn to dictate. Free for 3 days, then $18/month: https://www.lazur.app/download

- “Where is the Network tab in this DevTools window?”: Lazur draws a circle and a label around the Network tab on screen. You click it yourself. (Points at it)
- “Where is the Network tab in this DevTools window?”: Lazur circles the Network tab and labels it on your screen.
- “Walk me through throttling this page to Slow 4G.”: Lazur guides you one click at a time and waits for each click before the next step.
- “What does this failed request in the Network panel mean?”: Lazur explains the response out loud, based on what is on your screen.
- “Draft a bug report from my notes, with steps and the console error.”: Lazur drafts the report text. You check every line, then paste it into your tracker.
- “Research how Chrome 151 changed macOS support for our test Macs.”: Research runs in Lazur's own Chrome tabs and comes back with a summary and a report.
- “Repro steps: open checkout, add an item, apply the promo code.”: Hold fn and speak. Lazur types clean, formatted text at the cursor in any app.
- “Which keyboard shortcut opens the Console on this Mac?”: Lazur answers out loud and can point at the Console tab if it is on screen.

## FAQ

### Do I need to install anything to use DevTools on Mac?

No. DevTools comes built into Chrome. Open a page you want to test, then press ⌘⌥I. You need Chrome installed and a page to test.

### Which shortcut opens the Console on Mac?

Press ⌘⌥J to open the Console in DevTools. Press ⌘⌥I to open DevTools on the panel you used last. Chrome's shortcut page is the place to confirm the list for your build.

### Why does Chrome list ⌘⇧C twice?

Chrome's shortcut page lists ⌘⇧C once for toggling inspect element mode and once for opening the Elements panel. Test it on your build. If it does the wrong thing, search the Command Menu with ⌘⇧P.

### Is Device Mode the same as testing on a real phone?

No. Chrome calls Device Mode a first-order approximation of how a page looks and feels on mobile. It does not run the code on a mobile device. Use a real device when you are not sure.

### Is a HAR file safe to share?

The default export leaves out Cookie, Set-Cookie and Authorization. That does not make the whole file clean. Read it before you share it, and send the sensitive version only to people who need it.

### How do I find my Chrome build on Mac?

Open chrome://version in the address bar. Copy the build number into your bug report. Do not rely on a blog post for the current number, because builds change often.

### Will Chrome 151 run on an older Mac?

New installs of Chrome 151 require macOS 13 or later. On macOS 12, Chrome keeps running but stops updating. Check each Mac in your test lab before you assign work to it.

### Can Lazur click through DevTools for me?

No. Lazur does not click buttons or operate other apps. It can point at the Network tab, explain what you see, guide you one click at a time, and draft text for you.

### Does Lazur work on Windows?

Lazur runs on macOS, on Apple silicon and Intel Macs. Windows is planned, not available. This guide covers Chrome on Mac only.

## Sources

1. [Keyboard shortcuts | Chrome DevTools | Chrome for Developers](https://developer.chrome.com/docs/devtools/shortcuts), Google Chrome for Developers, checked 2026-11-09
2. [Network features reference | Chrome DevTools | Chrome for Developers](https://developer.chrome.com/docs/devtools/network/reference), Google Chrome for Developers, checked 2026-11-09
3. [Simulate mobile devices with device mode | Chrome DevTools](https://developer.chrome.com/docs/devtools/device-mode), Google Chrome for Developers, checked 2026-11-09
4. [Previous release notes, Chrome Enterprise and Education Help](https://support.google.com/chrome/a/answer/10314655?hl=en), Google, checked 2026-11-09
5. [Chrome Releases: Stable Channel Update for Desktop (2026-11-03)](https://chromereleases.googleblog.com/2026/11/stable-channel-update-for-desktop.html), Google Chrome Releases, checked 2026-11-09
6. [Test Automation Statistics & Trends for 2025 (Katalon)](https://katalon.com/resources-center/blog/test-automation-statistics-for-2025), Katalon, checked 2026-11-09
7. [World Quality Report 2025-26, Capgemini](https://www.capgemini.com/insights/research-library/world-quality-report-2025-26/), Capgemini, checked 2026-11-09