Heb je de tweede generatie AirPods Pro en valt het geluid soms weg, dan ben je niet de enige. Maar dit probleem is tot nu toe alleen nog maar op het forum van MacRumors gesignaleerd, en zelfs daar zijn er ook gebruikers die er geen last van hebben.

Met andere woorden, het lijkt hier te gaan om een probleem(pje) dat we vaak zien bij het uitbrengen van nieuwe devices: sommige mensen hebben in bepaalde omstandigheden last van een bug. Maar voor de meeste mensen is er niets aan de hand. Daarmee wil ik de problemen die deze mensen ondervinden natuurlijk niet bagatelliseren, de bedoeling is om het in perspectief te plaatsen.



Het is de moeite erbij te vermelden dat er in dat draadje op MacRumors ook mensen zitten die firmware 5A377 er op hebben staan. Deze update kwam vier dagen geleden uit, het lijkt er dus niet op dat die dit probleem heeft opgelost.

Heb je zelf last hiervan van vind je in datzelfde draadje van MacRumors ook een aantal oplossingen. En het is natuurlijk ook altijd een optie om iets wat je net hebt aangekocht terug te sturen onder garantie. Waarbij je dan natuurlijk hoopt dat de vervangende AirPods Pro geen last van dit probleem zullen hebben.

Wat ik altijd zo 'knap' vind bij het uitkomen van een grote update van hard - en/of software, dat ze er maanden aan werken, vele bêta testers er (hopelijk) mee testen en dan na een week van uitkomen zijn er fundamentele problemen. Ik vraag me dan af wie de Bêta-testers eigenlijk zijn... ?

Afgezien van het geen ‘fundamentele problemen’ zijn (want ze zijn vrijwel altijd bij een volgende update opgelost), is het een simpele rekensom. Bèta testen doe je altijd met een relatief kleine groep. Zelfs als dit er 1000 of 2000 zijn is dat slechts een fractie van de wereldwijde uitgifte in de eerste week na zo’n release. De kans dat er daarmee een nog onbekende variabele of omstandigheid opduikt die incidenteel een probleem oplevert is enorm. Dat hoeven wereldwijd slechts 100 meldingen te zijn en iedereen kan ze op zo’n site als MacRumours lezen.

Dat hele proces is mijn inziens volkomen logisch, niet fundamenteel en - belangrijker nog - Apple heeft een behoorlijk solide methode om kort na die signaleringen automatische updates uit te rollen om die issues op te lossen.

Onderdeel van het moderne leven met technologie, denk ik. Maar geen probleem. Het zou pas een probleem zijn als Apple dit proces niet onder controle zou hebben. En daar is volgens mij geen sprake van.

[ Ger ]

+1 voor Ger.

De aantallen mensen met klachten zijn meestal relatief klein. En als het wel om grote groepen gaat dan was het gewoon pech dat het bij het beta-testen niet naar boven kwam.

Ik ben het dan weer eens met nnsa. Het gaat niet om de kwantiteit van de béta tests maar om de kwaliteit. En daar lijkt het nogal aan te schorten bij Apple de laatste tijd.

Snap wat je bedoelt te zeggen Sluisje, maar bèta-testen en testers zijn per definitie kwalitatieve testers. Dat zijn er geen één of twee, maar uiteindelijk een paar honderd tot vele duizenden (afhankelijk van wat er moet worden getest). Niet alleen bij Apple, maar in elke bèta-test situatie bij elk hard- of softwarebedrijf. Daarnaast heeft Apple tegenwoordig ook 'Public Bètas' waarbij welwillende liefhebbers eveneens hun feedback mogen geven. Wat de groep (en het aantal variabelen) flink groter maakt en de kans op grote problemen fors minder.

Waar je desondanks altijd mee te maken hebt, is dat een relatief beperkte interne of publieke externe testgroep nooit alle mogelijke variabelen in hard-, software en/of (omgevings) omstandigheden zullen of zelfs maar kunnen vertegenwoordigen. Dat zijn bij een OS letterlijk honderden miljoenen variabelen, zo niet honderden miljarden combinaties van factoren die een nog niet eerder ontdekt probleem kunnen laten ontstaan.

Dus zijn er bij de daadwerkelijke uitrol onder honderden miljoenen praktijk gebruikers altijd wel een paar situaties die tot op dat moment onbekend zijn gebleven. Dit is simpelweg nooit te voorkomen, hoe goed die bèta-testers ook hun kwalitatieve werk doen.

[ Ger ]

Testen begint bij kennis van hoe iets verondersteld wordt te werken. Trillende camera's en crashes zijn duidelijk. Vaak is het echter minder evident. Als eindgebruiker vind ik bijv. de handleidingen soms te oppervlakkig om te weten of iets correct werkt.

Neem bijv. recente draadjes over dubbele foto's. Als er geen duidelijke definitie van is (ik heb er bijv. niet direct een gevonden in de Foto's handleiding voor macOS Monterey), dan wordt het moeilijk te valideren of de app naar behoren werkt. Het toenemend gebruik van machine learning stelt ook uitdagingen, want je werkt hier bijna per definitie met foutenmarges. De vraag wordt bijgevolg eerder: hoe goed lijkt het te werken?

Ik heb hier verschillende keren aanbevelingen voor open-source producten zien passeren. Soms duik ik eens in de code om te kijken of de ontwikkelaar unit testen heeft gemaakt. Vaak zijn er geen. Dit kan in feite al jaren niet meer, ook al is het product goed.

En als ik het aantal keren een probleem op dit forum zie opgelost worden door een volledige herinstallatie, terwijl er misschien 'gewoon' ergens een instelling fout of corrupt is... Dit zou toch beter moeten kunnen.

Neem bijv. recente draadjes over dubbele foto's. Als er geen duidelijke definitie van is (ik heb er bijv. niet direct een gevonden in de Foto's handleiding voor macOS Monterey), dan wordt het moeilijk te valideren of de app naar behoren werkt.

Dit is net nieuw in iOS 16, dus ik neem aan dat je macOS Ventura nodig zal hebben voor deze functie.

Met andere woorden, als het niet in Monterey zit dan zal je het ook niet in de gebruiksaanwijzing daarvan vinden.

Deze nieuwe functie in iOS16 wordt beschreven op deze pagina.
Een omschrijving van de criteria waarop de foto's beoordeeld worden ontbreekt. Ook wat er gebeurt wanneer foto's worden samengevoegd geeft weinig info.

Draadjes over problemen door dubbele foto’s zijn er trouwens al van vóór iOS 16 en Ventura.

Waar je desondanks altijd mee te maken hebt, is dat een relatief beperkte interne of publieke externe testgroep nooit alle mogelijke variabelen in hard-, software en/of (omgevings) omstandigheden zullen of zelfs maar kunnen vertegenwoordigen. Dat zijn bij een OS letterlijk honderden miljoenen variabelen, zo niet honderden miljarden combinaties van factoren die een nog niet eerder ontdekt probleem kunnen laten ontstaan.

Eens met Ger.


En mcmt raad ik dit artikel aan, vind je vast interessant, of je kent het al:
Out of the Tar Pit - Ben Moseley & Peter Marks (2006)

Hier is een TL;DR versie. Met een leuke slot-alinea:

I described "Out of the Tar Pit" to my former manager as one of those papers where if you read it, you can't help but agree with it's message because it puts into words what you already know by heart. He replied that this is true only if you've worked in programming for long enough to suffer from the effects of unmanageable complexity. Otherwise, you have no idea what the authors are talking about.

Het is vrij evident dat je niet alle combinaties van variabelen kan testen, net zo min als dat je alle waarden van een variabele gaat testen. Hier geldt ook de wet der verminderende opbrengsten.

Je kijkt naar verschillende beslissingspaden binnen een functie, naar happy day scenario's en edge cases, naar input waarden die een fout kunnen veroorzaken, .... Je probeert vooral functionaliteit netjes te scheiden en apart testbaar te maken, met minimale afhankelijkheden van andere modules. Dan merk je ook dat doeltreffend testen en eenvoud van code en ontwerp samengaan.

@puk1980: Dank voor de link.