thoughts from the test eye

In security testing, passive scanning is quite a big thing. You browse or spider a web site, and the network traffic is scanned to find potential vulnerabilities.
But this is not so common for general software testing, which is quite strange.
Why don’t we have tools that test in the background while we are doing testing?
Maybe there are quite a lot of custom tools that I don’t know about, and I have built a couple of browser extensions myself that weren’t big hits, because they found vey few bugs (maybe I gave up too early).
It feels better now that I have generalized it in Trowser:

security – the smallest pack that is valuable and fast; retire.js should be on all web testers’ machines, but the Chrome extension is equally good.
accessibility – axe-core for WCAG violations.
performance – big files, duplicated requests, slow responses.
functionality – 500s and 404s.

As with all testing, a lot of it will not be important or even a bug, so your judgment is needed.
For me it has most value when I am testing something new.

There were some design decisions where the speed was important, we don’t want to cause a sluggish browser experience.
Therefore I slimmed existing tests and put suspicious response codes into quicktest ConsoleAndNetworkErrors. The editable RequiredForbiddenStrings was kept as separate quicktest.
If you have specific things that are important in your context, I recommend vibe-coding a browser extension, or your own Trowser quicktest in Watch mode.