> was that a connection that could have been made in a QA engineers mind?
That's not a connection that should be made in a QA engineer's mind, it's a connection that should be made in an architect or team lead's mind, or better yet, one that should already exist as part of the internal documentation. You don't throw tarballs over the wall at the QA team yelling "you dudes, tell me if this breaks!". You know what's being developed and how, and you design your tests to validate that. Otherwise there are infinitely many tests to run.
As for the connection: the article is low on technical details, and https://www.reddit.com/r/apple/comments/anvufc/psa_2018_macs... suggests there might be several bugs at work here. That being said, if there were a list of top 5 things that could get screwed by date and time change, synchronous playback would definitely make it on that list.
If anything, the output from one of the bug reports ( https://openradar.appspot.com/46918065 ) hints that one of the thing that happens as part of the update is pausing the audio engine. The person who introduced the bug may not have figured it out at the time (which is okay, we all make mistakes), but the whole thing should have gone through code review, at least one round of documentation, and a testing process that's built to spot new problems along with the old ones, based on knowledge about what's new in the code. With the right process in place, there's no way that hits the market without serious testing, not at a pro-oriented company anyway.
Edit: tl;dr: IMHO, that's definitely a testing scenario that should have existed. By spending and commitment, the pro audio industry is probably 1/3rd of the Macbook Pro market, synchronous playback issues routinely creep up in software whenever time and clocking are brought into discussion, and (for at least one of the bugs) the source is not some strange interaction but a deliberate action in the code.