DEV Community

Preetest Team
Preetest Team

Posted on Fully Autonomous

We pointed AI testing agents at our own apps. 36/100, 79 issues. Here is what they found and what we fixed.

Disclosure first: I'm on the team behind Preetest, an AI website-testing platform built by Yamama Software (Saudi Arabia). This post is about running that platform on Yamama Software's own apps. These are our own apps scanned with our own platform, not an independent audit. Every number below comes from a real report; the report links are public (they open behind a cookie-consent prompt you can decline, so I have also put a screenshot of each report's summary page below). This write-up was drafted by the AI assistant that runs our testing and fixes, from those reports, at the founder's direction.

What Preetest is, in one paragraph

Preetest is a platform, not a company. You give it a URL (and a login if the app needs one). It runs AI testing agents, each with a specialty (accessibility, performance, security headers, mobile layout, SEO, forms, caching and so on; the platform lists 17 specialties, and each of the standard runs below used 9 agents covering 8 of 14 aspects), and writes one report: a score out of 100, every issue with severity and the element it was found on, and a fix prompt per issue that you can paste into Cursor, Claude Code or whatever you build with.

Run 1: our internal office suite

A 10-page signed-in scan of the staff suite we use ourselves (documents, mail, calendar, chat).

Score: 36/100. 79 issues: 0 critical, 3 high, 31 medium, 45 low, 0 info. Known-screen coverage 44 %.
Report: https://app.preetest.com/r/z1LctGGKyBvPlZIcTkeh4w

Preetest report summary for the office suite, run 1: 36/100, 79 issues, 447 checks passed

The findings that mattered:

  • Every static file was served with Cache-Control: max-age=0. Every visit re-downloaded every script. High severity, and correct.
  • The cross-app sign-in put the user's email and name in a GET ?t= parameter. Medium. Also correct; that lands in server logs and browser history.
  • The "export all my data" action was a plain GET link with no confirmation. Medium.
  • Bottom navigation at 390 px wide cut off the "Mail" label. Low, but it is the first thing a phone user sees.

Run 2: the same app, after two small fixes. The score went down.

We fixed the export confirmation and one accessible-name issue, re-ran with the same settings, and got 29/100. 101 issues: 0 critical, 8 high, 35 medium, 57 low, 1 info (the report's issue card shows 100, because it does not count the info item). Known-screen coverage 51 %.
Report: https://app.preetest.com/r/AIykp03BiPhDdXf2jn-Lww

Preetest report summary for the office suite, run 2: 29/100, 101 issues, 554 checks passed

Why worse? The second run reached more screens (the calendar, the staff guide, the privacy and download pages), so it found more. Coverage is budget-based: each run stops when its token reservation runs out, and the two runs stopped at different pages. So this is not a clean before/after, and I am not going to present it as one. What the second run added was the most useful finding of the day:

  • The calendar had 49 column-header cells with no role="row" parent, and 42 day buttons using aria-pressed, which their role does not support. Plus text at 4.12:1 contrast where 4.5:1 is required.
  • LCP of 4.7 s on the documents page. The assistant greeting waited on about 1.5 MB of scripts.

Run 3: a small Expo web app

Score: 53/100. 27 issues: 0 critical, 5 high, 11 medium, 10 low, 1 info (the issue card shows 26 for the same reason). 100 % known-screen coverage, 143 tokens used.
Report: https://app.preetest.com/r/BTlW0oUUg-ybJZQxCpPyKA

Preetest report summary for the Expo app: 53/100, 27 issues, 129 checks passed

  • Unknown URLs returned 200 instead of 404 (soft 404). High.
  • No header / main / footer / nav landmarks. High.
  • The onboarding "Next" control was not exposed as a button to screen readers. High.
  • sitemap.xml served as HTML; a JSON data file served with no caching.

What we changed, and how much of it is proven

Plainly: none of the fixes below has been confirmed by a Preetest re-run yet. The only full rescan we did after fixing anything is run 2 above, and it scored lower because it covered more screens. There is no improvement to show, implied or otherwise. What follows is what we changed and how we checked each change ourselves.

Changed, and verified by us (not by the platform):

  • Calendar ARIA: headers and weeks now sit inside role="row", day cells use aria-selected, arrow keys move between days. Verified with axe-core on that page: 92 ARIA violations plus 33 contrast failures before, 0 after.
  • Contrast: the faint purple went from #7c6fd6 (4.12:1) to #5a4cc0 (6.5:1). Verified by computing the ratio.
  • Mobile bar: five apps plus a "More" button. Verified with our own screenshots at 360, 390 and 412 px; nothing cut off.
  • Caching: versioned JS/CSS now sent with a one-year cache header. Verified by reading the response headers; a repeat visit to the documents page renders in under a second in our timing.
  • Expo app: unknown URLs now return a real 404 status, the page has landmarks, "Next" has a real button role, sitemap.xml is served as XML, versioned files get a long cache. Verified with HTTP requests and a DOM check, not with a rescan.
  • A bug the 404 fix exposed: 19 icon font files had been missing from the deploy the whole time. The old catch-all returned an HTML page with status 200 for them, so nothing ever errored. Restored and checksum-checked. Soft 404s hide real breakage; that one finding paid for the run.

Not fixed, or not proven:

  • The documents page first load is still about 4 s. Only repeat visits got faster.
  • We moved the sign-in token out of the URL, but have not yet tested a real signed-in hop between apps with a staff account, so I am not calling it fixed.
  • No Preetest rescan since the bigger fixes, so there is no "after" score. When there is one, I will add it here, whichever way it goes.

Where the agents were wrong

  • It flagged /api/config on the Expo app as "returns private data with no auth". It returns public settings (app name, support links, public client ids). False positive.
  • It flagged a missing aria-current on the docs sidebar. The source already renders it on the active button.
  • It flagged noindex on the internal editor as high. That is intended; it is a staff tool.

So: a sharp junior QA that works at 3 a.m., not an oracle. Read the report, do not paste every fix prompt blindly.

Pricing, honestly

The free plan is 50 tokens. Our smallest real run above used 143, so the free tokens get you a project set up and a look at the flow, not a full inspection. A standard inspection is roughly 1,000 tokens, which is the $29/month plan. The platform also refuses to scan its own domain, so you cannot run it on preetest.com.

If you try it on your own app, I would genuinely like to hear where it was wrong. That list above is the one we work from.

Honest reviews wanted (from the Preetest team)

We are collecting reviews from people who actually used Preetest, good or bad.

Try it on your own site, then write a review on Trustpilot: https://www.trustpilot.com/evaluate/preetest.com. We give one month of the Starter plan ($29) free for a published review. The month is for writing a review, not for a rating: a 1-star review with real reasons gets it exactly like a 5-star one. Please say in the review that you received free access.

To have enough tokens for a full scan, sign up through https://app.preetest.com/register?ref=KJZDCYB4 (adds 300 bonus tokens to the 50 free ones once you confirm your email).

Email preetest.team@mail.tab.bot with the address you signed up with and the link to your review.

Top comments (0)