Unlikely your suspicions are correct. Provisioning high QoS to the speedtest site is common practice (see fast.com for countermeasures), but changing the entire subscriber QoS because traffic to one particular destination is detected seems like too much work and doesn't really achieve anything useful. If you are on a wireless network (either your upstream from a WISP, or internally on your own network), then I'd susp…
About seven years ago, when unencrypted HTTP was still commonplace, I observed exactly this behavior (subscriber-wide QoS based on speedtest sensing) with my residential cable internet. My connection was nominally 100 Mib/s, but I would often observe downloads e.g. in Steam running at only 10-20 Mib/s. In those cases, I would open up a terminal and run
while sleep 1; do curl http:///speedtest; done
Didn't matter that this URL would give 404. Just because the URL contained "speedtest", the ISP machinery would adjust the QoS and the Steam download would immediately shoot up from 10 Mib/s to nearly the full 100 Mib/s.By now, this has not worked in a long time. I'm guessing they tore down the respective machinery once the important speedtest websites moved to HTTPS.